Multi Hop Wireless Network & OLSR

[jernst]

Hi everyone, I am trying to experiment with a multi hop wireless
network (wireless mesh) and am using ad-hoc mac along with OLSR
routing. However it seems whenever the destination is more than 2 hops
away the routing fails and I am having trouble finding out why. For
example 3 nodes in a straight line will work but when I add a fourth
it fails. Similarly in a grid pattern, with more than 2 hops it also
fails. Here is my simulation scenario (sorry for the length):

#include <iostream>
#include <fstream>
#include "ns3/core-module.h"
#include "ns3/common-module.h"
#include "ns3/node-module.h"
#include "ns3/helper-module.h"
#include "ns3/mobility-module.h"
#include "ns3/contrib-module.h"
#include "ns3/wifi-module.h"
#include "ns3/global-route-manager.h"

NS_LOG_COMPONENT_DEFINE ("mesh");
using namespace ns3;

int main(int argc, char ** argv)
{
Packet::EnablePrinting ();

// enable rts cts all the time.
Config::SetDefault
("ns3::WifiRemoteStationManager::RtsCtsThreshold", StringValue
("2200"));
// disable fragmentation
Config::SetDefault
("ns3::WifiRemoteStationManager::FragmentationThreshold", StringValue
("2200"));

//Containers to hold nodes and devices
NodeContainer MRNodes;
NetDeviceContainer MRDevices;
MRNodes.Create (6);

//wireless setup
WifiHelper wifi = WifiHelper::Default ();
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default
();
wifiPhy.SetChannel (wifiChannel.Create ());
wifi.SetMac ("ns3::AdhocWifiMac");
wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",
"DataMode", StringValue ("wifia-6mbs"));
MRDevices = wifi.Install (wifiPhy, MRNodes);

//add ipv4 and routing
InternetStackHelper internet;
internet.Install (MRNodes);
Ipv4AddressHelper ipAddrs;
ipAddrs.SetBase ("192.168.0.0", "255.255.255.0");
ipAddrs.Assign (MRDevices);
//GlobalRouteManager::PopulateRoutingTables ();

// mobility
MobilityHelper mobility;
Ptr<ListPositionAllocator> positionAlloc =
CreateObject<ListPositionAllocator> ();
positionAlloc->Add (Vector (0.0, 0.0, 0.0));
positionAlloc->Add (Vector (150.0, 0.0, 0.0));
positionAlloc->Add (Vector (300.0, 0.0, 0.0));
positionAlloc->Add (Vector (0.0, 150.0, 0.0));
positionAlloc->Add (Vector (150.0, 150.0, 0.0));
//positionAlloc->Add (Vector (300.0, 150.0, 0.0)); //doesnt work
with this one
positionAlloc->Add (Vector (0.0, 300.0, 0.0));
mobility.SetPositionAllocator (positionAlloc);
mobility.SetMobilityModel ("ns3::StaticMobilityModel");
mobility.Install (MRNodes);

OlsrHelper olsr;
olsr.Install(MRNodes);

uint16_t port = 80;
Ptr<Node> appSource = NodeList::GetNode (0);
Ptr<Node> appSink = NodeList::GetNode (5);
Ipv4Address remoteAddr = Ipv4Address ("192.168.0.6");
OnOffHelper onoff ("ns3::UdpSocketFactory",
Address (InetSocketAddress (remoteAddr, port)));
onoff.SetAttribute ("OnTime", RandomVariableValue (ConstantVariable
(1)));
onoff.SetAttribute ("OffTime", RandomVariableValue (ConstantVariable
(0)));
ApplicationContainer apps = onoff.Install (appSource);
apps.Start (Seconds (1.5));
apps.Stop (Seconds (10.0));

// Create a packet sink to receive these packets
PacketSinkHelper sink ("ns3::UdpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny (),
port));
apps = sink.Install (appSink);
apps.Start (Seconds (1.5));

NS_LOG_INFO ("Configure Tracing.");
std::ofstream ascii;
ascii.open ("mesh.tr");
YansWifiPhyHelper::EnableAsciiAll (ascii);
CsmaHelper::EnableAsciiAll (ascii);
YansWifiPhyHelper::EnablePcap ("mesh", MRDevices);
CsmaHelper::EnablePcap ("mesh", appSink->GetId (), 0);

Simulator::Stop (Seconds (11.0));
Simulator::Run ();
Simulator::Destroy ();

[jernst]

Nevermind, I seem to have found my solution after reading some
previous posts and some tinkering. It seems I wasn't leaving enough
time for OLSR to do its work. Now that I've started the application
traffic after a longer wait (100s) it seems to work fine! Sorry for
the trouble!

[Gustavo Carneiro]

2009/3/9 jernst <jer...@uoguelph.ca>

Nevermind, I seem to have found my solution after reading some
previous posts and some tinkering. It seems I wasn't leaving enough
time for OLSR to do its work. Now that I've started the application
traffic after a longer wait (100s) it seems to work fine! Sorry for
the trouble!

I think it's not just OLSR that needs to do its work.  OLSR should converge in much less than 30 seconds.  Probably it's that old "problem" (for lack of better word) of 802.11 rate control not adapting unicast rate fast enough.  The sort of thing you never think about, analytically, but which reality, or an accurate simulator, never forgives :-)
 

--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[Mathieu Lacage]

On Mon, 2009-03-09 at 17:32 +0000, Gustavo Carneiro wrote:

> Nevermind, I seem to have found my solution after reading some
> previous posts and some tinkering. It seems I wasn't leaving
> enough
> time for OLSR to do its work. Now that I've started the
> application
> traffic after a longer wait (100s) it seems to work fine!
> Sorry for
> the trouble!
>
> I think it's not just OLSR that needs to do its work. OLSR should
> converge in much less than 30 seconds. Probably it's that old
> "problem" (for lack of better word) of 802.11 rate control not
> adapting unicast rate fast enough. The sort of thing you never think
> about, analytically, but which reality, or an accurate simulator,
> never forgives :-)

This looks like a great candidate for the "ns-3 quote of the week" :)

Mathieu

[Tom Henderson]

Gustavo Carneiro wrote:
>
>
> 2009/3/9 jernst <jer...@uoguelph.ca <mailto:jer...@uoguelph.ca>>

>
>
> Nevermind, I seem to have found my solution after reading some
> previous posts and some tinkering. It seems I wasn't leaving enough
> time for OLSR to do its work. Now that I've started the application
> traffic after a longer wait (100s) it seems to work fine! Sorry for
> the trouble!
>
>
> I think it's not just OLSR that needs to do its work. OLSR should
> converge in much less than 30 seconds. Probably it's that old "problem"
> (for lack of better word) of 802.11 rate control not adapting unicast
> rate fast enough. The sort of thing you never think about,
> analytically, but which reality, or an accurate simulator, never
> forgives :-)
>

Since this rate control convergence seems to trip up users repeatedly,
we probably need to document better that Arf rate control typically
needs a large amount of time or packets to converge. OLSR gets a bad
reputation from this phenomenon.

Or else, do not use Arf and use something like constant rate for the
default in the wifi helper. However, that will probably in the long run
be more harmful because it will not lead to better methodology (i.e.
users need to understand and be able to check that their simulations
reach a steady state). So, I'd vote for making an OLSR ad hoc example
and putting some explicit startup delay in the script, accompanied by a
comment about this behavior.

Tom

[bea]

Hello!

i am testing OLSR in WMN's. I have started with an UdpEchoAplication
from n0 to n2 located this way:


n4 n5 n6 n7

* * * *

* * * *

n0 n1 n2 n3



it works. But there are two cases that don't:



a) from n0 to n6: n0 receives olsr information from n6. So, n0 try
to send the 'ip datagram' to n6, but it doesn't arrive to its
destination.



b) from n0 to n7: n0 doesn't receive olsr information from n7, they
haven't line of sight to each other. So, n0 sends the 'ip datagram' to
n1, and n1 tries to send it to n7, but again, it doesn`t arrive to its
destination.



i can't understand why it happens.(I use Wireshark). I wonder if
"broadcast udp packets" for olsr algorithm can reach longer distances
that "ip datagram" and because of that there are nodes that appear to
be reachable.

My simulation is:

int
main (int argc, char *argv[])
{
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);
RandomVariable::UseGlobalSeed (1, 1, 2, 3, 5, 8);
uint32_t nMRouters = 8;
CommandLine cmd;
cmd.AddValue ("nMRouters", "Number of mesh router devices",
nMRouters);
cmd.Parse (argc,argv);

NodeContainer meshNodes;
meshNodes.Create (nMRouters);
InternetStackHelper stack;
stack.Install (meshNodes);

YansWifiChannelHelper channel = YansWifiChannelHelper::Default ();
YansWifiPhyHelper phy = YansWifiPhyHelper::Default ();
phy.SetChannel (channel.Create ());

WifiHelper wifi = WifiHelper::Default ();

wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",
"DataMode", StringValue

("wifia-12mbs"));

wifi.SetMac ("ns3::AdhocWifiMac");

NetDeviceContainer wifiDevices = wifi.Install (phy, meshNodes);

MobilityHelper mobility;
mobility.SetPositionAllocator ("ns3::GridPositionAllocator",
"MinX", DoubleValue (0.0),
"MinY", DoubleValue (0.0),
"DeltaX", DoubleValue (50.0),
"DeltaY", DoubleValue (100.0),
"GridWidth", UintegerValue (4),
"LayoutType", StringValue ("RowFirst"));

mobility.SetMobilityModel ("ns3::StaticMobilityModel");

mobility.Install (meshNodes);

Ipv4AddressHelper address;
address.SetBase ("192.168.0.0", "255.255.255.0");
Ipv4InterfaceContainer wifiInterface;
wifiInterface=address.Assign(wifiDevices);

UdpEchoServerHelper echoServer (9);
ApplicationContainer serverApps = echoServer.Install (meshNodes.Get
(nMRouters-1));
serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (300.0));

UdpEchoClientHelper echoClient (wifiInterface.GetAddress
(nMRouters-1), 9);
echoClient.SetAttribute ("MaxPackets", UintegerValue (1));
echoClient.SetAttribute ("Interval", TimeValue (Seconds (40.)));
echoClient.SetAttribute ("PacketSize", UintegerValue (1024));

ApplicationContainer clientApps =
echoClient.Install (meshNodes.Get (0));
clientApps.Start (Seconds (80.0));
clientApps.Stop (Seconds (300.0));

OlsrHelper olsr;
olsr.InstallAll ();

Simulator::Stop (Seconds (300.0));
YansWifiPhyHelper::EnablePcapAll ("wifi2");

Simulator::Run ();
Simulator::Destroy ();

return 0;
}

Thank you,
Bea

[milo]

Hi,

For now I can give you two possible solutions:

1. Try to use e lower data-rate (this will reduce path loss & increase
distance coverage) i.e. use the default one

wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",
"DataMode",

StringValue ("wifia-6mbs"));

2. Try to use increase distance coverage by reducing path loss
directly (see Exponent) i.e.
replace

YansWifiChannelHelper channel = YansWifiChannelHelper::Default ();

with
YansWifiChannelHelper channel;
channel.AddPropagationLoss("ns3::LogDistancePropagationLossModel",
"Exponent", DoubleValue(2.5)); //
default is 3.0
channel.SetPropagationDelay
("ns3::ConstantSpeedPropagationDelayModel",
"Speed", DoubleValue(3e+08)); // this
is the default one

Although these can give a solution, I cannot find the reason why OLSR
packets can reach those nodes and UdpEcho packets can't. I also tried
with a smaller packet size to imitate OLSR, but the result remains the
same.

Does anyone have an idea why??

Milo

[Mathieu Lacage]

broadcast udp packets are sent using the lowest transmission rate, that
is, the transmission rate with the highest transmission range while
other ip unicast packets are sent using a higher transmission rate, that
is, a transmission rate with a lower transmission range.

Mathieu

[bea]

Thank you!!! Where could i find that information?for example, the
broadcast udp packet transmission rate?

Bea

[Mathieu Lacage]

On Wed, 2009-03-18 at 12:58 -0700, bea wrote:
> Thank you!!! Where could i find that information?for example, the
> broadcast udp packet transmission rate?

it is 6mbs but you can look at the output of NS_LOG=YansWifiPhy to
check.

Mathieu