BO: Buffer Occupancy for WiFi nodes

[George]

Hello,

I am intrested in using BO (Buffer Occupancy) measurements for a coexistence network simulation that includes WiFi. 

I was curious if there are any existing traces or information in the AP protocol stack that I could use for this. 

If not, can someone please point me towards the part of the WiFi AP protocol stack and/or source files where I could implement something like this? Somewhere  I could measure the time that the buffer had something to send. If someone would have a rough idea of an optimal way of implementing this for WiFi network I would much appreciate some input! 

Here is also the 3GPP definitoon of the buffer occupancy as a refference of what I want to achieve: 

Best regards,

George

[George]

Sorry, it seems the .png attachment failed. Here is the definition of buffer occupancy:

 - For DL-only coexistence evaluations:

- Buffer occupancy of the i-th small cell/UE (Wi-Fi & LAA) = sum of the period of time during which the i-th small cell/UE has data to transmit including retransmissions (i.e., its queue is not empty) / total simulation time

- Average buffer occupancy of the i-th small cell/UE (Wi-Fi & LAA) = sum of the period of time during which the i-th small cell/UE has data to transmit including retransmissions (i.e., its queue is not empty) / total simulation time

[Tom Henderson]

I attempted to answer on Zulip just now; copy-pasting the response here:


Here is an educated guess-- I don't think there are examples or
documentation around this.

Packets are stored in instances of WifiMacQueue, which are subclasses of
the Queue class found in src/network/utils. New transmissions and frames
awaiting acknowledgment (i.e. possible retransmissions) are all stored
in these queues. The base class Queue has trace sources for Enqueue,
Dequeue, Drop. There will be five such queues for each net device (one
for the DCF frames like beacons, and four for the four different AC
categories). Therefore, if you hook the traces of all five of these
queues, and monitor their enqueue, dequeue, and drop traces, you could
monitor the buffer occupancy by monitoring when the aggregate counts are
zero or non-zero.

In an 802.11be multi-link device, there will be replication of the above
for each link.

The config paths are

"/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/Txop/Queue"
"/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/BE_Txop/Queue"
"/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/BK_Txop/Queue"
"/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/VO_Txop/Queue"
"/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/VI_Txop/Queue"

I think it would be helpful to you and others if we made this less
complicated and directly provided a buffer occupancy trace.

[George]

Hi Tom Henderson,

Your description is very clear, however, I have never used these Config paths I struggle to get anything out of them. 

I cannot even connect to the config paths so I think I am doing something wrong.

However, I saw that in QosTxop there are traces for TxopTrace which I have used to see if I can calculate a BO% as shown bellow in the code snippet. 
I get most of the data from BE_Txop and some (only a small % like 0.003%) from VO_Txop. 
But I cannot get anything out of Txop, I have tried connecting using Pointer to Txop or QosTxop and neither work (get "Attempted to dereference zero pointers")

For all those, I schedule ConnectToTracesWithDelay some 400ms after the simulation starts to make sure the data I try to access is existent. 

Using this approach of aggregating TxopTrace at each AP node, gives me some BO% that looks ok for low traffic FTP lambda 0.25. But fails to scale up as sensitively as others have shown in 3GPP papers (e.g.,  Medium load at FTP lambda 0.38 and High load at 0.48) for similar setups to mine. Now I know these values may defer but I feel is not really accurate the way I am doing it. 

It would be great if you could give me maybe some clarification how to successfully connect to those Config Paths, and also what kind of data I should expect from those.

Thank you. 

void
WifiSetup ::ConnectToTracesWithDelay(NetDeviceContainer m_gnbDev)
{
    for (uint32_t i = 0; i < m_gnbDev.GetN(); ++i)
    {
        auto netDevice = DynamicCast<WifiNetDevice>(m_gnbDev.Get(i));
        // std::stringstream nodeId;
        uint32_t nodeId = m_gnbDev.Get(i)->GetNode()->GetId();
        uint32_t deviceid = m_gnbDev.Get(i)->GetIfIndex();
        std::ostringstream oss;
        oss.str("");

        PointerValue ptr_BETxop, ptr_Txop, ptr_BKTxop, ptr_VOTxop, ptr_VITxop;
        netDevice->GetMac()->GetAttribute("BE_Txop", ptr_BETxop);
        netDevice->GetMac()->GetAttribute("Txop", ptr_Txop);
        netDevice->GetMac()->GetAttribute("BK_Txop", ptr_BKTxop);
        netDevice->GetMac()->GetAttribute("VO_Txop", ptr_VOTxop);
        netDevice->GetMac()->GetAttribute("VI_Txop", ptr_VITxop);

        Ptr<QosTxop> BE_Txop = ptr_BETxop.Get<QosTxop>();
        Ptr<Txop> txop = ptr_Txop.Get<Txop>();
        Ptr<QosTxop> BK_Txop = ptr_BKTxop.Get<QosTxop>();
        Ptr<QosTxop> VO_Txop = ptr_VOTxop.Get<QosTxop>();
        Ptr<QosTxop> VI_Txop = ptr_VITxop.Get<QosTxop>();

        BE_Txop->TraceConnect("TxopTrace",
                           nodeId.str(),
                           MakeCallback(&WifiSetup::ConnectToBETxop, this));


        oss << "/NodeList/" << nodeId << "/DeviceList/" << deviceid
            << "/$ns3::WifiNetDevice/Mac/BE_Txop/Queue";
        bool check = 0;
        check = Config::ConnectFailSafe(oss.str(), MakeCallback(&WifiSetup::ConnectToBETxop, this));
        std::cout << check << std::endl;
    }
}

[George]

Here are also some BO% I managed to get using the TxopTrace for BE_Txop at FTP lambda = 0.25 and 0.66. 

At 0.25 it looks ok since it should be in Low load 10%~25%. However, at l =0.66 should be way over in High load (above 55%) according to other simulations,  but I bearly get a small change in the BO%. 
I should mention this is 20Mhz BW, filesize = 0.5 Mbps, sub 7Ghz, InH model with 5UEs per 1 AP.