Subject: [manet] MANET Transport Protocols

From: "Christopher P. Rigano" <[email-masked]>
Date: Wed, 24 Nov 2004 18:55:38 -0500

Greetings could someone point me to references on MANET Transport and
upper layer protocols.
 
Thanks and happy "turkey",
 
Chris
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: l s <[email-masked]>
Date: Thu, 25 Nov 2004 00:42:05 +0000 (GMT)

Dear researchers,

I have a question for those most familiar with OLSR.

I am comparing AODV and OLSR in lightly loaded
networks.  I am much less familiar with how OLSR
internally operates than I am with AODV.

I have 20 applications running (CBR 4 packets per sec)
in the network of 50 nodes moving Random Way Point in
1500x300.  There is no loss from Queue Overflow.

AODV has 3% Transport Loss (loss occuring somewhere
between departure from the source's transport layer
and arrival at the distination's transport layer)
whilst OLSR has 36% Transport Loss.
The number of Radio Collisions are 3 times lower in
OLSR than in AODV, so where and how is the most likely
way in which the OLSR loss is occuring.

Thanks in advance for your thoughts.

Cheers,
   Lee -S-
   CCSR, Uni of Surrey, UK.

___________________________________________________________ 
Win a castle for NYE with your mates and Yahoo! Messenger 
http://uk.messenger.yahoo.com

---

From: "Francisco J. Ros" <[email-masked]>
Date: Thu, 25 Nov 2004 09:47:12 +0100

Hi,

I guess that mobility could be the cause of your results. With high mobility 
AODV behaves better than OLSR because it can adapt itself fastly to changes 
in the network topology.

Imagine a node must forward a data packet but it has no route for it (this 
happens often in high mobility scenarios). In the case of AODV, the node 
initiates a route search process which may result in a valid route. But OLSR 
simply drops the packet.

If yor network is (almost) static, then forget what I told you ;). Please 
correct me if someone thinks I'm wrong.

Best regards,
Francisco J. Ros

---

From: [email-masked]
Date: Thu, 25 Nov 2004 10:49:38 +0100 (CET)

Hi Lee ;==)

 In OLSR, when a node moves, it goes out of the neighborhood of a node
which may be sending it the data packets. The data packets are lost
because the next-hop node is unreachable. A node keeps an entry about its
neighbor in its neighbor table for about 3 x Hello_interval seconds. If a
neighbor moves which is the next-hop node in a route, the node continues
to forward it the data packets. only after the entry expiration, the link
failure could be detected. Also few of the packets are lost because of
the unavailability. This happen: 1) at the begin of the simulation, a
node need a time to exchange vicinity and topology information to build
its routing table. So, in your simulation, it’s preferable to start
packets transmission after few seconds, and use a default route (a
neighbor node which is an MPR that covers the maximum number of 2-hop
nodes or a simple neighbor is the source node has not yet selected an
MPR). 2) when a node movement causes the node to be disconnected from the
network temporarily.

OLSR (with hello interval of 2 secondes, and neighbor entries life time of
6 secondes) supports the mobility of nodes but at low speeds. When the
speed increases, packet loss increases. To deal with this problem (high
speeds), you can decrease the hello interval and neighbor life time
values. This is the objective of the Fast-OLSR protocol. Fast-OLSR is
proposed by INRIA & LRI laboratories. You can see this paper: “Analysis
and simulation of Fast-OLSR”  In proceedings of the 57th IEEE Semiannual
Vehicular Technology Conference (VTC), Jeju Korea, April 2003.

Hakim.

---

From: Philippe Jacquet <[email-masked]>
Date: Thu, 25 Nov 2004 14:56:51 +0100

Hello,

Please notice that fast OLSR is in some way included in the RFC with variable
Hello rate time and variable neighbor holding time. I also agree with Francisco
that the discrepancies could also come from link buffering or link failure
notification options. 

Philippe

-- 
Philippe Jacquet
Hipercom project team leader
INRIA
tel: +33 1 39 63 52 63
fax: +33 1 39 63 55 66

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.