Control of MPDU aggregation via edca-txop-n.cc class

[Angelina]

Hi,

I want to insert a waiting time to increase the probability of arriving of new packets which can be aggregated together, thus when the access is granted we wait for a predefined time. I should so modify the method NotifyAccessGranted() in the class edca-txop-n.cc. the problem is that I need to count the number of packets that arrives to the queue during the waiting time!!

help please and thank you

[Rediet]

Hello Angelina,

Are you sure that you want to add the timer to NotifyAccessGranted? Because if you do so, considering that this method is called by DcfManager through the corresponding DcfState whenever the AIFS and BO timers have expired, you'll mess up the underlying CSMA/CA...

If you plan on waiting for more packets in the queue, why not modify the StartAccessIfNeeded method (which is called before timers are activated). You can, for example, schedule, if not already scheduled, a call to a method (X seconds later) that will sollicit DcfManager. You can thus, during the wait time (i.e. when scheduled flag is raised), peek at the queue to count for packets.

BR,

Rediet

[kaouthar mansour]

Hi,

Yes I should add the timer before asking for access, so it should be added in the method StartAccessRequest just before calling the DCF manager, but plea how can I schedule a call for the method that permit to wait for a predefined time?

Thanks

kaouther MANSOUR

Ingénieur chercheur en Réseaux Informatiques et Télécommunication

--
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 a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-BOxQnNrX7A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@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.

[Rediet]

Konstantinos has already answered to that part in another post...

Le jeudi 22 juin 2017 19:33:15 UTC+2, Angelina a écrit :

Hi,

Yes I should add the timer before asking for access, so it should be added in the method StartAccessRequest just before calling the DCF manager, but plea how can I schedule a call for the method that permit to wait for a predefined time?

Thanks

kaouther MANSOUR

Ingénieur chercheur en Réseaux Informatiques et Télécommunication

2017-06-22 19:16 GMT+02:00 Rediet <redietea...@gmail.com>:

Hello Angelina,

Are you sure that you want to add the timer to NotifyAccessGranted? Because if you do so, considering that this method is called by DcfManager through the corresponding DcfState whenever the AIFS and BO timers have expired, you'll mess up the underlying CSMA/CA...

If you plan on waiting for more packets in the queue, why not modify the StartAccessIfNeeded method (which is called before timers are activated). You can, for example, schedule, if not already scheduled, a call to a method (X seconds later) that will sollicit DcfManager. You can thus, during the wait time (i.e. when scheduled flag is raised), peek at the queue to count for packets.

BR,

Rediet

Le jeudi 22 juin 2017 18:21:48 UTC+2, Angelina a écrit :

Hi,

I want to insert a waiting time to increase the probability of arriving of new packets which can be aggregated together, thus when the access is granted we wait for a predefined time. I should so modify the method NotifyAccessGranted() in the class edca-txop-n.cc. the problem is that I need to count the number of packets that arrives to the queue during the waiting time!!

help please and thank you

--
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 a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-BOxQnNrX7A/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.

[Angelina]

Hi,

I have attached the edca-tx-n.cc file. As I explained ast time, I want to control the A-MPDU aggregation in order to increase the number of aggregated frames, I have added a function CheckQueue () to calculate the number of packets in the queue and I have modified the function EdcaTxopN::StartAccessIfNeeded (void). But the program is not correct. Any one can help me please!!

Le jeudi 22 juin 2017 18:21:48 UTC+2, Angelina a écrit :

[Rediet]

Hi Angelina,

You have forgotten to attach the file. In addition, could you also add the (whole) output of the compiler if there is an error (so that we can understand what you mean by "the program is not correct"), or describe the delta between what you expect and what you have if the code works but not as expected.

[Angelina]

Hi,

Thank you for your help.
I decide to proceed step by step, In the first step I will introduce a waiting time before invoking the RequestAccess function, thus we can aggregate more packet. I have modified the function EdcaTxopN::StartAccessIfNeeded (void),  The output shows that the RequestAccess requested isn't delayed!! please find in attached the edca-tx-n.cc and simple-wifi-aggregation.cc (the program that I'm testing).

the output
Arrival of QoS data packet at+1008000000.0ns
Needs Rts
manager request access at+1008000000.0ns
MacLow::AggregateToAmpdu  aggregate queue size0
MacLow::StartTransmission the number of aggregated packets 0 at  +1008000001.0ns
Arrival of QoS data packet at+1008112017.0ns
Needs Rts
manager request access at+1008112017.0ns
MacLow::AggregateToAmpdu  aggregate queue size0
MacLow::StartTransmission the number of aggregated packets 0 at  +1008200017.0ns
Arrival of QoS data packet at+1008248033.0ns
Needs Rts
manager request access at+1008248033.0ns
Arrival of QoS data packet at+1008248033.0ns
Needs Rts
manager request access at+1008248033.0ns
Arrival of QoS data packet at+1008248033.0ns
Needs Rts
manager request access at+1008248033.0ns
assert failed. cond="!state->IsAccessRequested ()", file=../src/wifi/model/dcf-manager.cc, line=535
terminate called without an active exception
Command ['/home/kaoutherma/Documents/ns3simulations/ns-allinone-3.26/ns-3.26/build/scratch/simple-wifi-aggregation'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run <program> --command-template="gdb --args %s <args>").


Thank you again for your help!

[Rediet]

I have the impression that it is delayed. It is just that the cout is placed within the StartAccessIfNeeded and not in the RequestAccess itself. StartTransmission of MacLow is called 1ns afterwards as configured.

By the way, it's not a good idea to redefine m_DelayedManagerCall...

[kaouthar mansour]

Hi,

Thank you, sorry I didn't understand what do you mean by "StartTransmission of MacLow is called 1ns afterwards as configure", By default StartTransmission is called 1ns after being invocked?

An other point please, how can I know the number of AMPDUs in an aggregated frame?

Thank you again

kaouther MANSOUR

Ingénieur chercheur en Réseaux Informatiques et Télécommunication

--

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 a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-BOxQnNrX7A/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@googlegroups.com.

[Rediet]

Hello,

I was refering to the following call chain, that happens without any delay if the channel was idle upon initial request and that there is no (internal) collision.

EdcaTxopN::StartAccessIfNeeded >>  DcfManager::RequestAccess >> DcfManager::DoGrantAccess >> DcfState::NotifyAccessGranted >> EdcaTxopN::NotifyAccessGranted >> MacLow::StartTransmission

The 1ns delay that you observe is the one that you have configured in your modified version of EdcaTxopN::StartAccessIfNeeded

//Modification: insert a waiting time before invoking RequestAccess function
EventId m_DelayedManagerCall;
NS_ASSERT (m_DelayedManagerCall.IsExpired ());
m_DelayedManagerCall=Simulator::Schedule(NanoSeconds(1), &DcfManager::RequestAccess,m_manager,m_dcf);
std::cout<<"manager request access at"<< Simulator::Now()<<'\n';
//m_manager->RequestAccess (m_dcf);

If you want to be sure about this, move the last std::cout to DcfManager::RequestAccess. Because otherwise it will execute it just after having scheduled RequestAccess to be called 1ns later (in other words, it won't stop here, it'll continue once it has put the event in the scheduler's list).

As for the number of A-MPDU in an aggregated frame, it is stored in queueSize variable in MacLow::ForwardDown, just before scheduling the transmissions of MPDUs within the aggregate.

BR,

Rediet

To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.

[kaouthar mansour]

Hi,

Thank you so much. I can now know the number of aggregated mpdus within a frame.

But  I still face problems in delay introduction. The objective from introducing a delay is to enable to aggregate more mpdus, but the output shows that there's no aggregation, each mpdu invoke the RequestAccess by himself. I don't know why, even  there are many frames in the queue which can be aggregated they aren't!

Output

RequestAccess invoked at +921600000.0ns
we are here  SendDataPacket at+921600000.0ns
MacLow::ForwardDown non ampdu+921600000.0ns
MacLow::ForwardDown no aggregation+921600000.0ns

Arrival of QoS data packet at+1008000000.0ns

CheckQueue called at: +1008000002.0ns
CheckQueue the number of the queued paquets 1
RequestAccess invoked at +1008000002.0ns

MacLow::AggregateToAmpdu  aggregate queue size0

MacLow::StartTransmission the number of aggregated packets 0 at  +1008000002.0ns
we are here  SendDataPacket at+1008000002.0ns
MacLow::ForwardDown non ampdu+1008000002.0ns
MacLow::ForwardDown no aggregation+1008000002.0ns
Arrival of QoS data packet at+1008112018.0ns
CheckQueue called at: +1008112020.0ns
CheckQueue the number of the queued paquets 1
RequestAccess invoked at +1008112020.0ns

MacLow::AggregateToAmpdu  aggregate queue size0

MacLow::StartTransmission the number of aggregated packets 0 at  +1008200018.0ns
we are here  SendDataPacket at+1008200018.0ns
MacLow::ForwardDown non ampdu+1008200018.0ns
MacLow::ForwardDown no aggregation+1008200018.0ns
Arrival of QoS data packet at+1008248034.0ns
Arrival of QoS data packet at+1008248034.0ns
Arrival of QoS data packet at+1008248034.0ns
CheckQueue called at: +1008248036.0ns
CheckQueue the number of the queued paquets 3
RequestAccess invoked at +1008248036.0ns
CheckQueue called at: +1008248036.0ns
CheckQueue the number of the queued paquets 3
RequestAccess invoked at +1008248036.0ns
assert failed. cond="!state->IsAccessRequested ()", file=../src/wifi/model/dcf-manager.cc, line=536

terminate called without an active exception
Command ['/home/kaoutherma/Documents/ns3simulations/ns-allinone-3.26/ns-3.26/build/scratch/simple-wifi-aggregation'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run <program> --command-template="gdb --args %s <args>").

kaouther MANSOUR

Ingénieur chercheur en Réseaux Informatiques et Télécommunication

To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@googlegroups.com.

[Rediet]

Hi,

I don't know if you have modified a lot of things in your code (considering that it crashed I assume that you have added some modifications) but I ran the script (as provided) with ns-dev, while just adding the following output in MacLow::ForwardDown (no other modification whatsoever):

void
MacLow::ForwardDown (Ptr<const Packet> packet, const WifiMacHeader* hdr, WifiTxVector txVector)
{
  NS_LOG_FUNCTION (this << packet << hdr << txVector);
  NS_LOG_DEBUG ("send " << hdr->GetTypeString () <<
                ", to=" << hdr->GetAddr1 () <<
                ", size=" << packet->GetSize () <<
                ", mode=" << txVector.GetMode  () <<
                ", preamble=" << txVector.GetPreambleType () <<
                ", duration=" << hdr->GetDuration () <<
                ", seq=0x" << std::hex << m_currentHdr.GetSequenceControl () << std::dec);
  if (!m_ampdu || hdr->IsAck () || hdr->IsRts () || hdr->IsBlockAck () || hdr->IsMgt ())
    {
      m_phy->SendPacket (packet, txVector);
    }
  else
    {
      Ptr<Packet> newPacket;
      Ptr <WifiMacQueueItem> dequeuedItem;
      WifiMacHeader newHdr;
      WifiMacTrailer fcs;
      uint8_t queueSize = m_aggregateQueue[GetTid (packet, *hdr)]->GetNPackets ();
      std::cout << "A-MPDU size:" << uint16_t (queueSize) << " ";
      bool singleMpdu = false;
      bool last = false;
      MpduType mpdutype = NORMAL_MPDU;

And here is what I get when I run the script.

'build' finished successfully (26.122s)
A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MPDU size:5 A-MP^CInterrupted

Try reverting back to a standard ns-3 codebase and go step by step...

[Luu Quang-Trung]

Hi Angelina, 

Did you solve the problem of introducing a waiting time in edca-txop-n.cc ? I'm trying to do the same thing and I faced the same problem as yours.

Trung

[inam]

Hi Rediet,

I tried to modify in the way you suggested, but I am unable to see any change in the number of aggregated frames. The output remains the same from the beginning to the end of simulation, similar to out shown in your post. I even tried to modify SenDataPacket function as follows (I am using ns-3.26):

if (m_ampdu)

    {

        AmpduTag ampdu;

        m_currentPacket->PeekPacketTag(ampdu);

        std::cout << "SendDataPacket A-MPDU size:" << uint16_t (ampdu.GetRemainingNbOfMpdus ()) << " ";   

    }

  ForwardDown (m_currentPacket, &m_currentHdr, m_currentTxVector, preamble);

but even that is also showing similar output. Few lines of output are copied below:

SendDataPacket A-MPDU size:23 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41 SendDataPacket A-MPDU size:41

Any help is greatly appreciated.

Regards

Inam

[Rediet]

Hello Inam,

Since you only have one AP and one STA that are placed close enough to use MCS7 quite comfortably, you're using a ConstantRateManager, and that your nodes are not moving, you're sure to have the same rate and thus the same number of MPDUs within the A-MPDU. If you want to see this number change over time, use the IdealRateManager and make your station walk around.

Rediet

[inam]

Hi Rediet,

Thank you for your last suggestion. The A-MPDU size did change with change in distance between AP and STA, and use of constant PHY rate. I attach the plot (it is for UDP traffic). But now I am unable to exactly figure out the cause of A-MPDU-size change. Is it because when ACKs do not arrive after a certain period, the aggregator re-aggregates the sent MPDUs (as part of last A-MPDU) which are not acknowledged, and sends them again as a new A-MPDU? But then why the size of new A-MPDU is less than max_AMPDU_size? Is it because of some ACK timeouts? 

I just analysed the output a little, and found that the transmission delay between successive A-MPDUs during the time when A-MPDU sizes are unchanging (before time 12s in the plot) is 8ms or more. But when A-MPDU sizes start dropping (beyond time 12s in the plot), this delay is as low as 2ms. This means that the A-MPDUs are being constructed in a short duration. I am not able to figure out the effect of packet loss on A-MPDU sizes.

Can you suggest something?

Any help is highly appreciated.

Regards

Inam

[Rediet]

Hi Inam,

This is just a guess (you'll have to debug more to check if this is what's happening) but it might be due to the fact that your STA is too far away from the AP and ends up dropping stale packets while continuing to pass some through. You can display the sequence numbers or drops to check if it is what's happening.

Rediet

[saumil shah]

Dear Rediet,

I am interested in putting trace for A-MPDU size. From above post i go to know that queueSize will give me this value. But how can i write trace call back for this?

std::cout << "A-MPDU size:" << uint16_t (queueSize) << " ";


Can you please provide any suggestion?

Best Regards
Saumil

[Rediet]

Hello Saumil,

A quick (and maybe dirty) solution would be to set an object attribute to RegularWifiMac returning pointer to MacLow instance (just like what's done for EdcaTxopN instances per AC) and then defining a trace source in MacLow for your purpose (have a look at how things are done for cw change trace in EdcaTxopN, just take heed that this type of trace source will only notify the trace sink if there has been a change in value, if your aim is to report each call, look into classical trace sources).

Rediet