> Well, the multicast/broadcast frames would be sent after DTIM beacon > using normal frame transmission rules, so this would be possible order. > Though, this might not be that likely if one were to consider a case > where these APs are on separate radios (i.e., multiple STAs contenting > for the medium) should there be large number of buffered frames. Right. > While this may end up being the easiest and cleanest way of implementing > multi-BSS support, this has somewhat unfortunate drawbacks for power > save stations (e.g., STAs associated with the AP1 would need to remain > awake for the extra time needed to send beacon2 and beacon3; and STAs > associated with the AP3 would need to remain awake while mc1..mc2 frames > are sent). Yep. Hence my idea of doing DTIM 0 beacons independently. > TBTT could (and well, should) be separate for each BSS. In other words, > if there are four virtual BSSes using one radio (BSS1 .. BSS4), TBTT > should be different for each. If the beacon frames are send out as a > burst, TBTT2 should be TBTT1 + <time needed to send beacon1> and so on.. > Similarly, there should be independent TSF for each BSS. However, > implementing this for virtual BSS (single radio) designs is going to be > quite difficult since the hardware/firmware is unlikely to support > something like this.. Well, I'm fairly sure Broadcom hardware would allow this because apparently it allows subtracting/adding (?) an arbitrary (?) value to the TSF timestamp as it is written. This could be made host-controlled so the host keeps track of the offsets. The only requirement would be that the beacon periods are spread out in equal intervals to allow the microcode to schedule properly. > > Another thing that I just realised is that I'm not sure whether we > > update the TSF in probe responses correctly or at all because as far as > > I can tell it's only done for the probe response microcode offload. > > We'll have to look into this. > > This should be done in the same way as for Beacons, i.e., by whatever > low-level functionality is available in the transmitting path. Yes. Except as far as I can tell Broadcom hardware/firmware only does it when the *firmware* responds to probe responses, and we disabled that. > > Actually, what we can do is adjust the offset for each of the beacons > > differently. So when we're sending a beacon at TSF "interval * (N+.25)" > > we can round that up to "interval * (N+1)" by adjusting the TSF write > > offset. This means that stations will adopt a TSF that is larger than > > ours by a bit. If we'd do the same for probe responses (which should be > > fairly easy), would the timing work out? I'm not entirely clear about > > CFP operation etc. > > Where would the TSF be adjusted? Some of these tricks could be doable in > the low-level firmware/microcode (if one is used), but this may be > difficult to do without access to such low-level location. There is such access as I described above. I need do tests but right now I have no second wireless card at all. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
