I had hoped to bring this up at the meeting that was canceled for this month.
I have been trying to understand the cause(s) of poor performance on the SD mesh network that persists even after the move to "channel -2", 2397 MHz. Part of the problem is the OLSR route "flapping" and temporary routing loops I observed and reported on earlier, but I don't believe that's the whole story. I see a lot of ping time variability even when the links are unloaded and routing is stable, so I suspect it has to do with the transmitter control mechanisms in 802.11 WiFi.
I am not confident I understand all of the differences between the "ad hoc" mode that the mesh nodes currently use and the "managed" or "access point" mode used by the vast majority of WiFi devices. There may be some advantages to "access point mode" for the more central, fixed-site nodes so I would like to conduct a simple experiment.
As far as I can tell, my node (ka9q-north) is the only radio peer of w6qar-wts, the south-facing node on Qualcomm building WT. (It sees several other nodes, but there are better routes to them through -wte or -wtn.) I propose temporarily reconfiguring -wts to operate as an access point and my own station as a client of that access point, conducting ping and throughput tests of that specific link both before and after the change. If performance significantly improves in access point mode, I would suggest a wider experiment in which more high level nodes (e.g., all three atop Qualcomm) operate in access point mode and lower-level nodes (e.g., on our houses) operate as clients of those access points. The ESSID would not necessarily have to change as clients automatically associate with the strongest access point with the specified ESSID. OLSR routing would continue as before, so the network would not change as seen from any other nodes.
Although the regular AirOS firmware doesn't support out-of-band operation and the AREDN firmware doesn't (AFAIK) officially support access point mode, I may still be able to reconfigure the latter temporarily with the 'iw' shell command. I'd just need root access to the w6qar-wts node.
Gene, Conrad, any objections or suggestions?
KA9Q, I've been wanting to do this same test, so very interested. Another possibility impacting performance is related to what is delaying the 3.15.1.0 release. The Ambient Noise Immunity capability may not be behaving very well in outdoor RF congested environments. There's a tendency and periods of time when ANI causes the Atheros chip to go into rapid calibrations and resets which would not be conducive to throughput. (It was worse turning off ANI.)
See: https://www.mail-archive.com/search?l=ath9k-devel@lists.ath9k.org&q=subj...
Joe AE6XE
Excellent! If you do, please distribute your results.
Way back in 1990 I invented a collision-avoidance scheme for the hidden-terminal problem I called MACA and published it in the ARRL/TAPR DCC proceedings. I never did much with it, but it got picked up by Xerox PARC and then the IEEE 802.11 working group and made a part of their medium access protocol. There are actually two versions: an explicit request-to-send/clear-to-send (RTS/CTS) data exchange as I originally proposed but which almost everyone disables, and an implicit holdoff mechanism piggybacked onto every frame that is, as far as I can tell, always on. This latter scheme was original with IEEE and I think it's the better implementation.
My basic idea was to announce when you expect a response to something you send so that other stations within range, who might not be able to hear the other station, know how long to stay off the channel. IEEE implemented this as a "us" (microseconds) field, which you can see by doing a verbose tcpdump on the raw wifi interface (e.g., wlan0-1).
Unicast data packets carry this field to allow for the expected link-level ack, but broadcasts (ARP, OLSR Hellos) do not (they specify 0 us). Since our links carry a great deal of broadcast traffic, sent at the lowest data rate (usually 1 Mb/s) because you don't know what the listeners can actually receive, and because our links operate in ad-hoc mode, I suspect that there are a lot of co-channel collisions between these transmissions. In managed/base station mode, the clients transmit only when polled by the base station so collisions cannot occur between clients even if they can't hear each other. I believe the base station still respects holdoff requests it overhears from other SSIDs sharing the channel, so this will also keep the clients from stomping on those other stations even if they can't hear them directly.
Then there are the beacon frames. In managed mode, a base station transmits a beacon every 100 ms, announcing its SSID (this is what you see when you do a scan) and scheduling transmissions to and from its clients. (Clients can go to sleep until the next scheduled base station transmission, thus saving battery power.) Client stations don't transmit beacons, but in ad-hoc mode everybody does -- 10 per second from everybody, all the time. With lots of hidden terminals I'm sure there are plenty of opportunities for problems.
One drawback to base station mode is that two clients must communicate through the base station even if they can hear each other, but with our directional links I suspect that wouldn't happen very often anyway. Another is that you can't just slap a node on the air and have it configure itself into the mesh; you have to configure it as either a base station or a client, and you have to give some thought to that. But since our network (so far) consists of fairly stable nodes in fixed locations, I don't see this as a serious problem. A node (particularly at high altitude) with multiple peers in its beam should probably be configured as an access point; a node with just one primary peer in its beam should probably be a client.
Joe, can you point me to any documentation on ANI? Is it part of 802.11 or is it proprietary to the Atheros chips?
Proprietary to Atheros. No documentation except reverse engineer the code and reference the patent: http://www.freepatentsonline.com/7349503.html . This is linux wireless ath9k with back-port to linux 3.10.49 (compat wireless 2014-05-22) and some OpenWrt tweaks on top in Barrier Breaker.
I believe switching to AP mode may actually cause more issues right now than it would solve.
I took a previous topology image from a few months back from here: http://www.aredn.org/content/san-diego-topology ( a few nodes have been added, removed or moved, but the overall mesh is still the same)
If we were to switch all the central, mid mile nodes as they are called in the San Diego deployment(these would be the Qualcom, Sleeping Indian, Oceanside West, Crest and SAREDN nodes), to some sort of AP mode San Diego county would end up with a significant reduction in redundant linking AND would actually end up with 7 isolated mesh networks where today we have one single mesh.
This can be seen in this image (Sorry it was a fast edit, not very clean) https://www.dropbox.com/s/yfpu0mg5pneqsrx/SD%20Mesh%20Topology%20using%20AP%20Mode.png?dl=0
Each isolated network is outlined in red, RF paths that could no longer occur due to everything via the AP were removed as well. Hard links were kept because they still apply
Even when the backbone is added these redundant links add a significant amount resilience and flexibility to the network should anything with the backbone ever occur. Right now I have 2 paths to San Diego, in this proposal I would be down to 1 with the lost of Qualcom North, and eventually with 0 with the loss of a few mid steps in our network
I do see one advantage to switching to AP mode however, it would immediately stop users from using a mesh node locally (inside a house, or in a car, etc) to relay through a "power node" (outdoor node aimed at the existing infrastructure) and force users to run a wired line to the operation or setup a part 15 AP. This would remove some duplicate and RF clogging traffic from the network Overall though as the mesh stands today in San Diego taking this sort of action would just fragment the network.
Nothing says that every node would have to become an access point or a client of some other access point. The idea is simply to experiment, to compare the performance of a group of nodes operating in one mode or the other and to better understand exactly how the multiple-access algorithms behave in practice with lots of hidden terminals and especially with a lot of broadcast traffic that has to be sent at the lowest common data rate and which cannot benefit from the collision avoidance mechanisms.
Broadcast traffic is a serious issue, and it's made worse by the duplication of similar mechanisms at different layers. Beacons are physical broadcasts intended to help nodes discover each other and to measure link quality. But the network layer routing algorithm (OLSR) knows nothing about them, so it has its own broadcast mechanism (HELLO packets), carried as data by the physical layer, to discover neighbors and monitor link quality. Operating a group of nodes as an access point with clients may be just one way to let the physical layer better assist the network layer; I'm sure there are others.
Phil, have you looked at OLSRv2? I wonder what you think of it?
It's on my list...
I'm particularly interested in seeing how (or if) nodes coordinate changes to their routing tables so as to avoid temporary routing loops.
I understand Atheros AR9287 and later chips support simultaneous station and AP mode.