Trouble with the simplest adhoc simulation

[Asifuddin]

Hi,

I am having trouble running the simplest of adhoc simulations with
ns-3.3-RC6. I
placed three wifi nodes in a linear fashion, each separated by 30
meters as shown:

O- - - - - - -O- - - - - -O
(0,0) (30,0) (60,0)
Dest. Source

The two edge nodes exchange cbr traffic at a rate of 1
pkt/sec. Since they are out of range (total distance 60 meters), the
data must be forwarded through the middle node, which happens to be
in
communication range of both the other nodes. I am trying to use OLSR
to achieve this. But I keep getting the following error.

Test for possibly unreachable code-- please file a bug report, with a
test case, if this is ever hit
Command ['/Applications/ns3/repos/ns-3-dev/build/debug/scratch/
adhoc_3node_test'] exited with code -10

Of course, I tested the code with just two nodes separated by 30
meters and everything works fine.
However, with multihop scenarios, routing seems to be the problem.

Just for grins, I tried using global routing as well and the same
error is produced. I am convinced that I am be doing something very
silly. Could you please point to me in the right direction. My code
is
attached below.

I have also looked at the examples in the distribution. Unfortunately,
the
adhoc example uses 2 nodes and the olsr example uses point-to-point
links.

Thanks,
Asif

/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation;
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Texport
'NS_LOG=*=level_function|prefix_func|prefix_time'emple Place, Suite
330,
Boston, MA 02111-1307 USA
*
*/

#include <fstream>
#include <iostream>
#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"

using namespace ns3;
NS_LOG_COMPONENT_DEFINE ("adhoc_3node_test");

int
main (int argc, char *argv[])
{
Config::SetDefault ("ns3::OnOffApplication::PacketSize",StringValue
("500"));
Config::SetDefault ("ns3::OnOffApplication::DataRate", StringValue
("4kb/s"));

NodeContainer adhocNodes;
adhocNodes.Create (3);

WifiHelper wifi;
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default
();
wifiPhy.SetChannel (wifiChannel.Create ());
wifi.SetMac ("ns3::AdhocWifiMac");
wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",
"DataMode", StringValue
("wifia-54mbs"));
NetDeviceContainer adhocDevices = wifi.Install (wifiPhy,
adhocNodes);

InternetStackHelper internet;
internet.Install (adhocNodes);

Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer adhocInterfaces;
adhocInterfaces = address.Assign (adhocDevices);

MobilityHelper mobility;
mobility.SetMobilityModel("ns3::StaticMobilityModel");
Ptr<ListPositionAllocator> positionAlloc =
CreateObject<ListPositionAllocator>();
positionAlloc->Add(Vector(0.0,0.0,0.0));
positionAlloc->Add(Vector(35.0,0.0,0.0));
positionAlloc->Add(Vector(60.0,0.0,0.0));
mobility.SetMobilityModel ("ns3::StaticMobilityModel");
mobility.SetPositionAllocator(positionAlloc);

mobility.Install (adhocNodes);

NS_LOG_INFO ("Enabling OLSR routing on all adhoc nodes");
OlsrHelper olsr;
olsr.Install (adhocNodes);
// GlobalRouteManager::PopulateRoutingTables ();

uint16_t port = 9999;
OnOffHelper onoff1 ("ns3::TcpSocketFactory",Address
(InetSocketAddress (adhocInterfaces.GetAddress (0), port)));
onoff1.SetAttribute ("OnTime", RandomVariableValue
(ConstantVariable (1)));
onoff1.SetAttribute ("OffTime", RandomVariableValue
(ConstantVariable (0)));

ApplicationContainer apps1 = onoff1.Install (adhocNodes.Get (2));
apps1.Start (Seconds (1.0));
apps1.Stop (Seconds (12.0));

PacketSinkHelper sink ("ns3::TcpSocketFactory", InetSocketAddress
(Ipv4Address::GetAny (), port));
apps1 = sink.Install (adhocNodes.Get (0));
apps1.Start (Seconds (0.0));
apps1.Stop (Seconds (12.0));

NS_LOG_INFO ("Configure Tracing.");
std::ofstream ascii;
ascii.open ("adhoc_3node_test.tr");
YansWifiPhyHelper::EnableAsciiAll (ascii);
MobilityHelper::EnableAsciiAll (ascii);
YansWifiPhyHelper::EnablePcapAll ("adhoc_3node_test");

NS_LOG_INFO ("Run Simulation.");
Simulator::Stop (Seconds (13.0));
Simulator::Run ();
Simulator::Destroy ();
}

[Tom Henderson]

Hi,
I think you stumbled onto the same bug that is reported here:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=451

Try the patch listed in that bug report; it should clear the problem for
you.

Tom

[Asifuddin]

Tom,

Thanks for the quick response. I added the patch and now the
simulation executes without throwing any errors/exceptions. However,
no data gets through. In fact there are no transmission at all. I
looked at the log files and suspect that it might be a routing issue.
I
think the following section from the logs maybe relevant:

6.45304s OlsrRoutingTable:RequestRoute(): Olsr node
10.1.1.3:RouteRequest for dest=127.255.255.255 --> NOT FOUND; **
Dumping routing table...
6.45304s OlsrRoutingTable:RequestRoute(): dest=10.1.1.1 -->
next=10.1.1.1 via interface 1
6.45304s OlsrRoutingTable:RequestRoute(): dest=10.1.1.2 -->
next=10.1.1.2 via interface 1
6.45304s OlsrRoutingTable:RequestRoute(): ** Routing table dump end.
6.45304s Ipv4L3Protocol:Lookup(): Requesting route
6.45304s Ipv4StaticRouting:RequestRoute(0x88a20c8, 4294967295,
0xbfd444c0,0x88b1840, 0xbfd44308)
6.45304s Ipv4StaticRouting:RequestRoute(): source = 127.0.0.1
6.45304s Ipv4StaticRouting:RequestRoute(): destination =
127.255.255.255
6.45304s Ipv4StaticRouting:RequestRoute(): Unicast destination
6.45304s Ipv4StaticRouting:LookupStatic()
6.45304s Ipv4L3Protocol:SendRealOut(0x88a2060, 0, 0xbfd4431c,
0x88b1840,0xbfd444c0)
6.45304s Packet:AddHeader(0x88b1840, 0xbfd444c0)

Please note that the traffic source is 10.1.1.3 and the destination
is
10.1.1.1 and they are not in direct communication range.

I have tried letting the simulation run for 100 seconds, before I
initiate any traffic to see if the convergence of routing table is
taking time. However, there were no data transmissions or receptions.

Please let me know if you want me to post the full log.

Thanks,
Asif.

[Tom Henderson]

Asifuddin wrote:
> Tom,
>
> Thanks for the quick response. I added the patch and now the
> simulation executes without throwing any errors/exceptions. However,
> no data gets through. In fact there are no transmission at all.

I looked at this a bit more carefully. First, it helps to increase the
time of the simulation to let OLSR converge. I set the simulation stop
time to 130 seconds, and started the Tcp flow at 100 sec.

Despite this, Olsr is not finding the correct next hop, for some reason.

If I put your program in scratch/test.cc, and turn on logging, such as:
NS_LOG="OlsrRoutingTable" ./waf --run scratch/test

I see in the log:

100s OlsrRoutingTable:RequestRoute(): Olsr node 10.1.1.3: RouteRequest
for dest=10.1.1.1 --> nestHop=10.1.1.1 interface=1

The next hop should be 10.1.1.2, I think. I'll have to look next at
OLSR; will look at it tomorrow.

Global routing will not work in this case; global routing assumes that
everyone is reachable on the link (it does not take into account the
wireless effects). One could conceivably avoid this by putting each
interface on a /32, but this is not supported (see bug 402):
http://www.nsnam.org/bugzilla/show_bug.cgi?id=402

Tom

[Gustavo Carneiro]

2009/1/5 Asifuddin <asif...@gmail.com>

I have run your example, and the OLSR logs contradict your assumption:

2.44252s [node 2] OlsrAgent:RecvOlsr(): OLSR node 10.1.1.3 received a OLSR packet from 10.1.1.1 to 10.1.1.3
2.44252s [node 2] OlsrAgent:RecvOlsr(): Olsr Msg received with type 1 TTL=1 origAddr=10.1.1.1
2.44252s [node 2] OlsrAgent:RecvOlsr(): 2.44252s OLSR node 10.1.1.3 received HELLO message of size 32
2.44252s [node 2] OlsrAgent:LinkSensing(): @2.44252: Olsr node 10.1.1.3: LinkSensing(receiverIface=10.1.1.3, senderIface=10.1.1.1) BEGIN
2.44252s [node 2] OlsrAgent:LinkSensing(): Existing link tuple already exists => will update it
2.44252s [node 2] OlsrAgent:LinkSensing(): Looking at HELLO link messages with Link Type 1 (ASYM_LINK) and Neighbor Type 0 (NOT_NEIGH)
2.44252s [node 2] OlsrAgent:LinkSensing():    -> Neighbor: 10.1.1.2
2.44252s [node 2] OlsrAgent:LinkSensing():      \-> *neighIfaceAddr (10.1.1.2 != receiverIface (10.1.1.3) => IGNORING!
2.44252s [node 2] OlsrAgent:LinkSensing(): Link tuple updated: 1
2.44252s [node 2] OlsrAgent:LinkSensing(): Looking at HELLO link messages with Link Type 1 (ASYM_LINK) and Neighbor Type 0 (NOT_NEIGH)
2.44252s [node 2] OlsrAgent:LinkSensing():    -> Neighbor: 10.1.1.3
2.44252s [node 2] OlsrAgent:LinkSensing(): LinkTuple(localIfaceAddr=10.1.1.3, neighborIfaceAddr=10.1.1.1, symTime=-882926194ns, asymTime=8442524197ns, expTime=6117073806ns: link is SYM or ASYM => should become SYM now (symTime being increased to 8442524197ns
2.44252s [node 2] OlsrAgent:LinkSensing(): Link tuple updated: 1
2.44252s [node 2] OlsrAgent:LinkTupleUpdated(): 2.44252s: OLSR Node 10.1.1.3 LinkTuple LinkTuple(localIfaceAddr=10.1.1.3, neighborIfaceAddr=10.1.1.1, symTime=8442524197ns, asymTime=8442524197ns, expTime=14442524197ns UPDATED.
2.44252s [node 2] OlsrAgent:LinkTupleUpdated(): NeighborTuple(neighborMainAddr=10.1.1.1, status=SYM, willingness=3)->status = STATUS_SYM; changed:1
2.44252s [node 2] OlsrAgent:LinkSensing(): @2.44252: Olsr node 10.1.1.3: LinkSensing END
2.44252s [node 2] OlsrAgent:ProcessHello(): 2.44252s ** BEGIN dump Link Set for OLSR Node 10.1.1.3
2.44252s [node 2] OlsrAgent:ProcessHello(): LinkTuple(localIfaceAddr=10.1.1.3, neighborIfaceAddr=10.1.1.1, symTime=8442524197ns, asymTime=8442524197ns, expTime=14442524197ns
2.44252s [node 2] OlsrAgent:ProcessHello(): LinkTuple(localIfaceAddr=10.1.1.3, neighborIfaceAddr=10.1.1.2, symTime=8257091202ns, asymTime=8257091202ns, expTime=14257091202ns
2.44252s [node 2] OlsrAgent:ProcessHello(): ** END dump Link Set for OLSR Node 10.1.1.3
2.44252s [node 2] OlsrAgent:ProcessHello(): 2.44252s ** BEGIN dump Neighbor Set for OLSR Node 10.1.1.3
2.44252s [node 2] OlsrAgent:ProcessHello(): NeighborTuple(neighborMainAddr=10.1.1.1, status=SYM, willingness=3)
2.44252s [node 2] OlsrAgent:ProcessHello(): NeighborTuple(neighborMainAddr=10.1.1.2, status=SYM, willingness=3)
2.44252s [node 2] OlsrAgent:ProcessHello(): ** END dump Neighbor Set for OLSR Node 10.1.1.3

I know the OLSR logging is kind of messy, but basically it says that 10.1.1.3 received a HELLO from 10.1.1.1, and the two nodes at that point are considered symmetric neighbors.  So naturally the shortest path from 10.1.1.3 to 10.1.1.1 is a direct hop.  Looking at pcap traces confirms this via other means: ARP request/response exchanges happen directly between 10.1.1.1 and 10.1.1.3.

I am not sure why transmissions succeed with OLSR and ARP packets (they're both broadcast), but I suspect there is something slightly wrong with the wifi adhoc mode.  But I am sorry I have no idea what it could be :|

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

[Asifuddin]

Gustavo,

Thanks for the help. However, I am a little confused now. If 10.1.1.3
and 10.1.1.1 are not in the physical communication range of each
other, how are they able to exchange any messages directly?

I am assuming that you are also testing this with NS-3.3-RC6, because
I noticed that the default range in this version with Yanswifi is
around 35-40 meters (found via trial and error), whereas the default
transmission range in ns-3.2 was around 150-160 meters.

Secondly, if the OLSR hello messages are able to get across (lets say
the two nodes are in fact in communication range), then why aren't the
data packets able to get through.

What puzzles me is why aren't there any transmissions. If they are not
received or dropped, that's one thing. But if there are no
transmission to begin with, that's whole another thing.

Lastly, I am wondering if anyone got a successful simulation going
with OLSR using adhoc wifi nodes?
I will be more than willing to conduct a rigorous testing of OLSR over
different scenarios in future

Thanks,
Asif

On Jan 6, 1:24 pm, "Gustavo Carneiro" <gjcarne...@gmail.com> wrote:
> 2009/1/5 Asifuddin <asif4...@gmail.com>

[Tom Henderson]

Asifuddin wrote:
> Gustavo,
>
> Thanks for the help. However, I am a little confused now. If 10.1.1.3
> and 10.1.1.1 are not in the physical communication range of each
> other, how are they able to exchange any messages directly?

What I am seeing is that 10.1.1.3 and 10.1.1.1 are in communication
range for each other, for OLSR and for Arp requests. But the Arp reply
does not make it back.

The OLSR messages and Arp request messages are much more robust than the
Arp reply messages. The Arp reply message range is roughly 40 m, but
the OLSR hello message range and the Arp request message range is
roughly 160 m.

This discrepancy in range is causing the problem. OLSR thinks that
10.1.1.1 is one hop away, but the Arp reply cannot make it back from
10.1.1.1 to 10.1.1.3, so the Tcp SYN eventually is dropped.

This seems like it is a bug of some kind.

>
> I am assuming that you are also testing this with NS-3.3-RC6, because
> I noticed that the default range in this version with Yanswifi is
> around 35-40 meters (found via trial and error), whereas the default
> transmission range in ns-3.2 was around 150-160 meters.

I am testing this with ns-3-dev with the patch for bug451 applied.

>
> Secondly, if the OLSR hello messages are able to get across (lets say
> the two nodes are in fact in communication range), then why aren't the
> data packets able to get through.

>
> What puzzles me is why aren't there any transmissions. If they are not
> received or dropped, that's one thing. But if there are no
> transmission to begin with, that's whole another thing.

The arp requests make it from 10.1.1.3 to 10.1.1.1, even at a distance
of 160 m. The arp replies cannot travel more than 40 m. I will look at
this again tomorrow morning. Drops are being logged to my ascii trace file.

- Tom

[Mathieu Lacage]

On Tue, 2009-01-06 at 21:39 -0800, Tom Henderson wrote:
> Asifuddin wrote:
> > Gustavo,
> >
> > Thanks for the help. However, I am a little confused now. If 10.1.1.3
> > and 10.1.1.1 are not in the physical communication range of each
> > other, how are they able to exchange any messages directly?
>
> What I am seeing is that 10.1.1.3 and 10.1.1.1 are in communication
> range for each other, for OLSR and for Arp requests. But the Arp reply
> does not make it back.
>
> The OLSR messages and Arp request messages are much more robust than the
> Arp reply messages. The Arp reply message range is roughly 40 m, but
> the OLSR hello message range and the Arp request message range is
> roughly 160 m.
>
> This discrepancy in range is causing the problem. OLSR thinks that
> 10.1.1.1 is one hop away, but the Arp reply cannot make it back from
> 10.1.1.1 to 10.1.1.3, so the Tcp SYN eventually is dropped.
>
> This seems like it is a bug of some kind.

This seems to be merely the rate control algorithm doing its work. For
broadcast packets, it uses always the lowest available rate so achieves
the highest range. For non-broadcast packets, it attempts to use a
higher rate so, achieves a lower range. After a while, it should settle
on a lower rate, hence, achieving the required range but this requires
packets to be sent to update the rate control statistics. i.e., the rate
control code takes time to update its tx rate based on the channel
conditions because it can't guess them so...

If you don't like this, you can set the 'constant' rate control
algorithm with a 6mbs rate.

Mathieu

[Tom Henderson]

Yes, that's obvious, should have occurred to me. I am used to seeing
the reverse behavior (unicast more robust than broadcast) in
interference-dominated environments.

.
>
> If you don't like this, you can set the 'constant' rate control
> algorithm with a 6mbs rate.
>

Well, I'm wondering whether this is a good default for us to use in the
simulator, since a TCP connection can't even get started. I counted 28
arp replies (retransmissions) and none of them seem to have dropped to
the rate that broadcast is using. Should Arf be this sluggish to
adjust? Should Arf initialize to the lowest rate instead? Or should we
not use Arf as a default?

Tom

[Asifuddin]

Hi Tom,

In order to simplify the problem a little bit (admittedly, a tiny
bit), I used UDP instead of TCP because we do not want to complicate
the issue with TCP behavior. From the simulations, I ran, I don't see
any UDP packets getting through either, nor are there any
transmissions.

As suggested by Mathieu, if the rate were to stabilize after certain
time period, we should be able to see some UDP packets getting through
assuming that OSPF would figure out the correct route. I ran the
simulation for 1000 seconds while starting and stopping UDP client/
server at several intervals. Unfortunately, had no luck with it.

Asif.

[Tom Henderson]

Asifuddin wrote:
> Hi Tom,
>
> In order to simplify the problem a little bit (admittedly, a tiny
> bit), I used UDP instead of TCP because we do not want to complicate
> the issue with TCP behavior. From the simulations, I ran, I don't see
> any UDP packets getting through either, nor are there any
> transmissions.
>
> As suggested by Mathieu, if the rate were to stabilize after certain
> time period, we should be able to see some UDP packets getting through
> assuming that OSPF would figure out the correct route. I ran the
> simulation for 1000 seconds while starting and stopping UDP client/
> server at several intervals. Unfortunately, had no luck with it.

Asif,
I think the problem is the 54mbs constant-rate rate control that is
being applied. Applying these wifi changes resolved it (removed the
constant rate rate control, and let the default rate control take over)

- WifiHelper wifi;
+ 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-54mbs"));

NetDeviceContainer adhocDevices = wifi.Install (wifiPhy,
adhocNodes);

Maybe the issue here (I will look into this and file a bug if needed) is
the behavior of this ConstantRateWifiManager rate control algorithm-- it
seems to only be applied to the broadcast frames perhaps.

Anyway, the above changes make your script work for me now.

Tom

[Asifuddin]

Hi,

Yes, I see that removing the 54mbs constant-rate control resolves
the
issue. Leaving it to default or at any a constant rate below 36mbs
seems to work. While this bug is fixed, it still helps me
tremendously
to be able to proceed with the default or lower data rates.

I would like to thank all the people (especially Tom, Gustavo, and
Mathieu) who contributed to the discussions. It was extremely
helpful.
Also, since there are no working examples of ad-hoc wifi (involving
more than two nodes), I would suggest a couple of examples to be
included in the default distribution of ns-3. One could be with
stationary ad-hoc nodes and the second one using the 2drandomwalk
mobility model. I would be willing to contribute properly commented
and tested examples if this is something that you agree should be
there.

Thanks,
Asif.

[Tom Henderson]

Asifuddin wrote:
> Hi,
>
> Yes, I see that removing the 54mbs constant-rate control resolves
> the
> issue. Leaving it to default or at any a constant rate below 36mbs
> seems to work. While this bug is fixed, it still helps me
> tremendously
> to be able to proceed with the default or lower data rates.
>
> I would like to thank all the people (especially Tom, Gustavo, and
> Mathieu) who contributed to the discussions. It was extremely
> helpful.
> Also, since there are no working examples of ad-hoc wifi (involving
> more than two nodes), I would suggest a couple of examples to be
> included in the default distribution of ns-3. One could be with
> stationary ad-hoc nodes and the second one using the 2drandomwalk
> mobility model. I would be willing to contribute properly commented
> and tested examples if this is something that you agree should be
> there.
>
> Thanks,
> Asif.
>

Yes, please contribute scripts that you think would be useful to others.

There is another script that includes more than two adhoc wifi nodes
(examples/mixed-wireless.cc), but I don't think the adhoc portion has
ever been seriously exercised and it may be that everyone is within
range of one another.

Thanks,
Tom