[olsr-dev] Combating hidden nodes using token-passing
Thu Jul 28 08:55:57 CEST 2005
I've recently taken an interest in OLSR networks after a long time of being
a staunch advocate of infrastructure-style wireless networking.
Some of us in the Melbourne Wireless group have been tinkering with the
developed by WAFreeNet.
It uses a master/client polling method to overcome the hidden-node problems
that occur with the 802.11 CSMA/CD media access method. It uses the
Iptables userspace QUEUE module to hold back traffic and release it only
when polled by the master. It's a Layer 3 solution to a Layer 2 problem and
it works well - and being layer 3 it is chipset agnostic - it works with any
wireless card. It even works with every stand-alone Access Point in
existence if you connect it to a Linux box.
Recently we were contacted by a wireless group who operate in the Himalayas
- they are using OLSR and they are having hidden-node issues with their mesh
network. As you can imagine - with some nodes on top of huge mountains and
some in valleys, a good portion of the nodes in the network are hidden from
each other. They are using Frottle, but it's current architecture limits it
to one master node per subnet - nodes that are more than one hop from the
master can't effectively participate in the network.
We are beginning to think about a way of using Frottle on a mesh network.
It currently is only really suitable for an infrastructure-style network
with an AP that polls it's clients to transmit in turn. We've decided that
a token-passing media-access method is the way to go - and it turns out this
method has been the subject of a lot of academic research for some years
Some Googling turned up these papers:
An overview of a Wireless Token Ring Protocol - a good intro, but lacking in
Distributed Token Circulation on Mobile Ad Hoc Networks
This paper reviews the different algorithms used to pass a token around all
the nodes on a mesh network.
Some of the more efficient methods for passing tokens around require that
each node have a good idea of the overall topography of the mesh network -
and this, of course, is information that is gathered by OLSR. However, a
program like Frottle will only work properly if it has absolute control over
when data is transmitted - OLSR transmissions would have to wait until
Frottle is polled (or receives the token). So a mesh version of Frottle
will have to send out it's own Hello packets to discover other nodes - at
least in the inital discovery stages.
At some point we are going to have a go at developing a token-passing
version of Frottle. We're still at the thinking stage at the moment. We
want to get a basic, stand-alone version working first.
The ultimate goal is to increase the efficiency of the token-passing using
the data gathered with OLSR. We are interested in hearing from anyone who
is interested in, thinking about, or working on a project like this.
More information about the Olsr-dev