Sending custom Wi-Fi Packets in Mac-Low level

[Arthur91]

Dear NS3 community,

I'm new to NS3 and I must implement the following modification to WiFi protocol:

"If a device A receives a Data Packet from device B and device A has a Data Packet adressed to B in its queue, instead of sending an ACK Packet as usual, device A must send a ACKDATA Packet, wich works both like a ACK Packet and Data Packet, to increase the network troughput."

I'm struggling for weeks to implement this. This is what i've done so far:

1. Defined a new WifiMacHeader type, named TYPE_ACKDATA and the routines that manage it
2. I made a modification to dca-txop in order to make the packet queue accessible in the Mac-Low layer
3. In MacLow::ReceiveOk(), when the device receives a Data Packet, it searches trough the packet queue for any packet addressed to the sender, dequeues this packet, changes its type to TYPE_ACKDATA, copy this packet to m_currentPacket and copy its header to m_currentHdr, to finally forward it to MacLow::SendDataPacket().
4. Also in MacLow::ReceiveOk() I added the case where the received packet is an ACKDATA so it will process it both as an ACK and as Data.

This implementation makes sense to me and when I run a simulation with 2 stations sending each other data, Station One correctly sees on its queue that it has a packet to Station 2 and sends it as an ACKDATA. Then Station 2 correctly receives it as an ACK and as Data, and replies with ACK.

But when Station 1 receives this final ACK it crashes when it enters the m_listener->GotAck() routine, with the following backtrace

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7b77c54 in ns3::Buffer::GetSize (this=0x8) at ./ns3/buffer.h:1072
1072      return m_end - m_start;
(gdb) backtrace
#0  0x00007ffff7b77c54 in ns3::Buffer::GetSize (this=0x8)
    at ./ns3/buffer.h:1072
#1  0x00007ffff7b77e40 in ns3::Packet::GetSize (this=0x0) at ./ns3/packet.h:768
#2  0x00007ffff20c7e2b in ns3::WifiRemoteStationManager::NeedFragmentation (
    this=0x716090, address=..., header=0x7176b0, packet=...)
    at ../src/wifi/model/wifi-remote-station-manager.cc:803
#3  0x00007ffff209033f in ns3::DcaTxop::NeedFragmentation (this=0x717630)
    at ../src/wifi/model/dca-txop.cc:354
#4  0x00007ffff20952a6 in ns3::DcaTxop::GotAck (this=0x717630,
    snr=3590,7020839224456, txMode=...) at ../src/wifi/model/dca-txop.cc:585
#5  0x00007ffff2097654 in ns3::DcaTxop::TransmissionListener::GotAck (
    this=0x716dd0, snr=3590,7020839224456, txMode=...)
    at ../src/wifi/model/dca-txop.cc:111
#6  0x00007ffff20611ba in ns3::MacLow::ReceiveOk (this=0x7163f0, packet=...,
    rxSnr=3590,7020839224456, txMode=..., preamble=ns3::WIFI_PREAMBLE_LONG,
    ampduSubframe=false) at ../src/wifi/model/mac-low.cc:986

It looks like it will check if the sent packet needed fragmentation and check for m_currentPacket and m_currentHdr, but those two dont correspond to the last packet sent (the ACKDATA Packet).

Am I transmitting the ACKDATA Packet correctly?

Thank you for your kind patience,

Arthur.

[Sebastien Deronne]

Do you mind providing a patch?
I could help you in a more efficient way.

Note that what you are trying to do is called piggybacking.
Some kind of piggybacking should be added in the current 802.11n implementation and in the upcoming PCF implementation.
So experience on this topic is welcome.

[Arthur91]

Dear Sebastien,

Thank you for having interest to help me!

Sorry for my lack of expertise on NS3, this is my very first project with this platform.
I hope the attached file is the patch you're looking for, I made it by looking at the documentation available on
https://www.nsnam.org/developers/contributing-code/submit/

My implementation is based on the release 3.22 of NS3

Again, thank you for your help, I hope to get a better understanding of what i'm doing wrong.

Best regards,

Arthur

[Sebastien Deronne]

Arthur, 

I will have a look in the coming days (weeks?).

Please note that a patch should have the extension .patch or .diff.

Cheers,

S.

[Arthur91]

Dear Sebastien,

Sorry about the wrong extension on the patch file. Now I think I got it right.

Thank you for your patience,

Arthur