Multiple AP on node/Client channel switching

[Patrick Bosch]

Hello, I have two questions. 

The first one is regarding multiple APs on one node. Usually an AP is able to host several SSIDs. I want to replicate that, but not only have two SSIDs, but communication between the APs hosting them. 

For example: AP 0.1 is a normal SSID with a lot of users. AP 0.2 is the other SSID, let"s say it is hidden, and just used to communicate some internal stuff. What I want now is if AP 0.2 has access to statistics of AP 0.1.

I know that two APs on one node are easy realisable through two NetDevices. But are those two NetDevices somehow able to communicate without the communication leaving the node? Which means, not using the network.

One example would be the number of clients that are connected to AP 0.1. Can AP 0.2 know that somehow? Or is it possible to transmit it? Every idea is welcome.

The second question is regarding the behaviour of a Wifi client. Usually a client checks every channel for networks and is able to switch between channels. I want to replicate this behaviour and use it in my simulation. The answers that I found during my search how to realise that, are all a few years old and leave some questions open. One proposes to use WifiPhy and use the channels saved there, but it somehow does not work for the person proposing this. The other proposition recommends using multiple NetDevices on the clients and somehow switch between them, while only having one activated. 

My first question would be, if this behaviour is implemented by now? And if not, what would the best and most reasonable way to implement it if I want to have as little code as possible in my topology model and most of it directly in the client implementation? Again, every idea is welcome.

Kind regards

Patrick

[Tommaso Pecorella]

Hi,

On Monday, December 8, 2014 10:57:52 AM UTC+1, Patrick Bosch wrote:

Hello, I have two questions. 

The first one is regarding multiple APs on one node. Usually an AP is able to host several SSIDs. I want to replicate that, but not only have two SSIDs, but communication between the APs hosting them. 

For example: AP 0.1 is a normal SSID with a lot of users. AP 0.2 is the other SSID, let"s say it is hidden, and just used to communicate some internal stuff. What I want now is if AP 0.2 has access to statistics of AP 0.1.

I know that two APs on one node are easy realisable through two NetDevices. But are those two NetDevices somehow able to communicate without the communication leaving the node? Which means, not using the network.

One example would be the number of clients that are connected to AP 0.1. Can AP 0.2 know that somehow? Or is it possible to transmit it? Every idea is welcome.

Easy cheesy. You can access the "other" NetDevice easily (just ask the IP layer about the pointer to the other NetDevice. or you can store the NetDevice smart pointer in a manager object. I don't know what's the structure of your node, but it's definitely possible.

 

The second question is regarding the behaviour of a Wifi client. Usually a client checks every channel for networks and is able to switch between channels. I want to replicate this behaviour and use it in my simulation. The answers that I found during my search how to realise that, are all a few years old and leave some questions open. One proposes to use WifiPhy and use the channels saved there, but it somehow does not work for the person proposing this. The other proposition recommends using multiple NetDevices on the clients and somehow switch between them, while only having one activated. 

My first question would be, if this behaviour is implemented by now? And if not, what would the best and most reasonable way to implement it if I want to have as little code as possible in my topology model and most of it directly in the client implementation? Again, every idea is welcome.

I never tried this, but it should be doable. The problem is the channel tho.

In the implementation there are two "channels": the channel number (1...12) and the Channel Object (the instance of the YansWiFiChannel).

A node can switch its channel number, and any node using the same Channel Object but not with the same channel number will not receive anything.

As a consequence, you can "scan" the channels simply changing the channel number periodically.

What I don't know is if there's a ready-made object implementing the logic:

- scan the channels

- grab the beacons

- if the SSID is in the "list of known SSIDs", try to associate

-- if success , stop

-- if fail, continue scanning

It shouldn't be too hard to develop one.

Cheers,

T.

[Patrick Bosch]

Easy cheesy. You can access the "other" NetDevice easily (just ask the IP layer about the pointer to the other NetDevice. or you can store the NetDevice smart pointer in a manager object. I don't know what's the structure of your node, but it's definitely possible.

 

I already tried to do something similar for the smart pointer as with for example the active probing attribute. Then I should have a pointer to the other NetDevice on one NetDevice. Probably a bad solution, but it seemed worth a try. But I'm somehow stuck. I'm not sure what I should do with the NetDevice then and how to access the functions in the AP implementation. I'm probably missing something simple or confusing something. My mind is somewhat blank, sorry. Could you post a very simple example?

What I don't know is if there's a ready-made object implementing the logic:
- scan the channels
- grab the beacons
- if the SSID is in the "list of known SSIDs", try to associate
-- if success , stop
-- if fail, continue scanning
It shouldn't be too hard to develop one.

That sounds promising. So I need to use one Channel Object with several channel numbers. If I'm not mistaken then the available channel numbers should be accessable through the corresponding Phy Object?

I would assume it would be implemented in StaWifiMac. The rest of the logic is also implemented there and it would make sense to have it in this class. It would be one more state that represents the scanning and a bit of logic.

Kind regards

Patrick

[Tommaso Pecorella]

Yo,

On Monday, December 8, 2014 3:59:24 PM UTC+1, Patrick Bosch wrote:

Easy cheesy. You can access the "other" NetDevice easily (just ask the IP layer about the pointer to the other NetDevice. or you can store the NetDevice smart pointer in a manager object. I don't know what's the structure of your node, but it's definitely possible.

 

I already tried to do something similar for the smart pointer as with for example the active probing attribute. Then I should have a pointer to the other NetDevice on one NetDevice. Probably a bad solution, but it seemed worth a try. But I'm somehow stuck. I'm not sure what I should do with the NetDevice then and how to access the functions in the AP implementation. I'm probably missing something simple or confusing something. My mind is somewhat blank, sorry. Could you post a very simple example?

Let's assume you have a "Monitor" object, and you did associate it with the node.

Class Monitor: public Object

{

...

public:

 void SetMainNetDevice (Ptr<NetDevice> mainNetDevice);

 void SetControlNetDevice (Ptr<NetDevice> controlNetDevice);

...

}

You can write an Helper for this class or you can simply create an instance (Create<Monitor> monitor) and aggregate it with the node (node->AggregateObject (monitor)).

To be honest you could as well avoid to aggregate it with the node, but it's better to do it. It's a bit more code to write, but you'll be safer in the object destroy phase.

Once you have this, the "monitor" will have access to both NetDevices.

The problem in having the Ptr of one NetDevice in the other one are:

1) object deallocation may get messy, and

2) it's not simple to do it (who said you have to create one interface before the other?)

About what to do with the NetDevice, I'm sorry but I can't help with this. It's your algorithm, so I can't really help.

What I don't know is if there's a ready-made object implementing the logic:
- scan the channels
- grab the beacons
- if the SSID is in the "list of known SSIDs", try to associate
-- if success , stop
-- if fail, continue scanning
It shouldn't be too hard to develop one.

That sounds promising. So I need to use one Channel Object with several channel numbers. If I'm not mistaken then the available channel numbers should be accessable through the corresponding Phy Object?

I would assume it would be implemented in StaWifiMac. The rest of the logic is also implemented there and it would make sense to have it in this class. It would be one more state that represents the scanning and a bit of logic.

The channel number is in YansWifiPhy (see SetChannelNumber and GetChannelNumber). You can access YansWifiPhy from StaWifiMac through:

DynamicCast<YansWifiPhy> (m_phy)

The DynamicCast is necessary because m_phy is of the base class.

Cheers,

T.

[Patrick Bosch]

Let's assume you have a "Monitor" object, and you did associate it with the node.
Class Monitor: public Object
{
...
public:
 void SetMainNetDevice (Ptr<NetDevice> mainNetDevice);
 void SetControlNetDevice (Ptr<NetDevice> controlNetDevice);
...
}
You can write an Helper for this class or you can simply create an instance (Create<Monitor> monitor) and aggregate it with the node (node->AggregateObject (monitor)).
To be honest you could as well avoid to aggregate it with the node, but it's better to do it. It's a bit more code to write, but you'll be safer in the object destroy phase.
Once you have this, the "monitor" will have access to both NetDevices.
The problem in having the Ptr of one NetDevice in the other one are:
1) object deallocation may get messy, and
2) it's not simple to do it (who said you have to create one interface before the other?)
About what to do with the NetDevice, I'm sorry but I can't help with this. It's your algorithm, so I can't really help.

Thanks, I will try this. Let's see what happens. The issues you mentioned could be a bit problematic.

Regarding what I meant with doing with the NetDevice: Calling a specific function of ApWifiMac, for example SetBeaconIntervall (May not make a lot of sense.), from the other NetDevice with only a pointer to the NetDevice. I hope this does make sense.

The channel number is in YansWifiPhy (see SetChannelNumber and GetChannelNumber). You can access YansWifiPhy from StaWifiMac through:
DynamicCast<YansWifiPhy> (m_phy)
The DynamicCast is necessary because m_phy is of the base class.

Found that one too after searching for implementations. Apparently there was an implementation for channel scanning, but the code does not seem to be available anymore.

Just wondering, may be a stupid question, the channel will only be changed for that specific device, right? 

Kind regards

Patrick

[Tommaso Pecorella]

Hi,

yes, the channel will be changed only for that NetDevice.

Cheers,

T.

[Patrick Bosch]

If anyone is interested, I added the modified files. 

You can activate scanning the same way as activating probing. If it's activated, it will switch from channel to channel, staying 100 ms, standard beacon interval,  in the channel if active probing is not activated and 5 ms if it is activated. The second value can probably be less, but I didn't test it for a loaded AP. If a beacon or a probe response is received the scanning will be canceled. I put the start of the scanning in the BEACON_MISSED state, so that it will scan as soon as this state is reached. The scanning itself starts from the current channel +1. Right now it only uses 11 channels, as used in 2.4 Ghz, but you can change that easily to 13 for 5 Ghz. (Just wondering, is there some check if it is a valid channel? At first I did also check channel 0, which shouldn't exist, and there was no error or anything.)

Let's assume you have a "Monitor" object, and you did associate it with the node.
Class Monitor: public Object
{
...
public:
 void SetMainNetDevice (Ptr<NetDevice> mainNetDevice);
 void SetControlNetDevice (Ptr<NetDevice> controlNetDevice);
...
}
You can write an Helper for this class or you can simply create an instance (Create<Monitor> monitor) and aggregate it with the node (node->AggregateObject (monitor)).
To be honest you could as well avoid to aggregate it with the node, but it's better to do it. It's a bit more code to write, but you'll be safer in the object destroy phase.
Once you have this, the "monitor" will have access to both NetDevices.
The problem in having the Ptr of one NetDevice in the other one are:
1) object deallocation may get messy, and
2) it's not simple to do it (who said you have to create one interface before the other?)
About what to do with the NetDevice, I'm sorry but I can't help with this. It's your algorithm, so I can't really help.

I didn't try that yet, but the concept is clear until a certain point. If I add the monitor to the node, I can access it from either AP and have the pointer to the other NetDevice. This is the point where I"m still confused, when I have the pointer to the other NetDevice, how can I call a function from the other ApWifiMac instance? 

For example, I have a function in ApWifiMac that is used if this AP is set as the control AP, say, GatherStatistics. This function wants to call a function from the other instance to get some data/statistics, let's call it GetStatistics. How can I get the instance when I have a pointer to the NetDevice so that I can call the function? I'm probably just missing something or ran into a corner and don't see it... 

Kind regards

Patrick

[Tommaso Pecorella]

Hi Patrick,

thanks for sharing, I'll check it.

About the 2nd thing... what about this ?

DynamicCast<ApWifiMac> GetMac ()-> GetStatistics ()

Cheers,

T.

[Tommaso Pecorella]

Hi Patrick,

it seems a good start, and I'd advise to move the discussion to ns-dev mailing list. Also, Daniel should be involved (he's the wifi module maintainer).

Some suggestion for the enhancement:

1) the channel scanning is searching for a specific SSID if I understand the code. This may be discussed further (e.g., have a list of allowed SSIDs or accept any).

2) some functionalities are assuming that the MAC object is of type YansWifiMac. Probably we should move some functions to the base class. E.g., why SetChannel isn't in the WifiMac base class ?

Cheers,

T.

[Patrick Bosch]

Hello Tommaso,

it seems a good start, and I'd advise to move the discussion to ns-dev mailing list. Also, Daniel should be involved (he's the wifi module maintainer).

That would be the developer mailing list, not the code review one, I guess?

 Some suggestion for the enhancement:
1) the channel scanning is searching for a specific SSID if I understand the code. This may be discussed further (e.g., have a list of allowed SSIDs or accept any).
2) some functionalities are assuming that the MAC object is of type YansWifiMac. Probably we should move some functions to the base class. E.g., why SetChannel isn't in the WifiMac base class ?

I didn't change the behaviour of the client and I think right now the client is somehow only able to look for one SSID. If you initialise it with the helper, you set the SSID. Usually a scan provides every SSID in range and then the user is offered the choice to connect. Here it's somehow the other way around, you set up a SSID while initialising and then search for this SSID. I didn't want to change too much and just provide a basic functionality. The change in the behaviour and where the functionality should be provided should indeed be discussed.

I don't know how much time I can provide right now, but I will try to free some time for that. But first, I want the other thing to work. I'm somehow stuck there and feel a bit dumb... 

Just to make it clear:

• Create monitor class with getter and setter
• Add functionality to node, so that it additionally stores a monitor object similar to NetDevices. Possibility to set the monitor device.
• Do something similar as in the wifi helper class to add the specific monitor
• Access monitor through node and use the pointer to the NetDevice for stuff

Actually, now that I write it, it seems more clear. The fact that it's in the morning and I didn't have a look at the code yet could also be a reason. ;)

Another questions popped up too. Does ns3 somehow provide the possibility for the AP to guess where a client is? I know that this is not easy at all. You need a model to estimate the distance from the AP through the signal strength and then several AP that received, for example, a probe request from the client. Through that you can triangulate and have roughly the position. Actually, for me it would be enough to just have roughly the distance and the direction. Is there something for that?

Another option would be to get the exact position through the mobility model and add some inaccuracy. But that would include some kind of hack again.

Kind regards

Patrick

[Patrick Bosch]

I realised that the time needed for channel switching rises with the number of clients. With up to 9 clients 5 ms is enough with active probing. But after that it rises continuously. I needed over 50 ms for 250 clients (worked with 75 ms). How exactly is it realised that it increases with the amount of clients? Is there some way to increase the speed of switching? If it increases the time of the simulation that wouldn't be a problem at all, as long as the time of the switching is in a certain range. 

And for the record, if anyone is interested in the stuff relating the monitor, the following is the way to go if you want to access one AP instance, if you have the mentioned monitor:

Ptr<Monitor> monitor = DynamicCast<YansWifiPhy> (m_phy)->GetDevice ()->GetObject<NetDevice> ()->GetNode ()->GetMonitor ();
Ptr<ApWifiMac> otherAP = DynamicCast<ApWifiMac> (DynamicCast<WifiNetDevice> (monitor->GetMainNetDevice ())->GetMac ());

If your interested in anything in detail, just ask.

Kind regards

Patrick

[Tommaso Pecorella]

Hi Patrick,

I'll see if I can take a look at the problem.

About your question in the other post... I meant the ns-developers mailing list, the link is here:

http://www.nsnam.org/support/mailing-list/

Cheers,

T.

[Patrick Bosch]

Hi Tommaso

I'll see if I can take a look at the problem.

Thanks!

This is really strange and I was genuinely surprised. The problem arises because the client is still in a switching state, so one needs to wait longer to make the next switch.

About your question in the other post... I meant the ns-developers mailing list, the link is here:
http://www.nsnam.org/support/mailing-list/

Then I will post it there soon. I will also mention the issue with the time.

Kind regards

Patrick 

[Tommaso Pecorella]

Hi Patrick,

mind sending me a sample script ? I think I got where the issue is.

Cheers,

T.

[Patrick Bosch]

Hi Tommaso

I think I got it too. A colleague mentioned interference and I think that's it.

I added a sample with which it should work. The channels are far apart and should not interfere with each other. Changing the channels should reproduce the problem perfectly.

I'm testing it with 10 ms and 100 clients right now and it seems to work. At least the simulation hasn't crashed yet.

Do you have the same solution or a different idea?

Off topic: I did try to send it to the mailing list, but it got rejected automatically. I know that as a first timer my mail will be checked, so is the automatic rejection normal?

Kind regards

Patrick

[Tommaso Pecorella]

Hi Patrick,

I did a quick check. There are some things I would have done differently, but nothing we can't iron out in a code review.

About the strange effect you mentioned, yes, it's collisions. I noticed that the probing done by the non-associated nodes is... massive, and it may be worth checking if it's done too fast. Perhaps it's a bug.

As a side note, the pcap file seems to include ANY packet seen by the NetDevice, regardless of the channel number. Also this may be classified as a bug. I'll have to check it a bit better.

Cheers,

T.

[Patrick Bosch]

Hi Tommaso

I did a quick check. There are some things I would have done differently, but nothing we can't iron out in a code review.

Sure, I think there are quite a lot of things that can be done better.

About the strange effect you mentioned, yes, it's collisions. I noticed that the probing done by the non-associated nodes is... massive, and it may be worth checking if it's done too fast. Perhaps it's a bug.

The switching should be done around every 5 ms, which means a probe request every 5 ms. Maybe that is too fast, but I thought the switching and probing in a real client is done way faster then just waiting for beacons. The time for that is usually 100 ms. 

In the beginning every client starts in the same channel. That could be a bit of a problem regarding the collisions. Maybe letting them start in different channels and maybe have something similar to the beacon jitter would reduce the collisions. 

As a side note, the pcap file seems to include ANY packet seen by the NetDevice, regardless of the channel number. Also this may be classified as a bug. I'll have to check it a bit better.

I didn't have a look at the pcap file, but isn't the NetDevice associated with the channel object and sees every packet because of that? Still, it should only see the messages with the same channel number. Otherwise it is also a bit confusing if someone wants to use the pcap files and sees every packet.

I will try to change something in the next days, but need to finish something else first and then this christmas is also there. ;)

By the way, did you read my comment regarding the mailing list? I somehow can't post there...

Kind regards

Patrick

[Tommaso Pecorella]

Hi Partick,

merry Xmas to you.

The ns-dev mailing list requires a registration, but I can't remember how I did it... it was some time ago :P

Cheers,

T.

[Konstantinos]

Hi Patrick,

wrt the mailing list, I would refer you to the ns-3 website http://www.nsnam.org/support/mailing-list/

There are 'join' instructions you should follow. It may take some time until you are granted access to the list (i.e. until the admin approves it)

[Banerjee Subhra]

Hi All,

I have similar requirement. Following is the description,

• I have multiple APs and Multiple clients. APs are static while the Clients are mobile. Based upon position of any client it connects to the nearest AP and perform the transmission activity. Over the time when client changes its position, it may connect to different AP based upon nearest AP logic.
  
• To connect to a particular AP I used SetChannelNumber API and changed the channel of client to the channel number of the AP that it wants to  connect with.
  
• For the first time (initialization) it is working fine. Clients are able to communicate with the desired APs.
  
• But over the time when client position changes, it should try to connect with different AP. For that again I am trying change the channel number of the client using SetChannelNumber API. This time the simulation fails because of some segmentation fault. [0x00007ffff70b461a in ns3::Buffer::GetSize (this=0x8) at ./ns3/buffer.h:87]
  

I am uploading my script file and log file for your reference. Anyone have any idea how to resolve this problem?

Any help would be highly appreciated. 

Regards,

Subhra

[Banerjee Subhra]

Hi All,

Please respond.. I am stucked in this problem.

Your input will be a great help to me.

Regards,

Subhra

[Tommaso Pecorella]

Hi,

I'm sorry but I can't even compile your script due to the use of non-standard code (e.g., DhcpClient).

The bug could be more or less anywhere, from your script to the DhcpClient (and server?) to the "normal" ns-3 sources.

My suggestion is to read one of the many debugging how-to (you can find on Internet) and do a little debug to your code.

Cheers,

T.

[Patrick Bosch]

I can not help you directly, I can only tell you what I did.

I implemented the behaviour of a normal WiFi client, which means, if it loses the connection, it searches through all the channels and connects to an AP if it finds one. That behaviour is also present at the beginning of the simulation. I'm not sure if that is the behaviour you want though. It seems you want to have a fixed setup, where it connects to a specific AP when it loses its connection. I did not try to do the channel switching like that, because I wanted a realistic setup.

Kind regards

Patrick