802.11e QoS - Error when TxOp limit modified in Adhoc mode

271 views
Skip to first unread message

camilo montero

unread,
Oct 18, 2017, 12:34:05 PM10/18/17
to ns-3-users

Dear NS3 users,


I set up a mesh network with some Infrastructure BSS and some Independent (Adhoc) BSS. Look the picture attached.


Characteristics of the network:


  • Only Uplink direction is considered (Sources: Sta1-Sta10, Sink: Server).
  • All the nodes are in the same Collision Domain.
  • Adhoc Wireless1 link is using the same frequency channel than Access Wireless2 link (channel 36 - 5Ghz Band).
  • Adhoc Wireless1 is an adhoc link and allows an Independent BSS between BackhaulAP1 and AccessAP1.
  • Access Wireless2 is an access link and allows an Infrastructure BSS between AccessAP2 and Sta10.
  • Sta10 (link Access Wireless2) compete with AccessAP1 (Interface 2-link Adhoc Wireless1) for the channel 36.


Goal: I want to modify the TxOp limit parameter of the Access Category Best Effort (AC=BE) of Access AP1 on the interface 2 (See the picture for a better illustration), so that AP1 can grant the medium for a longer period of time and can forward all the packets coming from the Sta1 to Sta9 to the Backhaul AP1.


According to the Documentation, an AP sends the Edca TxOp limit value in the beacon frame to the stations connected to it. So, in my case BackhaulAP1 should send the TxOp limit value to the Access AP1 in the beacon frame. But, it seems that the NS3 AdhocWifiMac class does not implement any kind of beacon generation, therefore I am getting the following error:


Error:___________________________________________


((gdb) run


msg="Invalid attribute set (ActiveProbing) on ns3::AdhocWifiMac", file=../src/core/model/object-factory.cc, line=75

terminate called without an active exception


Program received signal SIGABRT, Aborted.

0x00007fffeae59428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54

54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) where

#0 0x00007fffeae59428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54

#1 0x00007fffeae5b02a in __GI_abort () at abort.c:89

#2 0x00007fffeb9b984d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

#3 0x00007fffeb9b76b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

#4 0x00007fffeb9b7701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

#5 0x00007fffef1ec446 in ns3::ObjectFactory::Set (this=0x7fffffffa888, name="ActiveProbing", value=...)

at ../src/core/model/object-factory.cc:75

#6 0x00007ffff6546b41 in ns3::NqosWifiMacHelper::SetType (this=0x7fffffffa860, type="ns3::AdhocWifiMac", n0="QosSupported", v0=...,

n1="Ssid", v1=..., n2="ActiveProbing", v2=..., n3="", v3=..., n4="", v4=..., n5="", v5=..., n6="", v6=..., n7="", v7=..., n8="", v8=...,

n9="", v9=..., n10="", v10=...) at ../src/wifi/helper/nqos-wifi-mac-helper.cc:66

#7 0x000000000041a8ab in main (argc=1, argv=0x7fffffffd938) at ../scratch/single_station_dev.cc:369

________________________________________________



My two questions are:


  1. Is correct what i am assuming that the error is because NS3 AdhocWifiMac class does not implement any kind of beacon generation
  2. Is there a way I can modify the TxOp limit parameter of the AccessAP1 on the Interface 2, so that this interface 2 can grant the medium for more time?


I saw the example 80211e-txop.cc, but this is based in Infrastructured BSS Mode. I could not find an example for Adhoc Independent BSS Mode. Is there any somewhere in the repo?


Any comment would be very useful.


Thanks in advanced.

Cheers,
Camilo



complex_sce.png

Rediet

unread,
Oct 19, 2017, 3:49:24 AM10/19/17
to ns-3-users
Hi Camilo,

It doesn't seem that the error is related to Beacon generation but rather to probing (ActiveProbing is an attribute of a STA in infrastructure mode in ns-3, even if it can be used in Adhoc mode normally). By the way, I don't see any beacon generation attributes in the current AdhocWifMac, so you'll have to extend it.

Rediet

camilo montero

unread,
Oct 19, 2017, 11:46:55 AM10/19/17
to ns-3-users
Hi Rediet,

thanks for your answer.
Yes, you are right. That specific error i posted is for active probing, as i had it enable for the WifiMac of the Adhoc device.
I disable it and ran it and i get the following error:
Error:
_______________________________________________________________________________________
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff726ce22 in ns3::PeekPointer<ns3::WifiMac> (p=...) at ./ns3/ptr.h:566
566  return p.m_ptr;
(gdb) where
#0  0x00007ffff726ce22 in ns3::PeekPointer<ns3::WifiMac> (p=...) at ./ns3/ptr.h:566
#1  0x00007ffff6b7b638 in ns3::Ptr<ns3::WifiMac>::Ptr (this=0x7fffffff8890, o=...) at ./ns3/ptr.h:741
#2  0x00007ffff6438111 in ns3::WifiNetDevice::GetMac (this=0x0) at ../src/wifi/model/wifi-net-device.cc:224
#3  0x0000000000414626 in AssignTxOp (NodeAp=..., nodeFlows=9, maxIntFlow=10, CW=false) at ../scratch/single_station_dev.cc:45
#4  0x000000000041b185 in main (argc=1, argv=0x7fffffffd938) at ../scratch/single_station_dev.cc:386
_______________________________________________________________________________________ 


The line of code of my script provoking the error is the one in bold:

  Ptr<NetDevice> dev = NodeAp->GetDevice(0);
  Ptr<WifiNetDevice> wifi_dev = DynamicCast<WifiNetDevice>(dev);
  Ptr<WifiMac> wifi_mac = wifi_dev->GetMac();
  PointerValue ptr;
  Ptr<EdcaTxopN> edca;
  uint32_t txoplimit = 8160;
  
wifi_mac->GetAttribute("BE_EdcaTxopN", ptr);
  edca = ptr.Get<EdcaTxopN>();
  edca->SetTxopLimit (MicroSeconds (txoplimit));
  
The error is triggered when this line of code of the file /ns3/ptr.h is reached:

template <typename U>
U * PeekPointer (const Ptr<U> &p)
{
  return p.m_ptr;
}

The PeekPointer is used to extract the raw pointer as far as i understand.
I imagine that this error is because the AdhocWifiMac does not implement anything for the beacon generation.

So your solution is to extend the AdhocWifiMac class, with similar methods than ApWifiMac and StaWifiMac. 

But does it make sense to extend this, just to have the AccessAp1 Interface 2 behaving as a Station and to have the BackhaulAp1 behaving as an AccessPoint, when in reality they are nodes communicating through an Adhoc wireless link???

Is there not a faster way in which i can directly modify the BE_EdcaTxopN Attribute of the AccessAp1 Interface 2, so that this can grant the medium longer?

Best,
Camilo 

Rediet

unread,
Oct 20, 2017, 3:29:20 AM10/20/17
to ns-3-users
Hi Camilo,

Actually I thought that you really wanted to add beacon generation, but if you don't need it, I don't see why you'll be forced to implement it. The way you're doing it seems correct, since Edca queues are in RegularWifiMac.
The error seems to be coming from the fact that a WifiMac object wasn't found. Are you sure that the WifiNetDevice is the first NetDevice of your node? Check if the pointer wifi_dev pointer is not null to be sure.

Rediet

camilo montero

unread,
Oct 22, 2017, 1:50:08 PM10/22/17
to ns-3-users
Hi Rediet,

thanks for answering.
As you said, the problem was in the WifiNetDevice index. It was wrong and I made the correction. Now there is no error anymore, but I am not getting the expected result.

What is shown in the example 80211e-txop.cc is that the "BE_EdcaTxopN" attribute of the wifi_mac object of an Access Point in a BSS is modified, and as far as I understand the AP transmit this new BE_EdcaTxopN value to the stations via the Beacon frame. I have created my own scenarios and I have used the same way (modifying the BE_EdcaTxopN of the AP and it transmit this new value to the stations in a BSS) and it has been working as expected in Infrastructure BSS scenarios (AP with stations).

Because the part of this scenario I need to modify is Adhoc mode (Independent BSS) and it does not implement any Beacon generation, I do not know how to modify the BE_EdcaTxopN of the AP Access node directly (without transmitting this value via Beacon).

Do you know a way to do that? 

Here is part of the code relevant to this:

Network Set up (Independent BSS)

wifiPhy2.Set ("ChannelNumber", UintegerValue(36));

  Ssid ssid2 = Ssid("BhApMultiCluster");
  wifiMac.SetType ("ns3::AdhocWifiMac",
                   "QosSupported", BooleanValue (true),
                   "Ssid", SsidValue (ssid2));

  NetDeviceContainer ApMultiDevBh = wifi.Install(wifiPhy2, wifiMac, bhApMulti.Get(1));

  wifiMac.SetType ("ns3::AdhocWifiMac",
                   "QosSupported", BooleanValue (true),
                   "Ssid", SsidValue (ssid2));

  NetDeviceContainer bhMultiDev = wifi.Install(wifiPhy2, wifiMac, bhApMulti.Get(0));


  double maxFlow = 10; // SUM OF FLOWS IN INTERFERENCE RANGE
  uint16_t flowsMulti=9;
  uint32_t txopsMulti=0;

  if(algorithm == 1){
    txopsMulti = AssignTxOp(bhApMulti.Get(1), flowsMulti, maxFlow, cw);
  }


Method for New TxOp Assignation:

uint32_t AssignTxOp(Ptr<Node> NodeAp, uint32_t nodeFlows, double maxIntFlow, bool CW){

  //Modify EDCA configuration (TXOP limit) for AC_BE

  Ptr<NetDevice> dev = NodeAp->GetDevice(1);
  Ptr<WifiNetDevice> wifi_dev = DynamicCast<WifiNetDevice>(dev);
  Ptr<WifiMac> wifi_mac = wifi_dev->GetMac();
  PointerValue ptr;
  Ptr<EdcaTxopN> edca;
  uint32_t txoplimit = 8160;
  uint32_t temp1, txOpNewValue = 0 ;
  wifi_mac->GetAttribute("BE_EdcaTxopN", ptr);
  edca = ptr.Get<EdcaTxopN>();

  temp1 = (txoplimit * nodeFlows) / maxIntFlow;
  txOpNewValue = temp1 - (temp1 % 32);
  cout << "The txOpTimeNew value is: " << txOpNewValue << endl;
  edca->SetTxopLimit (MicroSeconds (txOpNewValue));
  cout << "The new TxOp is: " << edca->GetTxopLimit() << endl;

  return txOpNewValue;
}

I appreciate any help.
Camilo

Rediet

unread,
Oct 30, 2017, 9:31:07 AM10/30/17
to ns-3-users
Hi Camilo,

Why not directly modify the parameters for both APs that are in Adhoc mode then? Won't it be simpler than propagating the parameter through Beacons? It's a first step but if you say that you have managed to make it work through Beacons in infrastructure mode, then using this simple workaround in Adhoc mode shouldn't be complicated, should it?

Rediet
Reply all
Reply to author
Forward
0 new messages