Bugzilla – Bug 968
Beacon generation does not use CSMA deferral
Last modified: 2010-08-04 05:06:15 UTC
Created attachment 956 [details] Modified example which shows the problem (see generated pcap file) When two access points generate beacons with the same interval (see attachment), only beacons of one access point are actually sent. When the beacons are generated with different intervals (such that they don't overlap), the beacons of APs are received. This is probably due to the (mis-)configuration of m_beaconDca in NqapWifiMac::NqapWifiMac. There, CWMin and CWMax are set to 0 which disables the backoff process for beacons. 802.11-2007 11.1.2.1 states however that also beacons shall use the normal CMSA procedures.
Created attachment 963 [details] first step towards the solution I agree that the current behavior is not standard compliant. Attached is a tentative fix. Note that qap-wifi-mac would need to be fixed, also. Unfortunately I could not find in the standard what is the AC that is to be used when sending beacon frames. Does anybody have any idea?
(In reply to comment #0) Hi! I did not find any information about backoff procedures for beacons. If medium is defined busy, beacon will be sent after the medium has been idle a PIFS (9.3.2.1) interval. The following note "NOTE—Though the transmission of a Beacon frame may be delayed because of CSMA deferrals, subsequent Beacon frames shall be scheduled at the undelayed nominal beacon interval. This is shown in Figure 11-1." in section 11.1.2.1 does not mean a backoff procedure. It says, that beacon shall be generated after data frame + PIFS deffereal. Also in your example you have started both APs simultaneously, so (because there are no random start and there is no model of processing delay), beacons are generated exactly simultanuoisly, and CSMA can't resolve this problem. In dot11s module beacons are strictly periodical, and when we have removed random start for beaconing generation, nothing works properly.
Kirill, thank you very much for your explanation. After reading 9.2.3.2 and re-reading 11.1.2.1, I agree with your interpretation. The current code uses a DcaTxop with CWmin = 0 and AIFSN=1. This corresponds to the behavior described by Kirill: if medium is busy, defer transmission until medium is idle for a PIFS, but do not do backoff. So there is no need to perform any change. I am therefore closing this bug.