Subject: [manet] MANETs and 802.11?

From: Claudio Lavecchia <[email-masked]>
Date: Fri, 10 Dec 2004 12:30:17 +0100

Hello you MANET people,

I have a very general question.
I am running test on a simple 2-hops MANET. Briefly my testing scenario 
is the following: I have 2 ipaqs and a laptop. Those 3 devices have 
PCMCIA 802.11 WLAN cards (2 Dell Truemobile 1150 and a Cisco Aironet 
350). I configure those devices to belong to the same ad-hoc network 
(set the frequency to 2.422GHz) and route the network using unik-OLSR, a 
very popular OLSR implementation. Then I try to do a multi-hop ftp 
session. The result of this simple test is a little deception: routes 
are not stable and the network connectivity and response time seems to 
be, in general, very poor. So the question that comes to my mind is: am 
I doing something wrong or 802.11 is not suitable for real-life 
implementation of MANETs? I would like to have your detailed opinions.

Thx

Claudio

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Ramón Agüero<[email-masked]>
Date: Fri, 10 Dec 2004 13:06:36 +0100

Hello Claudio,

The question you raise it's, IMO, quite a hot topic. It's clear enough that 
current IEEE 802.11 implementations are not yet prepared for deploying real 
test-beds. The current specification defines an ad-hoc 802.11 cell as a 
number of STA that are within the same coverage area, going clearly against 
with the basis of multi-hop networking. In this sense, when you try to 
separate, lets say, the two edges of the communication (so as to force them 
to route traffic through an intermediate node), they would eventually loose 
connection (from the point of view of 802.11). This causes some 
inconsistencies and instability, as even in ad-hoc mode of operation, nodes 
within the same 802.11 cell are interchanging signalling traffic 
(beacons,...). Lets hope that mesh networking study group helps to 
alleviate this shortcoming.

What you can do (I don't now even whether you were actually using this) is 
MAC filtering. In this case, you "virtually" disconnect the devices but, 
from the 802.11 point of view, the connectivity is still ok. Another 
alternative may be to use two different interfaces at the intermediate 
nodes (one of each connected to one of the edges), but I prefer the former 
one.

I've tried to give my personal experience about this issue, but maybe 
others have additional ideas or tricks that can be used. I've sometimes 
heard experimental trials based on IEEE 802.11 cards within open fields, in 
which thinks, at least, worked. Nevertheless, I hope that this may help you 
to better understand the problem you *may* be facing.

Regards,

Ramón

At 12:30 10/12/2004, Claudio Lavecchia wrote:
>I am running test on a simple 2-hops MANET. Briefly my testing scenario is 
>the following: I have 2 ipaqs and a laptop. Those 3 devices have PCMCIA 
>802.11 WLAN cards (2 Dell Truemobile 1150 and a Cisco Aironet 350). I 
>configure those devices to belong to the same ad-hoc network (set the 
>frequency to 2.422GHz) and route the network using unik-OLSR, a very 
>popular OLSR implementation. Then I try to do a multi-hop ftp session. The 
>result of this simple test is a little deception: routes are not stable 
>and the network connectivity and response time seems to be, in general, 
>very poor. So the question that comes to my mind is: am I doing something 
>wrong or 802.11 is not suitable for real-life implementation of MANETs? I 
>would like to have your detailed opinions.
>
>Thx
>
>Claudio
>

---

From: "John P. Mullen" <[email-masked]>
Date: Fri, 10 Dec 2004 08:40:50 -0700

Hi Claudio,

I think the best view is that multihop communications is not as easy as it
looks.  A problem several field workers has reported is that, primarily due
to multipath fading, the received signal is highly variable.  This means
that from time to time, a RREP is received over an unreliable link, causing
an unreliable route to be set up.  When the route is used, the low
reliability triggers a new search, with a chance for the same thing to
happen.

Some sort of MAC filtering will definitely help.  Here is a paper that looks
into that problem.  

http://portal.acm.org/citation.cfm?id=774758

However, remember that although filtering helps, it does not completely fix
the problem.  I'd say that if you are getting above 50% of the throughput
simulation indicates you should have, you are doing pretty good.

John Mullen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Claudio Lavecchia
Sent: Friday, December 10, 2004 4:30 AM
To: [email-masked]
Subject: [manet] MANETs and 802.11?

Hello you MANET people,

Thx

Claudio

---

From: Brown Tim <[email-masked]>
Date: Fri, 10 Dec 2004 10:02:51 -0700 (MST)

Another little problem to watch out for is with the Cisco Aironet 350.
If the card is placed in ad hoc mode, we have observed in some versions of
the firmware an undesireable "feature". This feature cuts the throughput
in half and can add up to 125msec delays to packet delivery times. In ad
hoc mode, the card alternates between sending your packets and probing
other channels for other ad hoc networks.  The cycle is about 250msec with
half spent sending your packets and the other half searching. This is easy
to see by observing a file transfer with a spectrum analyzer.
	Regards,
		Tim

> implementation of MANETs? I would like to have your detailed opinions.

Timothy X Brown
Interdisciplinary Telecommunications
Electrical and Computer Engineering
ECOT 256 Campus Box 530
University of Colorado
Boulder, CO 80309
Tel: (303) 492-1630
Fax: (303) 492-1112
http://ece.colorado.edu/~timxb

---

From: David Young <[email-masked]>
Date: Fri, 10 Dec 2004 11:53:53 -0600

> implementation of MANETs? I would like to have your detailed opinions.

Claudio,

802.11 is suitable.  I think that on your network, you are probably
seeing the interaction of shortcomings in both the WLAN cards and OLSR.

On an 802.11 network, no multicast Hello protocol can be expected to
provide a reliable link indication while the link is heavily in use by
a unicast stream, like your FTP session.

Some 802.11 implementers foolishly believe that the number of 802.11
beacons received provides a useful "link quality" indication.  They cease
transmitting/receiving and start to scan if no beacon is heard in 10
consecutive beacon intervals.

802.11 cards commonly have ad-hoc mode implementations that are
susceptible to "IBSS splits."  Your TrueMobile card probably uses the
Intersil Prism chipset---if you are not running station firmware 1.4.9
or higher, try upgrading.  Even 1.4.9 will misbehave on ad hoc networks,
but it's safe to say that running any earlier version will disappoint you.
I don't know if there is a version of the Cisco Aironet firmware that
is not susceptible to IBSS splits.

Dave

-- 
David Young             OJC Technologies
[email-masked]      Urbana, IL * (217) 278-3933

---

From: Dave Maltz <[email-masked]>
Date: Fri, 10 Dec 2004 17:58:51 -0500

--On Friday, December 10, 2004 8:40 AM -0700 "John P. Mullen" 
<[email-masked]> wrote:

> looks.
<snip/>
> Some sort of MAC filtering will definitely help.  Here is a paper that
> looks into that problem.
>
> However, remember that although filtering helps, it does not completely
> fix the problem.  I'd say that if you are getting above 50% of the
> throughput simulation indicates you should have, you are doing pretty
> good.

As reported in our paper "Quantitative Lessons From a Full-Scale Multi-Hop 
Wireless Ad Hoc Network Testbed." In Proceedings of the IEEE Wireless 
Communications and Networking Conference, IEEE, Chicago, September 2000
http://www.monarch.cs.rice.edu/monarch-papers/wcnc2000.ps

we found that using macfiltering to prevent the discovery of "routes with 
too few hops" improves TCP throughput performance by 30%.  However, that 
still leaves a long way to go to achieve the throughputs measured on either 
ns-2 or a lab bench.  For example, on a lab bench using macfilter to create 
a synthetic topology of three nodes communicating with 2 Mbps radios, we 
recorded TCP throughput of .5 Mbps.  Moving to the field, with macfiltering 
preventing the discovery of "bad" routes, we measure ~.16 Mbps.  Without 
the macfiltering, we measure .12Mbps.

Cheers,
 -dam

---

From: Imad Aad <[email-masked]>
Date: Mon, 13 Dec 2004 17:33:09 +0100 (CET)

Dear colleagues,

We are organizing a one-day workshop within the WiOpt Symposium
(http://www.wiopt.org) to be held in April next year in Riva del Garda,
Italy. Riva del Garda is in Northern Italy, which is quite close to 
Venice.

Our workshop is entitled "Network Coding, Theory, and Applications", and 
we have put up a workshop web page at http://www.netcod.org.  The scope of 
the workshop includes network coding and multiuser information theory.  If 
you have any recent work related to these topics, please consider 
submitting to our workshop.  The deadline for submission is Dec 17, 2004.

In addition to NetCod, three other workshops will be held in conjunction
with the WiOpt Symposium.  For further information, please refer to the
Symposium homepage.  We look forward to seeing you at the Workshop and the 
Symposium.

With best regards,
Raymond Yeung, Workshop Chair
http://www.ie.cuhk.edu.hk/whyeung
Phil Chou, Technical Program Chair
http://research.microsoft.com/users/pachou/

---

From: Imad Aad <[email-masked]>
Date: Mon, 13 Dec 2004 17:52:46 +0100 (CET)

Our appologies if you receive multiple copies of this CFP.

                     CALL FOR PAPERS
                     ===============

                          RAWNET
   Workshop on Resource Allocation in Wireless Networks
                   http://www.rawnet.org

               In conjunction with WiOpt 2005
                 April 3, Trentino, Italy

This workshop focuses on models and techniques for addressing resource
allocation problems in wireless networks. Resource management in wireless
environments is extremely complex due to the specific characteristics of
wireless communications, such as user mobility, interference, the
intrinsically scarce bandwidth, and the highly variable and unpredictable
propagation conditions. These features present a vast range of novel and
fundamental challenges as wireless networks evolve to support an expanding
variety of data applications. In particular, data streams have drastically
different traffic characteristics and Quality-of-Service requirements from
voice services, urging a radical overhaul of voice-centric air-interface
and resource allocation paradigms. In addition, existing congestion 
control
protocols for data flows like TCP were originally designed for wireline
networks, and are not well-suited to wireless links which are inherently
slow and error-prone. A further dimension of complexity stems from the
growing diversity in network architectures, as wireless LAN's and ad hoc
networks rapidly proliferate, giving rise to a wide spectrum of pricing 
and
routing issues.

Specific topics of interest include (but are not limited to):

    * air-interface scheduling
    * cross-layer design
    * dimensioning, provisioning and traffic engineering
    * load balancing and routing
    * models and techniques for optimization of wireless networks
    * performance evaluation methods for wireless networks
    * power control and energy-efficient communication
    * pricing and incentive schemes in ad hoc networks

Important Dates
===============

Submission deadline:    December 17, 2004
Notification date:      February 11, 2005
Camera-ready due:       February 26, 2005

Papers should be formatted according to the IEEE double-column standard
format with 11 pt font size. The maximum length of the manuscript is 6
pages. This limit includes figures, appendix, bibliography, etc. Papers
must be submitted in PDF. Paper submission is managed by the EDAS system:
http://edas.info. If you do not have an EDAS account, please create one
first.

Program Chairs
==============

Sem Borst <mailto:[email-masked]>
           Bell Labs, Lucent (USA) and CWI (The Netherlands)

Alexandre Proutiere <mailto:[email-masked]>
           France Telecom R&D, France

Technical Program Committee
===========================

Rajeev Agrawal          Motorola, USA
Chris Blondia           University of Antwerp, Belgium
Thomas Bonald           France Telecom R&D, France
Richard Boucherie       University of Twente, The Netherlands
Costas Courcoubetis     Athens University of Economics and Business, 
Greece
Piyush Gupta            Bell Labs, Lucent, USA
Riku Jantti             University of Vaasa, Finland
Leonidas Georgiadis     CERTH, Greece
Sindo Nunez Queija      CWI, The Netherlands
Phuoc Tran Gia          University of Wuerzburg, Germany
Venu Veeravalli         University of Illinois at Urbana-Champaign, USA
Harish Viswanathan      Bell Labs, Lucent, USA
Phil Whiting            Bell Labs, Lucent, USA