• If a non-QoS STA transmits to a QoS STA a data frame that exceeds the TXOP limit, what happens?

    What about vice versa?


  • By (Deleted User)

    My thoughts:

    Page 140 and 141 in the 802.11 Designer's handbook:

    Under the Hybrid Coordination Function (HCF) TXOPs are granted to QOS Stations . Since you specified a Non QoS station (STA) is doing the transmitting to the QOS station, would they not just operate in the legacy mixed environment without needing a TXOP established on that particular call leg?

    But if it was reversed ie, the QoS station was transmitting to the NonQoS station (STA) and that frame exceeded the limits of the TXOP ,we would have an issue. On page 144 of the guide , it talks about the TXOP and the frame exchange the QSTA must ensure it meets. The transmitted frame and any necessary acknowledgment, must fit into the time remaining in the TXOP.

  • Nothing.

    Non-QoS: Does not understand TXOPs, so therefore it will send the frame and receive an acknowledgment, regardless of any TXOP limits that are in place.

    QoS: Exceeding the TXOP limit can only happen because of retransmissions. If a station has an MSDU to send that would take longer than the allowed TXOP given the current PHY rate, it will fragment that frame to ensure that it stays within the TXOP.

    If a retransmission does cause a QSTA to exceed the TXOP limit, the QSTA will send the offending MPDU and receive an acknowledgment just like normal. Then it will continue to behave just like normal:

    -If fragmentation is used: The station will send the next fragment after a SIFS, just like normal. (Remember that this fragment must fit the TXOP limit.)

    -If fragmentation is not used: The station will send the next unfragmented MSDU after it wins arbitration.

  • Nice work Ben!

  • Thank you.

    I've learned to read standards from the best. :D

  • By (Deleted User)

    Yes, Ben. Thanks for answering this. I was out there flapping. I must attend one of the classes you help instruct, if you are ever in the DC area with GK . You have the Gift.

  • I am traveling and dont have access to the standards but wondered a few things while pondering this question. There are 2 ways for txop limits to be assigned one in edca with the edca capability info field and the other by hcf with the assigment of values with the qos control field. In the edca case i was wondering if it would be advantagous for the QAP to retransmit a beacon or association response frame to redefine the txop values in the case of possible corruption, say the stations arent abiding by the txop values it has assigned for ACs, which i realize is unlikely. Also, this made me wonder if when recieving a beacon will a QSTA reset its values relating to the edca capability field if the counter hasnt changed in sequence from the previous beacon.

    i appreciate all the input on this forum and am looking forward to going through the practice test questions for cwne when i return.

    Best wishes

  • Rico,

    Are you asking about some type of Beacon poisoning, whereby an Intruder would capture a Beacon, change its EDCA Parameter Set and then send the Beacon with the same Sequence number?

    My understanding is that the station does not pay attention to the Sequence number when processing Beacons. For example, that is why Beacon poisoning by setting the DS Paramenter Set to Channel 0 works.

    802.11w should solve these problems by introducing an authentication mechanism that protects the integrity of the Beacon.

    The other thing to remember in reference to your post is that Beacon frames are sent at regular intervals, so if a station has the wrong TXOP limit, it should be reset to the correct value at the next Beacon interval.

  • Rico,

    If the Retransmission bit were on and you altered the sequence number remember Beacons are not acked. So, there should never be a retransmission of a beacon frame. STAs should ignore that and the sequence number. However, a cloned MAC and SSID of an authorized AP that uses QoS on a rogue AP which is beaconing without QoS wil cause many problems for the QoS STAs. This could cause STAs to associate with the wrong AP as well as missing TXOPs. It could also force a STA to constantly reconfigure its QoS configurations. This could be an interesting DoS attack.

  • Let me first say thanks for you responses. The idea of beacon poisoning and impersonation are fascinating and very interesting in and of themselves.

    Let me clarify myself a little better than i did, but i will say the info Brian and Ben have shared has opened windows to some interesting ideas.

    I was wondering if the QAP noticed irregularities could it reset the edca values in the non-APQSTA.

    in 802.11e 2005-
    The most recent EDCA parameter set element recieved by a non-AP QSTA is used to updat the appropriate MIB values.

    It is further said -- the EDCA parameter update count subfield is used by the non-AP QSTA to determine whether the EDCA parameter set has changed and requires updating the appropriate MIB values.

    This would imply to me that unless the update count subfield has incremented its value, the EDCA parameter set will not change the MIB values in the non-AP QSTA as a result of recieving successive beacons.
    Now in a the QOS control field of a non AP QSTA the TID subfield indicates the traffic category of the data in the frame. If the QAP sees a difference in the TXOP from that assigned by the EDCA parameter set, i pondered if there could be value in incrementing the update count subfield to initiate a rewrite of the MIB values from the EDCA parameter set info.

    Anyway just some passing thoughts i had before the question was answered.

    Its lots of fun as always,

Page 1 of 1
  • 1