[Olsr-dev] OLSR on OLPC?

[Sven-Ola Tücke]

Hi Scott,

here are some thougts which may be of interest. Please apologize if the 
following is boring...

Presumably, a layer 3 protocol such as OLSR is not suitable for that scenario 
because of the underlying layer 2 mechanisms. We basically use the ad-hoc 
(ibss) wifi mode as well as a "hardware zoo" with different card vendors / 
driver versions / operating systems. With the nodes scattered in a larger 
area (city). Which means also: only a small number of neighbours per node, 
nodes do not move.

If you have such a high node count in a dense area, you presumably need an 
instance which coordinates medium (air) access, such as a master node or 
simply an access point or such. Yes - OLSR also runs with an access point and 
a couple of attached clients. Anyhow: to our experience, the following will 
happen if you place 100 ad-hoc nodes (a selection from the hardware zoo) into 
a single room without any countermeasures:

a) every node sends out it's beacon every 1/10 second at 1mbit/s. You loose 
50% of the air time if you do not lower the beacon rate or send them with a 
faster rate. Most wifi drivers do not offer a function to set the beacon tx 
rate. Some will not send out becaons if they hear other traffic - most will 
not -> interference.

b) typical wifi card in IBSS mode immediately responds to Probe-Request 
packets with a Probe-Answer packet. A chip internal function. A typical geek 
has 5 additional wifi capable gadgets in his pockets. Which will send out 
probe requests if switched on and seeking e.g. a wifi access point. Now two 
of those geeks enter the room. Sums up to 10 probe requests per second 
answered by 100 ibss nodes. Which consumes the other 50% of the airtime. Most 
wifi drivers do not offer a function to switch off automatic probe-responds.

c) next is the chip/driver internal neighbour table. Typically, a wifi chip / 
driver combination manages a table of neighbours with ~ 8-16 entries. To 
manage e.g. the rate to use / mode / modulation / rssi of the respective 
neighbours. 100 neighbours is a lot more than 8-16...

These (and other things, such as RTS/CTS [...]) will prevent you to 
send/receive a single ping in that room. No ping -> no OLSR routes -> no 
payload.

P.S. As far as I understand your original post, you are in a more comfy 
position: single wifi vendor and controlled config as well as access to 
source / specs / chip design. The nortel guys are right: separating control 
from payload will help. They will have the experience from their 3G/4G lab 
(UMTS/IMS2k/?). Data separation on a single channel is possible only by a 
decent and coordinated timing (in micro/nanoseconds), which normally requires 
a master instance / node. Maybe the IBSS on 5 Ghz (dot-H) is worth a look: 
AFAIK the standard requires the election of a so called "channel master", 
e.g. to send out a "switch channel command" if a military radar signal is 
detected. The madwifi driver has code included for that, but nobody has 
successfully deployed a 5 Ghz IBSS mesh (also AFAIK).

// Sven-Ola

Am Mittwoch 04 Juni 2008 19:26:45 schrieb C. Scott Ananian:
[snip}
>  d) discovering your experience with OLSR in dense networks: if I put
> 100 machines in a single room running olsrd, does the network break
> down due to discovery traffic?
[snap]