From Nsnam
Revision as of 09:37, 27 May 2011 by Ashwin (Talk | contribs) (PCAP Refactoring)

Jump to: navigation, search

Click-MAC Extensions for ns-3-click

  • Student: Ashwin Narayan
  • Mentors: Ruben Merz and Lalith Suresh
  • Abstract: This project deals with the MAC extensions for ns-3 click. The current integration of the Click Modular Router with ns-3 is confined to only ns-3’s network device types and doesn’t yet permit the use of Click’s Wifi MAC specific elements. This project aims to enable the same by implementing Radiotap support, and a Monitor Wifi Mac High interface.


A major step in the project would be the implementation of full radiotap headers support. The radiotap header cannot simply be added in YansWifiPhy as this would create issues with the current implementations of MacLow and MacRxMiddle. The current NS-3 Click integration is limited to L3 and leaves ns-3 to handle L2. The radiotap header would probably best be added on the receiver path as close to NetDevice as possible. The implementation would require a redesign in the method of packet forwarding with the radiotap pertinent data. The radiotap header could be created in MacLow and the necessary modifications must be made for sending the header upwards.

Creation of Radiotap Header

The Radiotap Header can be created in MacLow::ReceiveOk(Ptr<Packet> packet, double rxSnr, WifiMode txMode, WifiPreamble preamble).

       RadiotapHeader radiotaphdr;
       uint8_t frameFlags = RadiotapHeader::FRAME_FLAG_NONE;
       bool isShortPreamble = (WIFI_PREAMBLE_SHORT == preamble);
       radiotaphdr.SetTsft (Simulator::Now ().GetMicroSeconds ());
       if (isShortPreamble)
           frameFlags |= RadiotapHeader::FRAME_FLAG_SHORT_PREAMBLE;
       radiotaphdr.SetFrameFlags (frameFlags);
       radiotaphdr.SetRate (rate);
       if (channelFreqMhz < 2500)
           radiotaphdr.SetChannelFrequencyAndFlags (channelFreqMhz,
             RadiotapHeader::CHANNEL_FLAG_SPECTRUM_2GHZ | RadiotapHeader::CHANNEL_FLAG_CCK);
           radiotaphdr.SetChannelFrequencyAndFlags (channelFreqMhz,
             RadiotapHeader::CHANNEL_FLAG_SPECTRUM_5GHZ | RadiotapHeader::CHANNEL_FLAG_OFDM);
       double signalDbm = RatioToDb (m_sendAckEvent->GetRxPowerW ()) + 30;
       double noiseDbm = RatioToDb(m_sendAckEvent->GetRxPowerW() / rxSnr) - GetRxNoiseFigure() + 30 ;
       radiotaphdr.SetAntennaSignalPower (signalDbm);
       radiotaphdr.SetAntennaNoisePower (noiseDbm);

channelFreqMhz can be determined using YansWifiPhy::GetChannelFrequencyMhz() while rate can be obtained from tx.GetDataRate().

In MacLow::Receive(), the rxpacket segment of the code should be modified so that m_rxCallback (packet, &hdr) includes the Radiotap Header. The signature as well as the invocations of the callback must also be modified.

       void MacLow::SetRxCallback (Callback<void,Ptr<Packet>,const WifiMacHeader *,RadiotapHeader> callback)
       {  m_rxCallback = callback;

PCAP Refactoring

        Ptr<Packet> p = packet->Copy ();
        p->AddHeader (radiotaphdr);

The Radiotap Header can be added to the copy of the packet and then we could use:

        WifiPhy::NotifyPromiscSniffRx (p, channelFreqMhz, channelNumber, rate, isShortPreamble, signalDbm, noiseDbm)

Modifications for sending up the stack

While the Radiotap Header is created in MacLow, it must be sent up the stack till MacHigh where it can be added to the packet for Click use.

RegularWifiMac::Receive (Ptr<Packet> packet, const WifiMacHeader *hdr, RadiotapHeader radiotaphdr)


MonitorMacHigh can inherit directly from WifiMac and we could copy only the non-QoS part from RegularMacWifi. Thus, the MonitorMacHigh implementation doesn't need to know the type of station being implemented in the Click graph.

       packet->AddHeader (radiotaphdr);

There would be changes required in IPv4L3ClickRouting would be stripping off headers (the radiotap headers must be stripped as high in the stack as possible) to extract required information and pushing them using SendDown() where we can pass the required click information through netdev->Send(). I might need to strip off a WifiMacHeader at Ipv4L3ClickProtocol::SendDown() to extract Mac address information before sending out the packet through the NetDevice.

       RadiotapHeader radiotaphdr;
       netdev->Send(p, radiotaphdr.GetInfo(), protocol);

Transmission side

As far as TX part is concerned, there’s a need to use a tx-vector that allows per-packet tx parameters so as to allow for the transmission parameters obtained from the radiotap headers to be used for transmission. The implementation can be done as per the suggestions given by Nicola in the discussion of bug 917 wherein I shall attempt to introduce per-packet tx parameters through WifiStationRemoteManager by adding the appropriate menthods for the different parameters and for Data, Rts, Cts, Ack. Finally, extensive testing and validation may be made against stock Click graphs, unit tests may be performed for the radiotap implementation, validation through example scripts for the ClickMac implementation and eventually, integration checks for the whole. As part of future work, following the click-mac integration, there’s the possible implementation of tx-queue feedback.


Considering the time period for the program, the following would be the list of deliverables:

  • Implementation of full-radiotap header support
  • Implementation a ClickWifiMac abstraction acting as a MAC high model for a NetDevice
  • Implementation of tx-vector


  • May 23 - June 6 : RX path - creation of radiotap headers in MacLow
  • June 7 - June 11 : Testing the above
  • June 12 - June 26 : Implementing ClickWifiMac abstracting connecting Click’s interfaces with lower MAC layers
  • June 27 - July 1 : Testing
  • July 1 - July 10 : Refactoring PCAP output: moving wifi PCAP sniff trace sources to MacLow,
  • July 11 - July 15 : Mid-term code review + feedback
  • July 16 - July 21 : Rest of the refactoring of the PCAP output
  • July 22 - July 24 : Testing
  • July 25 - August 7 : Implementation of tx-vector
  • August 8 - August 11 : Integration and testing
  • August 12 - August 14 : Documentation
  • August 15 - August 19 : End-term code review + feedback