How to calculate the AP's contention, defer and retransmission times

126 views
Skip to first unread message

PN

unread,
Sep 8, 2017, 3:45:21 PM9/8/17
to ns-3-users

I want to calculate the time gap between the time instance where the AP starts contenting to transmit a packet and the time instance when it wins the channel and transmits the packet. I want to do this for every single packet the AP transmits on the downlink to the STAs for every STA.


This time gap will include all the retransmissions, deferring because some other node captured the channel, contention duration, etc.


To do this, I need two timestamps:


1. The timestamp at which the AP started to contend to transmit the packet for the first time i.e. prior to this time instance this particular packet had not reached the head of the queue.

2. The timestamp at which the AP finished the transmission of this packet.


I looked up the list of available ns-3 traces (https://www.nsnam.org/~pdbarnes/docs-related/group___trace_source_list.html). Unfortunately, I could not find any trace that provides these two timestamps.


Does anyone know of any way by which these timestamps can be extracted without making any modifications to the ns-3 wifi module code? Or maybe how this value can be extracted indirectly?


Or if I need to add a trace to the ns-3 wifi module myself, can someone please point me to which function in the wifi module code should this trace be fired from?


Thanks a lot! Your help is highly appreciated.

Rediet

unread,
Sep 11, 2017, 9:55:06 AM9/11/17
to ns-3-users
Hello,

I don't think that it's possible to get the first timestamp without adding a trace source. You can add it in DcfState::NotifyAccessRequested through a callback set in DcaTxop, just like what's done for NotifyAccessGranted. I'm not 100% sure though...
As for the second timestamp, you might as well set up another trace source that will be called in DcaTxop::EndTxNoAck and for ACKed transmissions you'll have to add a line or two in MacLow and DcaTxop.

Rediet

sebastie...@gmail.com

unread,
Sep 11, 2017, 2:45:38 PM9/11/17
to ns-3-users
For the first timestamp, DcfState::NotifyAccessRequested is called each time a packet is queued, which is not really what we want here.
I suggest instead to add a trace source in DcaTxop::RestartAccessIfNeeded (void) and DcaTxop::StartAccessIfNeeded (in case of non QoS, do that in EdcaTxopN in case of QoS), but IMO you need to fire the trace only if m_currentPacket == 0. 
For the second timestamp, I assume you can use the existing trace source MacTxFinalDataSucceeded.


--
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 the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, 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.

Sebastien Deronne

unread,
Sep 11, 2017, 2:46:29 PM9/11/17
to ns-3-users

PN

unread,
Sep 11, 2017, 7:25:21 PM9/11/17
to ns-3-users
Hey Sebastien ,

Thanks for your reply. I really appreciate it.

Just to be sure I'm understanding this correctly:

To get the first timestamp, we need two traces:

For non-QoS packets, the two traces should be:

one from DcaTxop::RestartAccessIfNeeded and one from DcaTxop::StartAccessIfNeeded. And in both cases we fire the trace when m_currentPacket == 0.

For QoS packets, the two traces should be:

one from EdcaTxopN::RestartAccessIfNeeded and one from EdcaTxopN::StartAccessIfNeeded fired when when m_currentPacket == 0

The criteria for "m_currentPacket == 0" ensures that this is the first time the backoff is being taken. m_currentPacket != 0 addresses the case of a retransmission.

Is this correct? Why do we need two traces in each case?

Also, I could not find the trace MacTxFinalDataSucceeded in ns doxygen documentation. Is this trace available in ns-3.26 and if so what path do I need to set in Config::Set and Config::Connect to access it?

Or is this a new trace being added in ns3-dev? If so, can I add it to any function in ns 3.26?

Sorry for such a long reply and thanks a lot for your response!

Sebastien Deronne

unread,
Sep 12, 2017, 6:03:03 AM9/12/17
to ns-3-users
Sorry, my mistake, the trace source is indeed not present (I had added for my own purpose in the past, but I never added this to the dev branch).
You can fire this tracer source in WifiRemoteStationManager::ReportDataOk, which is triggered when the ACK is received.

Your understanding is correct. If you only consider non QoS packets, you can first limit yourself to DcaTxop.
Note that if you consider aggregation, this might be more complex, I did not consider that case, this is up to you to test and eventually adapt my proposal in any case.

PN

unread,
Sep 12, 2017, 5:04:45 PM9/12/17
to ns-3-users
Thanks very much Sebastien! Is there a way to figure out whether the packets in the simulation are QoS or non-QoS. Does this depend on TCP vs UDP or are there other criteria used?

PN

unread,
Sep 29, 2017, 5:39:24 PM9/29/17
to ns-3-users
Hey Sebastien,

I tried the method that you had recommended to find the the timestamp at which the AP starts to contend to transmit a packet for the first time (i.e. prior to this time instance this particular packet had not reached the head of the queue).


What I notice is that the number of timestamps that I obtain after the entire simulation are more than the number of packets that get enqueued at the AP. I was assuming that since I print out the timestamps only for the first time the AP starts to contend for a packet (and not for any following retransmissions), the total number of timestamps I would obtain would be less than or equal to the number of packets enqueued at the AP during the entire course of the simulation.


I checked to ensure that these were all data packets (i.e. no ARP or other control packets). The only reason that I can think of is if EdcaTxopN::RestartAccessIfNeeded and/or EdcaTxopN::StartAccessIfNeeded gets called for a retransmission and the timestamp gets printed out. However, before printing, I do ensure that I check for m_currentPacket being equal to 0.


In my simulation, I have one AP and a variable number of STAs. For one of the STAs, there is a downlink TCP transmission. Other STAs have fully backlogged UDP flows for uplink transmission. So on the downlink, there is only one TCP flow. I want to measure these timestamps only for this one flow.


Here is the modified code from edca-txop-n.cc. I'm not adding a trace yet. What I'm doing is that I check for the transmitter and receiver address and the packet size and print only if the transmitter and receiver addresses match. These addresses are accurate and do not change in my simulation as I vary the number of STAs. I understand that this might not be the safest way. But I think this should give me the same values regardless.


void
EdcaTxopN::RestartAccessIfNeeded (void)
{
  NS_LOG_FUNCTION
(this);
 
if ((m_currentPacket != 0
       
|| !m_queue->IsEmpty () || m_baManager->HasPackets ())
     
&& !m_dcf->IsAccessRequested ())
   
{
     
Ptr<const Packet> packet;
     
WifiMacHeader hdr;
     
if (m_currentPacket != 0)
       
{
          packet
= m_currentPacket;
          hdr
= m_currentHdr;
       
}
     
else if (m_baManager->HasPackets ())
       
{
          packet
= m_baManager->PeekNextPacket (hdr);
       
}
     
else if (m_queue->PeekFirstAvailable (&hdr, m_currentPacketTimestamp, m_qosBlockedDestinations) != 0)
       
{
          packet
= m_queue->PeekFirstAvailable (&hdr, m_currentPacketTimestamp, m_qosBlockedDestinations);
         
/// This is my modification: extracting the time at which the AP started contending for the packet for the first time.
         
if(hdr.GetAddr2 () == Mac48Address ("00:00:00:00:00:03") && hdr.GetAddr1 () == Mac48Address ("00:00:00:00:00:04") && packet->GetSize() == 1084){
           
if(m_currentPacket == 0){
               
std::cout << Simulator::Now().GetSeconds() << "," << (double)packet->GetSize() << std::endl;
           
}
         
}         
       
}
     
if (packet != 0)
       
{
          m_isAccessRequestedForRts
= m_stationManager->NeedRts (hdr.GetAddr1 (), &hdr, packet, m_low->GetDataTxVector (packet, &hdr));
       
}
     
else
       
{
          m_isAccessRequestedForRts
= false;
       
}
      m_manager
->RequestAccess (m_dcf);
   
}
}

void
EdcaTxopN::StartAccessIfNeeded (void)
{
  NS_LOG_FUNCTION (this);
  if (m_currentPacket == 0
      && (!m_queue->IsEmpty () || m_baManager->HasPackets ())
      && !m_dcf->IsAccessRequested ())
    {
      Ptr<const Packet> packet;
      WifiMacHeader hdr;
      if (m_currentPacket != 0)
        {
          packet = m_currentPacket;
          hdr = m_currentHdr;
        }
      else if (m_baManager->HasPackets ())
        {
          packet = m_baManager->PeekNextPacket (hdr);
        }
      else if (m_queue->PeekFirstAvailable (&hdr, m_currentPacketTimestamp, m_qosBlockedDestinations) != 0)
        {
          packet = m_queue->PeekFirstAvailable (&hdr, m_currentPacketTimestamp, m_qosBlockedDestinations);         
         
/// This is my modification: extracting the time at which the AP started contending for the packet for the first time.
          if(hdr.GetAddr2 () == Mac48Address ("00:00:00:00:00:03") && hdr.GetAddr1 () == Mac48Address ("00:00:00:00:00:04") && packet->GetSize() == 1084){
            if(m_currentPacket == 0){
               
std::cout << Simulator::Now().GetSeconds() << "," << (double)packet->GetSize() << std::endl;           
            }
          }
        }
      if (packet != 0)
        {
          m_isAccessRequestedForRts = m_stationManager->NeedRts (hdr.GetAddr1 (), &hdr, packet, m_low->GetDataTxVector (packet, &hdr));
        }
      else
        {
          m_isAccessRequestedForRts = false;
        }
      m_manager->RequestAccess (m_dcf);
    }
}

Thanks a lot!


On Tuesday, September 12, 2017 at 5:03:03 AM UTC-5, Sebastien Deronne wrote:
Reply all
Reply to author
Forward
0 new messages