Discovery is a special case, that is not quite multicast. Discovery is "noticing". A node wishing to be discovered must be noticed by one (or maybe more) already existent stations in a group (groups are noticed by any member being noticed by a member of another group).
So you don't need any facility to "reach all" in one message. It's sufficient to "reach any". From that point on, it's a higher level problem of "association management" (tracking members and their reachability). I use these general terms in quotes to step outside the frame limited to 802.11 and its rigid culture. So the key to discovery is *anycast* not multicast. So for example, a station that is not yet associated could follow some predictable sequence of transmissions, using a variety of MI transmissions (multiple input, i.e. multiple antennas transmitting simultaneously) with a variety of waveforms, where that sequence was determined to have a high probability of being noticed by at least one member of the group to be joined. A station noticing such a signal could then use the signal's form itself to respond and begin to bring that station into the group of stations that can hear each other, discovering further information (like mutual propagation characteristics (multipath/MIMO coefficients, attenuation (for equalization), noise)). By conflating discovery with multicast, one loses design options for discovery and cooperative transmission. So yes, the "normative" centralized access point discovery now practiced in 802.11 nets assumes a sort of "multicast", but that is because we have "centralized" architectures, not mesh at the phy level. On Thursday, April 28, 2016 9:43am, "Toke Høiland-Jørgensen" <[email protected]> said: > Juliusz Chroboczek <[email protected]> writes: > >> For discovery, multicast is unavoidable -- there's simply no way you're >> going to send a unicast to a node that you haven't discovered yet. > > Presumably the access point could transparently turn IP-level multicast > into a unicast frame to each associated station? Not sure how that would > work in an IBSS network, though... Does the driver (or mac80211 stack) > maintain a list of neighbours at the mac/phy level? > > -Toke > _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
