On Mon, Nov 12, 2007 at 01:02:31PM +0100, Johannes Berg wrote: > That's the point I wasn't quite sure on, would it be valid to send the > frames in the order beacon1, beacon2, beacon3, mc1, mc1, ..., mc2, ..., > mc3, ...? 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. 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). > On Broadcom hardware, I'm pretty sure that the transmit engine updates > the timestamp only during transmission so that shouldn't be a problem. OK. This will allow the STAs to remain in sync. > Time zero is defined as TBTT, so this means we need to send the frame as > close to TU "Beacon Interval" * N where N is a non-negative number. Is > my interpretation correct here? If so, and because we only have a single > TSF, doesn't this mean that we should send the beacons all together as > quickly as possible? If we tried spreading them out we'd be sending them > at something like "Beacon Interval" * (N + 0.25) which isn't something > we should do, no? 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.. Consequently, the only realistic mechanism may end up being to try to send the beacon frames as close to each other as possible. I'm not sure whether non-AP STAs would be able to handle offset from the N * beacon_int TUs time and still sleep properly. In theory, they could try to sync with previous beacons, but this would be difficult to do since beacon transmission times can vary a bit. This would be simple if we would not need to think about power saving, but reality is likely to be much more complex and the safest solution would to just try to send the frame as close as possible after the N * beacon_int time. > 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. > 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. > > I've done some > > experiments with configuring the hardware to use beacon interval divided > > by number of BSSes, but ended up using burst of beacon frames instead > > (and all BSSes were forced to use the same beacon interval). > > Do you remember any reason? Nope.. There were some issues in getting the implementation to be stable, so that may have been the main reason. Setting the beacon interval and related interrupts to very small values was probably not expected in the original design. -- Jouni Malinen PGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
