[CUWiN-Dev] Visualization Question:

[Stephane Alnet]

>>> I had a quick question that came up at the FCC regarding the mapping 
>>> of
>>> the network.  Let's say that Geek A adds latitude and longitude, 
>>> then Geek
>>> B (one year later) moves the node to a new location but neglects the
>>> geolocation information, meaning that the node is now announcing
>>> inaccurate information.  How does our mapping deal with this?
>>
>> The node will be displayed at the wrong location.
>
> We use a "springs" layout algorithm.  If many nodes have been "tacked"
> to the map using their GPS coordinates, then the springs attached to a
> misplaced node may be under much greater strain than the springs 
> attached
> to other nodes.  If we choose the color of each node to reflect the sum
> of the potential energy in its attached springs, maybe misplaced nodes
> will stand out.

When a node is displaced, the neighboring nodes are going to appear as 
being co-located (say, downtown Champaign), but all located some 
distance away from the registered position of the displaced node (say, 
downtown Urbana). (In that case the node was moved from downtown Urbana 
to downtown Champaign.) It should be somewhat obvious from looking at 
the drawing that the node is not tolopogically located where it is said 
to be geographically located. (The drawing would show a bunch of lines 
going from different nodes in downtown Champaign to that single node in 
"downtown Urbana".)

One simplistic approach to automatically detect these nodes could be to 
look for inter-node distances that are outside of reach (from a 
wireless standpoint) under "normal" conditions (based on the hardware 
deployed). Specific links (using point-to-point amplifiers, etc.) could 
be tagged to make sure they don't get trimmed as abnormal (because they 
are by design).

One could also take the reverse path of thought and use both 
neighboring information (provided by the routing tables) and power 
levels (or ETX metrics) seen by the different nodes to create a 
topological map of the network and tag any major changes over time 
(using, say, daily or weekly averages) to detect displaced node. 
Collecting this kind of metrics would be interesting from a network 
health monitoring in any case. (A la "mrtg/smokeping".)

Moreover, and this is maybe a better idea, one could combine this 
(topological) map information with a few, well-known reference nodes 
(for which the geographical location can be established with certitude 
and verified at regular intervals), and create (using a spring model) a 
topological/geographical map. (I guess what I'm saying is that we don't 
need to know the geographical location of _all_ the nodes to establish 
the location of an unknown node; the "fuzzy triangulation" done by 
using the topological metrics (signal levels, ETX values, ...) and the 
spring model should be sufficient to produce an intelligible map. 
Moreover that new map would have the advantage of displaying "moving" 
nodes at their approximate location, thus eliminating the "geolocation 
update" problem completely. Something like this: 
http://www.shimaore.net/CUWireless/map/ )

S.

PS: Dave, this is based on the Java applet I've being mentioning for 
some time. It uses different colors to indicate the stress on a link, 
as you mentioned, or can display the stress as a value. In the demo I 
used "100+dB level" as the target value (one would need some metric 
that is proportional with distance and has some physical meaning, this 
one doesn't meet either criteria).