802.11s mesh with 802.11n PHY

[steve]

I would like to modify the 802.11s mesh example to utilize an 802.11n PHY.

1. What is the easiest way to the modify the mesh example to incorporate use of an 802.11n PHY?

2. More specifically, is there a way to use the YansWifiPhyHelper to change the PHY standard?

Thanks,

Steve

[Tommaso Pecorella]

Hi,

check this function:

https://www.nsnam.org/docs/doxygen/classns3_1_1_mesh_helper.html#a4724c5e5c2ae4e58662e56150ca3e1a3

Hope this helps,

T.

[steve]

Tom,

Thank you. I'm not sure how to use Google Groups-- thus my mistaken previous post.

I assume I would enter WIFI_PHY_STANDARD_80211n_5GHZ. 

Do you happen to have any more information on the 11n models (e.g. published paper) and how well they've been tested?

Thanks,

Steve

[Tommaso Pecorella]

Hi,

no, unfortunately I don't have more documentation beside the ns-3 manual:

https://www.nsnam.org/docs/models/html/wifi.html

This, of course, doesn't means that more papers don't exists. I just don't have them.

Cheers,

T.

[steve]

Tom,

Ok. Thank you again for the information.

From what I can tell, the code appears to support up to GetOfdmRate24Mbps () which seems far lower than the standard data rates: http://en.wikipedia.org/wiki/IEEE_802.11n-2009#Data_rates. 

1. Am I missing something?

2. Are there any plans to implement higher data rates in the ns-3 simulation?

Thanks,

Steve

[Tommaso Pecorella]

Hi,

yes, you're missing something. The supported rates are far higher, but I can't give you precise hint right now (sorry, food cooking).

Cheers,

T.

[Sebastien Deronne]

Are you using the constant rate manager?

Support for rate adaptive algorithms in 802.11n is not yet provided.

[steve]

I'm using the 802.11s mesh example. I'm trying to modify that as little as possible.

[steve]

I've added:

mesh.SetRemoteStationManager ("ns3::ConstantRateWifiManager", "DataMode", StringValue("OfdmRate65MbpsBW20MHz"), "ControlMode", StringValue("OfdmRate6_5MbpsBW20MHz"));

However, that results in:

msg="Can't find response rate for OfdmRate65MbpsBW20MHz. Check standard and selected rates match.", file=../src/wifi/model/wifi-remote-station-manager.cc, line=1052

[steve]

Is there a handy table of the all the compatible standard, data rates, and optional settings? 

Or, to be more specific, what this highest data/control rate I can use with WIFI_PHY_STANDARD_80211n_5GHZ?

Thanks,

Steve

[Sebastien Deronne]

Normally it should be ok.

Anyway, try first with this:

mesh.SetRemoteStationManager ("ns3::ConstantRateWifiManager", "DataMode", StringValue("OfdmRate65MbpsBW20MHz"), "ControlMode", StringValue("OfdmRate65MbpsBW20MHz"));

[steve]

Sebastien,

I've tried that one and about a half dozen other combinations. They all return:

msg="Can't find response rate for OfdmRate65MbpsBW20MHz. Check standard and selected rates match.", file=../src/wifi/model/wifi-remote-station-manager.cc, line=1052

it would be good to an explicit table of which ones are supposed to work. Or is there another reason this error is occurring?

Thanks,

Steve

[steve]

I'm using:

WIFI_PHY_STANDARD_80211n_5GHZ via SetStandard().

Steve

[steve]

Tom,

I'll need a few more hints. I have the following:

  mesh = MeshHelper::Default ();

  mesh.SetStandard (WIFI_PHY_STANDARD_80211n_2_4GHZ);

  mesh.SetRemoteStationManager ("ns3::ConstantRateWifiManager", "DataMode", StringValue("OfdmRate65MbpsBW20MHz"), "ControlMode", StringValue("OfdmRate6_5MbpsBW20MHz"));

and have also experimented with setting:

  //wifiPhy.Set ("ChannelBonding", BooleanValue(true));

  //wifiPhy.Set ("ShortGuardEnabled", BooleanValue(true)); 

  //wifiPhy.Set ("GreenfieldEnabled", BooleanValue(true));

Full code is here:

void

MeshTest::CreateNodes ()

{ 

  /*

   * Create m_ySize*m_xSize stations to form a grid topology

   */

  nodes.Create (m_ySize*m_xSize);

  // Configure YansWifiChannel

  YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();

  //HtWifiMacHelper wifiPhy = HtWifiMacHelper::Default ();

   

  //wifiPhy.Set ("TxPowerLevels", UintegerValue (1));

  //wifiPhy.Set ("TxPowerStart", DoubleValue (20));

  //wifiPhy.Set ("TxPowerEnd", DoubleValue (20));

  

  YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default ();

  //wifiChannel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel");

  //wifiChannel.AddPropagationLoss ("ns3::LogDistancePropagationLossModel",

  //      "Exponent", DoubleValue (3.0),

  //                                "ReferenceLoss", DoubleValue (46.6777));

  wifiPhy.SetChannel (wifiChannel.Create ());

  /*

   * Create mesh helper and set stack installer to it

   * Stack installer creates all needed protocols and install them to

   * mesh point device

   */

  mesh = MeshHelper::Default ();

  mesh.SetStandard (WIFI_PHY_STANDARD_80211n_2_4GHZ);

  mesh.SetRemoteStationManager ("ns3::ConstantRateWifiManager", "DataMode", StringValue("OfdmRate65MbpsBW20MHz"), "ControlMode", StringValue("OfdmRate6_5MbpsBW20MHz"));

 

  //wifiPhy.Set ("ChannelBonding", BooleanValue(true));

  //wifiPhy.Set ("ShortGuardEnabled", BooleanValue(true)); 

  //wifiPhy.Set ("GreenfieldEnabled", BooleanValue(true));

 

  if (!Mac48Address (m_root.c_str ()).IsBroadcast ())

    {

      mesh.SetStackInstaller (m_stack, "Root", Mac48AddressValue (Mac48Address (m_root.c_str ())));

    }

  else

    {

      //If root is not set, we do not use "Root" attribute, because it

      //is specified only for 11s

      mesh.SetStackInstaller (m_stack);

    }

  if (m_chan)

    {

      mesh.SetSpreadInterfaceChannels (MeshHelper::SPREAD_CHANNELS);

    }

  else

    {

      mesh.SetSpreadInterfaceChannels (MeshHelper::ZERO_CHANNEL);

    }

  mesh.SetMacType ("RandomStart", TimeValue (Seconds (m_randomStart)));

  // Set number of interfaces - default is single-interface mesh point

  mesh.SetNumberOfInterfaces (m_nIfaces);

  // Install protocols and return container if MeshPointDevices

  meshDevices = mesh.Install (wifiPhy, nodes);

  // Setup mobility - static grid topology

  MobilityHelper mobility;

  mobility.SetPositionAllocator ("ns3::GridPositionAllocator",

                                 "MinX", DoubleValue (0.0),

                                 "MinY", DoubleValue (0.0),

                                 "DeltaX", DoubleValue (m_step),

                                 "DeltaY", DoubleValue (m_step),

                                 "GridWidth", UintegerValue (m_xSize),

                                 "LayoutType", StringValue ("RowFirst"));

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

  mobility.Install (nodes);

  if (m_pcap)

    wifiPhy.EnablePcapAll (std::string ("mp-"));

}

Steve

[Sebastien Deronne]

Which version of ns-3 are you using?

Some bugs have been removed between ns-3.21 and ns-3.22.

Feel also free to attach your script, I will try to have a look (in a reasonable time) whether there is a bug somewhere.

[Tommaso Pecorella]

How many times we said to NOT post the code in the message and use the attachment function ?

[steve]

I'm using the latest version of ns-3. Just downloaded it again today to make sure: version 3.22. 

The mesh file is attached. I'm trying to keep changes minimal and within this file, which is the case so far.

Thanks,

Steve

[Tommaso Pecorella]

The problem is in the mesh helper. It doesn't set the "HtSupported" attribute in the MAC. As a result... you know.

How to fix ? No idea - dunno if it should be fixed or it's something set by the standard.

I'll leave the floor to Sebastien, as wifi it's not my topic (sort of).

Cheers,

T.

[steve]

Tom and Sebastien,

Thanks. 

We have real systems running in this manner, so it would be nice to force it to 11n rates, if necessary. I would like to avoid hacking things up; if you have some thoughts on an aesthetically pleasing way to do it, that would be much appreciated.

Thanks,

Steve

[Sebastien Deronne]

Indeed, 802.11n implementation did not focus on mesh, so I am not surprised that HtSupported attribute is not set.

It should be quite easy to solve, I will have a look this weekend and let you know the solution.

[steve]

That would be great. However, I have not gotten much throughput even using 802.11g. I have WIFI_PHY_STANDARD_80211g set with ErpOfdmRate54Mbps and only two nodes 1 meter apart. It's returning about 12 Mbs throughput, which does not seem correct.

[Sebastien Deronne]

This is indeed strange.

Please provide also your script for 802.11g, I want to be sure you are doing it correctly before thinking to a potential bug.

[steve]

Attached is my version of the g configuration. Output is:

Printing mesh point device #0 diagnostics to mp-report-0.xml

Printing mesh point device #1 diagnostics to mp-report-1.xml

Flow 2 (10.1.1.1 -> 10.1.1.2)

  Tx Bytes:   145777872

  Rx Bytes:   145164816

  Throughput: 11.1875 Mbps

Definitely NOT utilizing 54Mbs given only two nodes that are one meter apart.

[Sebastien Deronne]

It seems you are confusing PHY bitrate, which should be indeed 54 Mbit/s in this case, and the application throughput, which seems here to be around 12 Mbit/s.

I checked the traces, and the physical bitrate is ok:

YansWifiPhy:SendPacket(0x7f8dcac255b0, 0x7f8dcac69360, ErpOfdmRate54Mbps, 0, 0, 0)
YansWifiPhy:StartReceivePacket(0x7f8dcaf1d260, 0x7f8dcac62bb0, 17.0206, ErpOfdmRate54Mbps, 0, 0)
sync to signal (power=0.0633957W)
YansWifiPhy:EndReceive(0x7f8dcaf1d260, 0x7f8dcac62bb0, 0x7f8dcac64630)
mode=54000000, snr=1.58001e+11, per=0, size=1536

I also observed collisions in the traces:

[mac=00:00:00:00:00:01] MacLow:StartTransmission(0x7fbc52702170, 0x7fbc527361b0, 0x7fbc52517858, [send rts=0, next size=0, dur=+0.0ns, ack=normal], 0x7fbc525157c0)
[mac=00:00:00:00:00:01] MacLow:CancelAllEvents(0x7fbc52702170)
[mac=00:00:00:00:00:01] startTx size=1536, to=00:00:00:00:00:02, listener=0x7fbc525157c0
[mac=00:00:00:00:00:01] MacLow:SendDataPacket(0x7fbc52702170)
[mac=00:00:00:00:00:01] MacLow:ForwardDown(0x7fbc52702170, 0x7fbc52736250, 0x7fbc52702308, mode:ErpOfdmRate54Mbps txpwrlvl:0 retries:0 Short GI: 0 Nss: 1 Ness: 0 STBC: 0)
[mac=00:00:00:00:00:01] send DATA, to=00:00:00:00:00:02, size=1536, mode=ErpOfdmRate54Mbps, duration=+44000.0ns, seq=0x100
YansWifiPhy:SendPacket(0x7fbc52518780, 0x7fbc52736250, ErpOfdmRate54Mbps, 0, 0, 0)
[mac=00:00:00:00:00:02] MacLow:StartTransmission(0x7fbc5260e930, 0x7fbc52650ea0, 0x7fbc5260fff8, [send rts=0, next size=0, dur=+0.0ns, ack=normal], 0x7fbc5260fd20)
[mac=00:00:00:00:00:02] MacLow:CancelAllEvents(0x7fbc5260e930)
[mac=00:00:00:00:00:02] startTx size=1536, to=00:00:00:00:00:01, listener=0x7fbc5260fd20
[mac=00:00:00:00:00:02] MacLow:SendDataPacket(0x7fbc5260e930)
[mac=00:00:00:00:00:02] MacLow:ForwardDown(0x7fbc5260e930, 0x7fbc52534bd0, 0x7fbc5260eac8, mode:ErpOfdmRate54Mbps txpwrlvl:0 retries:0 Short GI: 0 Nss: 1 Ness: 0 STBC: 0)
[mac=00:00:00:00:00:02] send DATA, to=00:00:00:00:00:01, size=1536, mode=ErpOfdmRate54Mbps, duration=+44000.0ns, seq=0x2a0
YansWifiPhy:SendPacket(0x7fbc52610f70, 0x7fbc52534bd0, ErpOfdmRate54Mbps, 0, 0, 0)
YansWifiPhy:StartReceivePacket(0x7fbc52610f70, 0x7fbc525341e0, 17.0206, ErpOfdmRate54Mbps, 0, 0)
drop packet because already in Tx (power=0.0633957W)
YansWifiPhy:StartReceivePacket(0x7fbc52518780, 0x7fbc52534f30, 17.0206, ErpOfdmRate54Mbps, 0, 0)
drop packet because already in Tx (power=0.0633957W)
[mac=00:00:00:00:00:01] MacLow:NormalAckTimeout(0x7fbc52702170)
[mac=00:00:00:00:00:01] normal ack timeout
[mac=00:00:00:00:00:02] MacLow:NormalAckTimeout(0x7fbc5260e930)
[mac=00:00:00:00:00:02] normal ack timeout

 

So, it is indeed possible that you get 12 Mbit/s...

But this is not an error in the .11 implementation, it is only due to the fact you do not really understand what you are doing!

Just checking the logs would have showed you the PHY bitrate is ok.

One more tip: enable pcap traces if you want to have a better understanding on what is happening in your simulation.

[steve]

Sebastien,

Thank you very much for checking into this. Much appreciated.

Our actual hardware has much closer to 54Mbs throughput, so perhaps it is the application rate. 

Is there an ns-3 app that more closely simulates Iperf and it's ability to exercise the channel? 

Thanks,

Steve

...

[steve]

Do any of the Helpers add QosTags to Packets? Or do I have to modify application Packets directly to add QoSTags for mesh wifi?

Steve

[Konstantinos]

You need to modify the application and if you create a new attribute you could use the application helper to easily configure the QoSTag.

[steve]

Mesh code attached and section of log below. If I understand this correctly, the packet error rate is 1.0 and appears to cause all receptions to fail. Unfortunately, the yans error rate model does not appear to have any logging to display why this is the case. Do you have any hints as to why this could be the case?

0.00400003s YansWifiPhy:StartReceivePacket(0xfb5ce0, 0xfc3e90, -128.355, OfdmRate6Mbps, 0, 0)

0.00400003s sync to signal (power=3.66826e-16W)

0.00412803s YansWifiPhy:EndReceive(0xfb5ce0, 0xfc3e90, 0xee09d0)

0.00412803s mode=6000000, snr=0.00289107, per=1, size=76

0.00412803s [mac=00:00:00:00:00:01] MacLow:ReceiveError(0xfb32a0, 0xfc3e90, 0.00289107)

0.00412803s [mac=00:00:00:00:00:01] rx failed

[Tommaso Pecorella]

I did write a post. Then I deleted it, because it wasn't a nice one. For you I mean.

However, I'll keep the main thing, as it may be helpful for you.

Signal to Noise Ratio of 0.00289107

I don't have to add more, do I ?

No, I must not. You don't want to.

T.

[steve]

I guess a better question would be: what are the units? dB? The value could be good or bad depending on the units.

The documentation did not appear to specify the units.

[Sebastien Deronne]

it's in linear scale, a quick look in the code would have given the answer.

[Sebastien Deronne]

I think additional comments are not needed, it is quite clear in the code:

  // thermal noise at 290K in J/s = W

  static const double BOLTZMANN = 1.3803e-23;

  // Nt is the power of thermal noise in W

  double Nt = BOLTZMANN * 290.0 * mode.GetBandwidth ();

  // receiver noise Floor (W) which accounts for thermal noise and non-idealities of the receiver

  double noiseFloor = m_noiseFigure * Nt;

  double noise = noiseFloor + noiseInterference;

  double snr = signal / noise;

[Tommaso Pecorella]

[with the most sweet voice possible]

  Dear Steve, what documentation are you looking at ?

  Because if you go at the right page, as is https://www.nsnam.org/docs/doxygen/classns3_1_1_yans_wifi_phy.html you will find the units of every attribute.

  Now, I'm wondering what documentation are you looking at.

T.

[steve]

I've cranked up the transmit power, but no luck getting many packets through the mesh (I'm 802.11g instead of n for now). 

There are lots of macLow receive errors. I assume "per" is packet error rate. Sometimes the value is nan. 

I see https://www.nsnam.org/doxygen/structns3_1_1_interference_helper_1_1_snr_per.html#a668e16537480e30bd4cb5dae02f06894 but that doesn't tell me units or details.

---

0.00303803s [mac=00:00:00:00:00:01] duration/id=+0.0ns

0.00303803s [mac=00:00:00:00:00:01] rx group from=00:00:00:00:00:04

0.00303803s MacRxMiddle:Receive(0x2704600, 0x7ffffa8c0ab0)

0.00303803s MacRxMiddle:Lookup(0x7ffffa8c0ab0)

0.00303803s MacRxMiddle:IsDuplicate(0x7ffffa8c0ab0, 0x273e310)

0.00303803s MacRxMiddle:HandleFragments(0x2704600, 0x7ffffa8c0ab0, 0x273e310)

0.00303803s forwarding data from=00:00:00:00:00:04, seq=0, frag=0

0.00303803s YansWifiPhy:EndReceive(0x2715b30, 0x27435c0, 0x269a060)

0.00303803s mode=54000000, snr=4.58204e+35, per=1, size=76

0.00303803s [mac=00:00:00:00:00:05] MacLow:ReceiveError(0x2713020, 0x27435c0, 4.58204e+35)

0.00303803s [mac=00:00:00:00:00:05] rx failed

0.00303803s YansWifiPhy:EndReceive(0x271e400, 0x2711400, 0x269a510)

0.00303803s mode=54000000, snr=4.58204e+35, per=1, size=76

0.00303803s [mac=00:00:00:00:00:07] MacLow:ReceiveError(0x271b8f0, 0x2711400, 4.58204e+35)

0.00303803s [mac=00:00:00:00:00:07] rx failed

0.00303803s YansWifiPhy:EndReceive(0x2719f90, 0x2722bc0, 0x2727770)

0.00303803s mode=54000000, snr=4.58204e+35, per=1, size=76

0.00303803s [mac=00:00:00:00:00:06] MacLow:ReceiveError(0x2717500, 0x2722bc0, 4.58204e+35)

[steve]

I have a separate question about HWMP. I see mp-report*.xml files generate information about HWMP.

(1) Is the PeerLink element of the XML supposed to be describing an HWMP "routing" connection?

(2) If that is so and if I specify a root MAC address, should it form a tree with the root MAC-addressed node as the root of the tree? I'm not seeing this. Instead it looks like a mesh of inter-connections always end of forming. 

Steve

On Tuesday, April 7, 2015 at 2:20:11 PM UTC-4, Tommaso Pecorella wrote:

[Sebastien Deronne]

I do not get the same output with the provided script.

But the results you describe are quite strange. 

Have you modified something in the wifi PHY model?

[steve]

No changes to underlying code, except adding QosTag to application packets. I'm trying to avoid touching low-level code if at all possible.

[Sebastien Deronne]

Ok, then what are the parameters used in your script?

If you want me to reproduce the issue, please provide me the exactly same script and parameters you used.

[steve]

Certainly. The script is attached.

Steve

[Sebastien Deronne]

If you want help you need to provide files that are matching.

Here, they are not! (attributes passed but do not exist, ...) So I cannot test it.

A Txpower of 400 dBm is not possible IN PRACTICE and IN NS3!

Indeed, try to compute what you get in Watt? It's sooooooo huge!

So, such a huge number in the simulator may result in erroneous number representations, which may explain the large SNR value and a null frame success rate.

Give a correct Tx Power (generally between 10 and 20 dBm) and try again!

[Tommaso Pecorella]

Sebastien,

a 400dBm Tx power is perfectly fine. If you want to jam all the neighbors Wi-Fi, including the ones used by the cops.

Weeee.... I have a nuclear plant in my truck, and I'm frying all the 2.4 GHz radios in the neighborhoods. 

Cheers,

T.

PS: 400 dBm is 1e+37 Watts. So yes, you need a nuclear plant, and probably it wouldn't be enough.

[Sebastien Deronne]

Indeed :-)

[steve]

My problem is that 10 or 20 dBm results in an SNR that is too low. I have had to use this crazy value to get packets to flow even over short distances. That's what is causing me to lose confidence in the ns-3 mesh (or my understanding of it). 

I've attached both script and mesh code together in this message to make sure you have the matching files. mesh.cc should have all the proper command line arguments that are passed from the script. I'm using ns-3 version 22 and the attached code compiles and operates.

My results: 

*) 10-20 dBm result in SNR too low to communicate

*) 400 dBm gets packets through when at relatively close range, but HWMP peering is not forming a tree.

[Tommaso Pecorella]

How many times should we repeat this ?

How many ***** times ?

Do you know ? There will be a time when we'll have to not correct this error at lest one every 15 days ?

  YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default ();
 
  wifiChannel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel");
  wifiChannel.AddPropagationLoss ("ns3::LogDistancePropagationLossModel", "Exponent", StringValue ("2.7"));

 We even named the function "AddPropagationLoss"

ADD, so people would think that they're adding a propagation loss.

Now, please don't come up with blatant excuses. I can confute them from the beginning.

Excuse #1: "I didn't think there was another propagation loss already in place".

Confutation #1: "Oh, so you thanked that if you didn't add any propagation loss, there wasn't any. And tell me, what would be the Wi-Fi range in this case ?"

Excuse #2: "but... but..."

Confutation #2: "Good, and since you didn't understand why a normal Wi-Fi radio, with a normal power, in a normal setup had a abysmal radio range, you increased the power instead of finding why the radio range was too short ?"

Shall I continue ? No, not really.

You know what makes me so upset ?

Logic and method. The lack of.

T.

[steve]

Commenting that line out does not appear to help. Is there anything else that could be the cause?

Below is at 20 dBm. I'm guessing its saying that every packet is lost due to collision at the given input rate and step distance? 

--

0.0049019s YansWifiPhy:StartReceivePacket(0x133af20, 0x1363900, -69.3869, ErpOfdmRate54Mbps, 0, 0)

0.0049019s drop packet because already in Tx (power=2.89278e-10W)

0.0049019s YansWifiPhy:StartReceivePacket(0x1336ab0, 0x13a1490, -71.5068, ErpOfdmRate54Mbps, 0, 0)

0.0049019s drop packet because already in Tx (power=1.7755e-10W)

0.00490192s YansWifiPhy:StartReceivePacket(0x1329c40, 0x13a29f0, -71.5068, ErpOfdmRate54Mbps, 0, 0)

0.00490192s drop packet because already in Tx (power=1.7755e-10W)

0.00494372s YansWifiPhy:EndReceive(0x132e190, 0x1362120, 0x12cd660)

0.00494372s mode=54000000, snr=106863, per=1, size=88

0.00494376s YansWifiPhy:EndReceive(0x13617c0, 0x138f810, 0x1327870)

0.00494376s mode=54000000, snr=13357.9, per=1, size=88

0.00530775s YansWifiPhy:SendPacket(0x13617c0, 0x13a29f0, ErpOfdmRate54Mbps, 0, 0, 0)

--

Steve

[Sebastien Deronne]

mode=54000000, snr=106863, per=1, size=88

Such SNR value for such small frame size should never give a PER = 1!

There is still an issue in your code somewhere...

[Sebastien Deronne]

At which distance are you by the way?

[Tommaso Pecorella]

@Sebastien, don't forget that he also changed the sensitivity, noise figure and so on. Basically his WiFi is all but "normal". I didn't do the math, but I'd like to know which params are giving that results. Also because I tried to launch the script with a 20 dBm Tx power and the output is 113.5 Mbps, not that bad.

@steve... a more delicate question. Let me ask it straight so we avoid any doubt.

In the launch script you attached, there's a nice copyright header. All perfectly fine, it doesn't violate the ns-3 copyrights. Still, it's somewhat disturbing me. The point is: if you borrowed the script from somewhere else and you adapted it, you can stop reading.

If you are the one in the copyright message, then I guess you plan to use the simulation results in a more serious way than the usual. Then my question is: do you understand that we (the ones that usually reply to the group) are basically co-authoring your simulations ? How do you plan to thank our efforts ?

It may seems a strange question, but there's a subtle difference between helping a user on basic things, give a student a direction to avoid huge mistakes, and fixing the simulations of a guy who's authoring books.

Cheers,

T.

[steve]

The script is borrowed and modified from another project (using ns-3 to simulate molecular motors and biological communication). Nothing remotely related to wifi. Sorry, I did not bother to remove it.

Maybe what I should do is erase my ns-3 completely and try re-installing from scratch and start again making sure the 3 x 3 mesh works properly. The goal is to simulate an 11s comprised of thousands of nodes over a metropolitan area and see how well it matches the real implementation. I'm particularly interested in proactive tree formation under a variety of RF conditions (to be added later). 

There may be opportunities here.

[Tommaso Pecorella]

Answers in line.

On Thursday, April 16, 2015 at 3:05:23 PM UTC+2, steve wrote:

The script is borrowed and modified from another project (using ns-3 to simulate molecular motors and biological communication). Nothing remotely related to wifi. Sorry, I did not bother to remove it.

Nice. Please remember to send the links to any publication using ns-3 to Tom Henderson. We keep a bibliography of papers / books using ns-3.

 

Maybe what I should do is erase my ns-3 completely and try re-installing from scratch and start again making sure the 3 x 3 mesh works properly. The goal is to simulate an 11s comprised of thousands of nodes over a metropolitan area and see how well it matches the real implementation. I'm particularly interested in proactive tree formation under a variety of RF conditions (to be added later). 

If you did heavy changes and you don't know how to go back... yes, it's a good idea. I'd also suggest sto use a versioning system, like mercurial queues.

 

There may be opportunities here.

There are always opportunities.

[Droan Malik]

is this an output of your pcap file?