Isn't this more of an order of execution issue than a bug?

Using the helpers, typically users will configure the desired standard, which will result in a number of attributes being set to standards-compliant values; e.g.:

  wifi.SetStandard (WIFI_PHY_STANDARD_80211b);

It is possible to later set timing attributes to non-standard values after the install has occurred.

So rather than add ways to prevent overwriting these attributes by ConfigureStandard () if the user has changed the default values beforehand, I wonder whether the solution is to better document what exactly happens to attributes by using the WifiHelper::Install() and SetStandard(), and document (and add to some examples) that if user wants to take most of the standard values but alter only a few, he or she needs to perform configuration to non-standard values after the WifiHelper::Install() has occurred, or else avoid the helpers and do things step-by-step.

Setting attributes after Install() can be done with Config paths, but it may also be helpful to add some new helper methods that would do a SetAttribute() on an existing NetDeviceContainer that has been installed.

e.g.

  WifiHelper wifi;
  wifi.SetStandard (WIFI_PHY_STANDARD_80211b);
  ...
  NetDeviceContainer devices = wifi.Install (wifiPhy, wifiMac, c);
  // Post-install configuration to non-standard values
  wifi.SetAttributeForType (devices, "ns3::StaWifiMac", "Slot", TimeValue (MicroSeconds (0));

Hi,

I do partially agree. Partially because the user is expecting that if an Attribute is set, its value is honoured, not overwritten.

I think that the SetStandard function should check if any value has been explicitly set by the user and use that one. It's not a matter of functionalities, it's an expected behaviour.

Of course we can document that the SetStandard will overwrite any non-standard value (it sounds logical) and that the user must change the params to its value AFTER the full initialisation is finished. This may be further complicated by the fact that some stuff is done by WifiNetDevice::DoInitialize (void)... like the EdcatTxOp params.

(In reply to Tommaso Pecorella from comment #2)
> Hi,
> 
> I do partially agree. Partially because the user is expecting that if an
> Attribute is set, its value is honoured, not overwritten.
> 
> I think that the SetStandard function should check if any value has been
> explicitly set by the user and use that one. It's not a matter of
> functionalities, it's an expected behaviour.

I'm not aware of a facility in the attribute system that would allow SetStandard() to easily check this (to query for the original compiled-in value and check it against the current value).  

However, it seems like the attributes in question store their default values in getters in the WifiMac; e.g. GetDefaultSifs(), so it seems like it would be straightforward to implement something like this for each such attribute:

  if (GetSifs() == GetDefaultSifs())
    SetSifs (MicroSeconds (16));

So, I would be OK with that solution, provided that it is documented in WifiHelper that if the user had previously configured a non-default value of certain attributes, that WifiHelper::install() (and SetStandard()) won't rewrite the values of such attributes.

Hi Tom,

It's indeed the solution I used so far for my own simulations.
Do you want me to provide a patch implementing that solution?

Regards,
Sébastien

(In reply to sebastien.deronne from comment #4)
> Hi Tom,
> 
> It's indeed the solution I used so far for my own simulations.
> Do you want me to provide a patch implementing that solution?
> 
> Regards,
> Sébastien

Yes, seems like rough consensus to make this change.

There is still an issue with the proposed solution, because the default values are based on IEEE 802.11a. Here is the case of the default slot value:

Time
WifiMac::GetDefaultSlot (void)
{
  // 802.11-a specific
  return MicroSeconds (9);
}

with the proposed solution as follows in the case of IEEE 802.11b:

  if(GetSlot() == GetDefaultSlot())
  {
      SetSlot (MicroSeconds (20));
  }

If the user specifies a slot value, the good point is that the value is no longer overwritten by SetStandard(). However, the bad point is that if we configure a 802.11b network with a slot of 9 microseconds (ok, it is a bad idea to set such value for the slot time but it is just an example), it will not be set as expected (because GetSlot() == GetDefaultSlot() !!!) and the slot time value will be equal to 20 microseconds.

A bad (but working) solution that I used for my own simulations was to change it as follows:

Time
WifiMac::GetDefaultSlot (void)
{
  // 802.11-a specific
  return MicroSeconds (-1);
}

since a slot value of -1 will never be set by a user, the condition GetSlot() == GetDefaultSlot() will always be true if the user has tuned the slot time value.
Nevertheless, I think another better solution should be implemented.

Does someone have any proposal?

> since a slot value of -1 will never be set by a user, the condition
> GetSlot() == GetDefaultSlot() will always be true if the user has tuned the
> slot time value.
> Nevertheless, I think another better solution should be implemented.

I don't support using the invalid -1 value, because it forces users to call SetStandard() to remedy the situation.

I also see the issue now with the attribute accidently coinciding with the default; one can envision that the user runs simulations from an external script with slot times varying by 1 in the range 1 to 20, and getting anomalous data when the value 9 occurs, and not being able to understand/debug this point.

I guess at this point I feel again that the solution is to document that when the helper and ConfigureStandard() is used in programs, that certain default values that the user may have configured prior to the Install() may be overwritten (and list these out in the documentation).  Then, possibly provide new API (or use existing Config::Set API) for post-install configuration of attributes on containers, and show examples of how to do this in some of the wireless examples.

example:

Config::Set ("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Mac/Slot", TimeValue (MicroSeconds (9));

Thanks for your comment Tom, I will prepare a patch considering your proposal.

I made some tests, and I think we do not need to change the current code.

Anyway, we should correctly document that if the user wants to overwrite standard values, he simple should do it after having installed nodes (i.e. when is called SetStandard). For instance, here is how it should be done for the slottime:

WifiHelper wifi = WifiHelper::Default ();
wifi.SetStandard (WIFI_PHY_STANDARD_80211b);

//HtWifiMacHelper mac = HtWifiMacHelper::Default ();
NqosWifiMacHelper mac = NqosWifiMacHelper::Default ();
    
Ssid ssid = Ssid ("ns-3-ssid");
mac.SetType ("ns3::StaWifiMac",
             "Ssid", SsidValue (ssid),
             "ActiveProbing", BooleanValue (false));
  
NetDeviceContainer staDevices;
staDevices = wifi.Install (phy, mac, wifiStaNodes);

mac.SetType ("ns3::ApWifiMac",
             "Ssid", SsidValue (ssid),
             "BeaconInterval", TimeValue (MicroSeconds(102400)),
             "BeaconGeneration", BooleanValue (true));

NetDeviceContainer apDevices;
apDevices = wifi.Install (phy, mac, wifiApNode);

Config::Set ("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Mac/Slot", TimeValue (MicroSeconds (slot))); //here, we overwrite the standard slot duration with the slot value specified by the user

Do you agree on this?
If yes, I will start to work on the documentation.

> 
> Config::Set ("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Mac/Slot",
> TimeValue (MicroSeconds (slot))); //here, we overwrite the standard slot
> duration with the slot value specified by the user
> 
> Do you agree on this?
> If yes, I will start to work on the documentation.

Yes, unless no other suggestions are voiced.

Created attachment 1954 [details]
add documentation for setting wifi attributes

patch pushed in changeset 11184:d1759767295f