[Ns-developers] About 802.11 management frame

[Mirko Banchi]

Hi all,

i've a question about 802.11 management frames. I'll try to explain the
problem by an example. Suppose a sta1 is sending an Association request
to an Ap.
The Ap should send an Association Response frame. But should this happen
in the same TxOp? I mean, between this frames exchange is possible
another frame exchange for example a data frame exchange between sta2
and ap? I read carefully the standard but this is not really explained.
I deduced it in the clause 7.1.4 (point 2):

-------
Within all data or management frames sent in a CP by the QoS STAs
outside of a controlled access phase
(CAP), following a contention access of the channel, the Duration/ID
field is set to one of the following
values:
a) For management frames, frames with QoS Data subfield set to 0, and
unicast data frames with Ack
Policy subfield set to Normal Ack,
1) The time required for the transmission of one ACK frame (including
appropriate IFS values), if
the frame is the final fragment of the TXOP, or
2) The time required for the transmission of one ACK frame plus the time
required for the
transmission of the following MPDU and its response if required
(including appropriate IFS
values).
--------


I think that this is very important! Working with block ack, there's
need to work with management frame in order to negotiate block ack and
i found it's complex if the management frame exchange could be completed
in two different Txops even if i think that this doesn't make sense.
Ns-3 for now works with management frames as they were data frames, so
their exchange (for example association request/ association response)
could not be completed in the same Txop.

Thank you all,

Mirko


-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090421/adbcf8bc/smime.bin