<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> How does the collision model/scheme change between AP mode and > ad-hoc/mesh modes? </div>As far as I can tell, it doesn't.  802.11s is interoperable with 802.11abg, which means that the same media access algorithms are used.  At least part of our problem might be in the synchronized transmits occurring in our present 802.11s implementation of broadcast, which are probably killing whatever CA scheme 802.11abg dictate.  See:  <a href="http://wiki.laptop.org/go/Path_Discovery_Mechanism:Sanity#Question_.232_-_Does_PDM_traffic_self-interfere.3F" target="_blank">http://wiki.laptop.org/go/Path_Discovery_Mechanism:Sanity#Question_.232_-_Does_PDM_traffic_self-interfere.3F</a> which is trying to deal with low-level path discovery requests, which also use the broadcast mechanism.  --scott </blockquote><div> Yes, it is the same 802.11 DCF for both scenarios (infra and mesh). I would like to add to this discussion that sparse and dense mesh are too completely different animals. Most of the problems that we are trying to address now, are associated to the latter. The more we dig into this, the more clear it gets that we need to "adapt". Everything we do to increase coverage in a sparse mesh hurt us in a dense cloud. One example: broadcasting or multicasting at 1 or 2Mbps. Likewise, what we do to increase reliability, might actually decrease it. One example: the verbosity or redundancy of some of our protocols. And that's one of the strengths of Cerebro (less is more). So, as a side note: Treating the two animals as different will avoid some bites and scratches. ;-) -- Ricardo Carrano </div></div>