Implementation of an Android-based opportunistic network

[Jan Jessewitsch]

Hello ns3-community,

I'm currently working on a project about the implementation of an Android-based opportunistic network using the ns3.
Since Android devices do not support an adhoc-mode, the idea was to use Android's hotspotting mechanism as the basis for this network.
Every node that is not connected to a hotspot decides by means of different criteria (waiting packets, rss, ...) either if it connects to an open hotspot, or if it opens a hotspot for other nodes. It is at no time possible to establish a route, because only single-hops may exist. (The scenario of two nodes (sender and receiver) being connected to the same hotspot forms an exception, that has to be considered.)
As far as I know, the functionality of a dual-use WifiNetDevice that either serves as a station or as a hotspot is not yet implemented in the ns3.
My solution to the problem is to equip every node with two WifiNetDevices, one configured with Sta- the other one with ApWifiMac. Since it is possible to set the inactive NetDevice into sleep mode, each node only ever has one active NetDevice at simulation's runtime. The concept for the hotspotting mechanism's implementation consists in creating a new virtual netdevice that serves as an interlayer on top of the data link layer similar to the already existing Mesh Device module.
The basic approach for routing will be flooding, but an other routing scheme that is a hybrid of spray and wait, spray and focus and seek and focus will also be implemented.

Please, let me know if you have any suggestions or ideas to improve this project.

[Tommaso Pecorella]

Hi,

yes, just one: you could assume that Android can use Ad-Hoc Wi-Fi, since it's actually just blocked by software.

Still, it seems that its support isn't common. It depends on the chipset and (most probably) stock Android doesn't allows it because some phones would had an explicably missing feature (not that any normal user will ever cry about it).

About the other points, no suggestions.

T.

[Jan Jessewitsch]

Hey Tommaso,

thanks for your quick reply. That's an interesting aspect you pointed out. The assumption that Android can use ad hoc Wi-Fi would simplify the project's structure in many respects.
Unfortunately, it would not meet the requirements: To measure and to validate the performance and the scalability of the hotspotting mechanism (and the above-mentioned routing scheme).

[Jan Jessewitsch]

Recently I run into an issue that originates from a node's sudden switching from station to hotspot.

Node A (station) that has just sent an association request to Node B (hotspot), decides to become
a hotspot for other nodes (e.g. because Node B was busy and the association response is delayed).
Node B replies with an association response that is received by Node A and causes the simulation to crash.

That is because (in ApWifiMac::Receive) the case of an association response is not considered.
The WifiMacHeader is:
- a Management header,
- addressed to this node, but
- wether an association request,
- nor a disassociation.
Hence, RegularWifiMac::Receive is called. In this method arises the
NS_FATAL_ERROR ("Don't know how to handle frame (type=" << hdr->GetType ());
(where hdr->GetType() is WIFI_MAC_MGT_ASSOCIATION_RESPONSE).

To continue my project I chose workaround. I modified ApWifiMac::Receive so that association responses are dropped:

    // below if (hdr->IsDisassociation ()){...}
    else if (hdr->IsAssocResp())
    {
      NotifyRxDrop (packet);
      return;
    }

Although an access point usually not receives association responses, it should remain functional if this happens.
Ergo, is the current ns3 implementation of an access point containing a bug?

[Tommaso Pecorella]

Hi

let's say that it is a missing feature :P

Your workaround seems acceptable, but I'd suggest to open a ticket on Bugzilla for further analysis and a definitive fix.

Cheers,

T.