IEEE 802.11s implementation is broken?

[Federico Tramarin]

Dear all,

after long debug and tests, I am quite disappointed now by the fact that the mesh (802.11s) implementation does not work as expected in ns3 (3.25).

Please, let's consider the example file provided, where a grid 3x3 of wifi mesh node is built.

 *  m_xSize * step

 *  |<--------->|

 *   step

 *  |<--->|

 *  * --- * --- * <---Ping sink  _

 *  | \   |   / |                ^

 *  |   \ | /   |                |

 *  * --- * --- * m_ySize * step |

 *  |   / | \   |                |

 *  | /   |   \ |                |

 *  * --- * --- *                _

 *  ^ Ping source

The distance between nodes in the example file is 100 meters.

With such a distance, two neighbors are expected to be able to talk each other *directly*, but surely ping source and sink are not expected to!

This is where mesh should come into play, by finding a correct path, and relaying messages through the mesh.

The behavior obtained with the example provided with ns3 is instead opposite.

Ping sink is able to ear and answer to ping source only if they are in the range of each other.

This is easily reproducible by anyone on a fresh build of ns3

Just build the examples, and then run the example in src/mesh/examples/mesh.cc

If one activates logging, though NS_LOG="UdpEchoServerApplication=level_all|prefix_func|prefix_time", she/he will discover that no packets are received until

the step parameter (distance between two neighbor nodes) is lowered to around 45 meters.

Enabling pcap output, one then will also discover that in that case sink and source are talking each other directly.

And the same can be seen by looking at the xml report files generated by the simulation.

Clearly, I observed the same behavior changing a lot of configuration parameters. But, finally, using the example file make thing more reproducible.

At this point, since mesh is there from time, and since I doubt that there is a so big issue in the simulator, I am here asking help

in understanding what is failing here. There have to be something :(

Cheers

Federico

[Natale Patriciello]

On 07/10/16 at 01:42am, Federico Tramarin wrote:
> At this point, since mesh is there from time, and since I doubt that there
> is a so big issue in the simulator, I am here asking help
> in understanding what is failing here. There have to be something :(

This is one of the few email that should be used as example on how to
ask questions.

Coming in-topic: What routing protocol are you using?

Nat

[Federico Tramarin]

Thank you.

I am using the example file ns3 provides as “an example” script of the mesh feature implementation.
It makes use of HWMP, that is the default L2 routing protocol foreseen by the 802.11s standard.

Looking forward to hearing from the community

Federico

> --
> 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/uKa0fCIXk6Q/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.
> For more options, visit https://groups.google.com/d/optout.

[Tom Henderson]

On 10/07/2016 02:18 AM, Federico Tramarin wrote:
> Thank you.
>
> I am using the example file ns3 provides as “an example” script of the mesh feature implementation.
> It makes use of HWMP, that is the default L2 routing protocol foreseen by the 802.11s standard.
>
> Looking forward to hearing from the community
>
> Federico

Federico, can you please try the latest release (3.26) or the ns-3-dev code?

What has changed since the 3.25 release (motivated by this type of
failing mesh topology) is the backoff behavior for nodes relaying
broadcast frames. Previously, there was no backoff in that scenario,
and ARPs were repeatedly colliding and failing for regular grid
topologies. This bug entry has more detail:

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1465

With ns-3.26 and this example, I see the ping succeeding at the default
100m step size.

- Tom

[Federico Tramarin]

Thank you for this hint.

I will try now.

Actually, when 3.26 has been published, I didn't see the problem mentioned in the changelog, and unfortunately I didn't looked at bugzilla.

This last has been my fault, sorry for this...

I'll let you know.

Federico

[Federico Tramarin]

Tried and works now.

Thank you.

BTW...

1) I will make some tests again about HT support with mesh networks.

2) One thing works, another one stopped working!

In my file, where also output for netanim was produced, the line 

           anim.EnablePacketMetadata ();

causes a runtime error...

msg="Information element 0 is not implemented", file=../src/wifi/model/wifi-information-element-vector.cc, line=100

libc++abi.dylib: terminating

Command ['/Users/federico/simulazioni/ns-allinone-3.26/ns-3.26/build/scratch/mesh-test4'] terminated with signal SIGIOT.

Commenting out that line makes things work again.

Actually, I don't need very much that feature, so it's not urgent, but I want to signal this issue.

Bye and thank you again

Federico

[Tom Henderson]

On 10/08/2016 06:04 AM, Federico Tramarin wrote:
> Tried and works now.
> Thank you.
>
> BTW...
>
> 1) I will make some tests again about HT support with mesh networks.
>
> 2) One thing works, another one stopped working!
> In my file, where also output for netanim was produced, the line
> anim.EnablePacketMetadata ();
> causes a runtime error...
>
> msg="Information element 0 is not implemented",
> file=../src/wifi/model/wifi-information-element-vector.cc, line=100

I'm guessing that this is due to a bug we have open:
https://www.nsnam.org/bugzilla/show_bug.cgi?id=2505

I saw this assert when I was trying to enable packet printing in the
course of looking at the above bug. I will see about a workaround or
fix but it may take a few days.

- Tom