[CQ] Reality check on Amateur Mesh Networking

[Bruce Perens]

I attended Jason's talk at Pacificon today. It seemed to me that there 
was a concatenation of optimistic assumptions in the talk.

To get a reality check on mesh networking, please take a look at David 
Rowe's "Mesh Potato" effort and his deployment of a mesh telephony 
network in Dili, Timor Leste. In the post at 
http://www.rowetel.com/blog/?p=652
Rowe discusses why a commercial Wimax device works well, even in Timor 
Leste, when his own mesh network doesn't.

Also note that Rowe has created a 100% open mesh wifi design and is 
having it manufactured, and has a history of success in manufacturing 
Open Hardware - his Blackfin Asterisk PBX is great.

Jason showed a 150 mile wifi link as an example. While these things are 
possible when all of the conditions are met, it's more the case that the 
average ham won't achieve line-of-sight to even one other node. This is 
the main reason that hams are still using D-STAR, AX-25, etc. We can do 
better than D-STAR, potentially, with spread spectrum on lower 
frequencies than those proposed.

Jason discussed mobile use of the mesh hardware. Has there been any 
testing? I suspect that the multipath and fading issues might be 
underestimated.

Jason offered TDMA as a cure for the hidden-node problem. While a good 
algorithm for doing TDMA in a mesh is probably possible, it's not at all 
clear that we have one yet. The RTS algorithm used on WiFi hasn't worked 
well in practice on Rowe's mesh, in an area that didn't have much "Part 
15" operation to interfere with it. Phil Karn KA9Q designed most of the 
algorithm that was adopted in the WiFi standard, and I'm trying to get 
him interested in why it's failing. I suspect that the well-working 
examples have a star topology.

It's likely that we will lose 44 net in the coming IPV4 address panic. 
Given the use we are making of it presently, it would be responsible of 
us to give it up. Starting with IPV6 would make our lives easier over 
the long run, there is an old TAPR paper on encoding Amateur callsigns 
in IPV6 headers. If your local equipment only does IPV4, run NAT or map 
the Amateur IPV6 subnet to a bank of net 10 addresses.

Codec2 was mentioned as a potential audio payload. Please note that the 
7 byte Codec2 frame is tiny compared to the IP+TCP/UDP/RTP/STCP header 
overhead, and that you either end up wasting most of the packet or 
having really high latency because it takes 4 seconds of speech to fill 
a packet. So, it turns out that a codec with less compression works 
better over IP, Codec2 is intended to run with only one header per 
transmission over the radio link.

I think there are some difficult, unsolved problems that should be 
acknowledged in future talks. It might be best if the potential quoted 
is what you achieve in your own testing.

     Thanks

     Bruce Perens K6BP