[Olsr-dev] OLSR on OLPC?
Thu Jun 5 08:18:00 CEST 2008
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
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).
Am Mittwoch 04 Juni 2008 19:26:45 schrieb C. Scott Ananian:
> 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?
More information about the Olsr-dev