Problem with 802.11s HWMP simulation

[Daniel Oliva Domingues]

Hi all,

I've been working with 802.11s and I'm facing a lot of issues when trying to simulate an area with a couple of nodes running HWMP. If the distance between all nodes is at least 100 meters, I do not have any problems with packet delivery.

However, if I have a topology like this attached image, where distance between some HWMP nodes is less than 100 meters, I do not have any packet received on the destination, which is the sink node (blue). The other nodes are client nodes (red) that send packets, and router nodes (green) that only route packets.

If I use another routing protocol as AODV or OLSR, I do not have any problems with the same topology, packets can be delivered to its destination.

Could you please help me? I've been trying to solve this problem for days and I can't come up with a solution. An example output file is also attached.

Many thanks as usual.

Best regards,

Daniel Domingues

[Daniel Oliva Domingues]

Just to complement a information that I've forgotten, I'm using the latest ns-3-dev distribution.

Thanks.

Daniel Domingues

[Daniel Oliva Domingues]

Hi Tommaso,

Sorry to bother copying you on this thread. I usually wait the amount of time needed to obtain answers from the ns-3 community of users, which is really fast, indeed. I know that you are very busy and don't have anything to do with my urgency in this case, but I would really appreciate if you could help me with this problem.

I'm at the final phase of my master's thesis and these negative results from HWMP were a very negative surprise to me. Do you have any clue about what can be happening in my simulations? Or how can I diagnose this? Or anyone who can help me?

Many thanks.

Regards,

Daniel Domingues

[Tom Henderson]

On 04/19/2017 10:31 AM, Daniel Oliva Domingues wrote:
> Hi Tommaso,
>
> Sorry to bother copying you on this thread. I usually wait the amount
> of time needed to obtain answers from the ns-3 community of users,
> which is really fast, indeed. I know that you are very busy and don't
> have anything to do with my urgency in this case, but I would really
> appreciate if you could help me with this problem.
>
> I'm at the final phase of my master's thesis and these negative
> results from HWMP were a very negative surprise to me. Do you have any
> clue about what can be happening in my simulations? Or how can I
> diagnose this? Or anyone who can help me?
>
> Many thanks.
>
> Regards,
>
> Daniel Domingues
>

It sounds like you need to get some information out of your program to
debug it, or else you need to step through it with a debugger.

Here is a hint. Run your simulation with the "HwmpProtocol" log
component enabled; e.g.:

NS_LOG="HwmpProtocol" ./waf --run mesh

and since you will get a lot of debug information, I'd direct the output
to a file like this:

NS_LOG="HwmpProtocol" ./waf --run mesh > log.out 2>&1

Then you can look at Hwmp in action. Try doing this for a working
scenario, then repeat for the non-working scenario, and try to compare
the logs to understand what is different. If you need more information,
turn on more log components as needed:

NS_LOG="HwmpProtocol:HwmpRtable" ./waf --run mesh

- Tom

[Daniel Oliva Domingues]

Hi Tom,

Many thanks for your answer.

I've done what you said and I've noticed that the log files from a working scenario and a not working one are very different.

In the not working scenario I see a lot of these messages in the log:

HwmpProtocol:PeerLinkStatus(): [DEBUG] 0 failed destinations for peer address 00:00:00:00:00:0a

HwmpProtocol:MakePathError(0x26e18b0)

HwmpProtocol:GetPerrReceivers(0x26e18b0)

HwmpProtocol:InitiatePathError(0x26e18b0)

HwmpProtocol:DropDataFrame(0x26e18b0, 1, 00:00:00:00:00:08)

HwmpProtocol:DropDataFrame(0x276e5c0, 1, 00:00:00:00:00:08)

HwmpProtocol:DropDataFrame(0x26cfed0, 1, 00:00:00:00:00:08)

In the working scenario, the above messages doesn't appear in the log.

The only difference between these scenarios is the number of mesh nodes in this way:

- working scenario: 4 mesh nodes representing only router nodes and 1 mesh node representing a client sending data to another 1 mesh node (sink)

- not working scenario: 4 mesh nodes representing only router nodes and 4 mesh node representing a client sending data to another 1 mesh node (sink)

- both scenarios has a simulation area of 1000 m².

I've attached the logs to show you if you have the chance to analyze them. Even looking them, I cannot tell what is happening to result in this poor HWMP performance.

As I said before, I suspect that this is something related with the step distance between mesh nodes, but I can't understand why as with MANET routing protocols I do not have this problem.

Many thanks.

Regards,

Daniel Domingues

[Tom Henderson]

I will hazard a guess. There may be enough failures at the Wi-Fi level
(excessive retries) to trigger a path error in HWMP, while the other
protocols are operating at a higher layer and are not seeing these
errors. I suspect it is something along these lines.

- Tom

[christopher]

Hi Daniel,

 

An unfavorable parametrization could be also the reason.

I would recommend to try the following:

 Config::SetDefault ("ns3::dot11s::PeerLink::MaxBeaconLoss", UintegerValue (20)); //20 (default 2)
  Config::SetDefault ("ns3::dot11s::PeerLink::MaxRetries", UintegerValue (10)); // (default 4)
  Config::SetDefault ("ns3::dot11s::PeerLink::MaxPacketFailure", UintegerValue (50000)); // high value => link will not be closed

 Config::SetDefault ("ns3::dot11s::PeerManagementProtocol::EnableBeaconCollisionAvoidance", BooleanValue (true));

 Config::SetDefault ("ns3::ArpCache::DeadTimeout",TimeValue (Seconds (900))); //100
 Config::SetDefault ("ns3::ArpCache::AliveTimeout",TimeValue (Seconds (920))); //120
 Config::SetDefault ("ns3::ArpCache::MaxRetries",UintegerValue (10)); //3
 Config::SetDefault ("ns3::ArpCache::WaitReplyTimeout",TimeValue (Seconds (0.1))); //default 1

You have also mentioned that one of the differences is 4 sending nodes instead of one. As I remember, there might be a bug in the ARP Protocol. The 4 different datastreams should have a different start time.

[Daniel Oliva Domingues]

Hi Christopher and Tom,

Unfortunately, even applying those parametrizations the simulation do not deliver any packets to its destination. When I have until 4 sending nodes it does work, but when I try to use 5, it stops receiving packets.

Many messages like the one below are being displayed in those failed simulations:

HwmpProtocol:PeerLinkStatus(): [DEBUG] 0 failed destinations for peer address

Tomorrow I will continue to investigate this issue and then I message you once again if I have any positive results.

Many many many thanks for your help!

Regards,

Daniel Domingues

[Daniel Oliva Domingues]

Hi Christopher,

Today I've done a lot of simulations and I've noticed a couple of things:

- After changing the following parameter as you suggested, the small scenario that I've been simulating has finally worked! However, when running larger scenarios, this parameter didn't changed the simulation results significantly.

Config::SetDefault ("ns3::dot11s::PeerLink::MaxRetries", UintegerValue (10)); // (default 4)

- When running simulations for 1000 seconds, I've noticed that the Packet Delivery Ratio has started to decrease a lot (from 80% to 40%) after half of the simulation and it kept falling until the end. So I've tried to run this simulation once again using the parameter below like you suggested. Then surprisingly it has worked and the Packet Delivery Ratio has remained almost constant during all the simulation. Many thanks, this really helped me. Is this the ARP bug you have mentioned?

Config::SetDefault ("ns3::ArpCache::AliveTimeout",TimeValue (Seconds (simDuration))); //120

I've tested all the others parameters but they didn't changed the simulation results significantly.

I was doing some researches and I think my problem is somewhat related to this bug description: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2369. It appears to have been solved, but I think ARP collisions might be the root cause of this problem.

Many thanks for your help.

Regards,

Daniel Domingues

[辛文飞]

Can you upload your program for me? Now, I'm studying the mesh module, but I don't know how to build such a topology. Perhaps you can send me this with the gmail, my gmail address is xinwenf...@gmail.com. Thank you in advance!

在 2017年4月22日星期六 UTC+8上午5:49:06，Daniel Oliva Domingues写道：

[Daniel Oliva Domingues]

Hi,

You can use mesh.cc example file to build yours own mesh topology.

https://www.nsnam.org/doxygen/mesh_8cc.html

Regards,

Daniel

[Marcel Riera]

Hi Daniel, I know this post is 2 years old but I believe I'm facing the exact same issue

I'm running simulations with HWMP, and again in scenarios where nodes are closer together I have no packet delivery, but when further apart they do perform correctly.

On further analysis checking at the logs I found the same behavior as you stated, 

HwmpProtocol:PeerLinkStatus(): [DEBUG] 0 failed destinations for peer address

And also the same as the other posts above.

Would you mind sharing how you worked around this issue? I've spent a long time working on it and still can find a solution. I would deeply appreciate it.

Thanks.

[Daniel Oliva Domingues]

Hi Marcel,

Sorry for the late reply. Unfortunately I did not find a suitable solution for this. I ended up changing my scenario to a larger one, where nodes did not stay close together enough to allow packet delivery.

I don't know if this is a bug, or maybe HWMP protocol behavior, as it sends a lot of control messages that might be flooding the wireless spectrum.

Regards,

Daniel Domingues

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/jfWGJW_xEGc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/cf2c86a1-5af9-422e-aad5-5a6fb9103749%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marcel Riera]

Thank you Daniel. 

I agree it must be some sort of bug, but a hard one to trace down. I'll have to modify my scenarios too. 

Thanks again.

Marcel.