Wifi with multiple APs and mobile STAs: how?
francesco
I am trying to model a wireless network with several access points,
belonging to different networks (e.g. 192.168.i.0/24, with each AP
being 192.168.i.1).
Stations are mobile, i.e. they associate/de-associate with APs while
they move.
However, I see the following problems:
1. if I use a single wifi helper/channel for the whole network,
GlobalRouteManager::PopulateRoutingTables() fails with "network number
confusion". If I use different wifi helpers/channels for each AP (plus
one for the STAs), I can assign the addresses in the way described
above, but stations do not associate with APs, they do not even "see"
them.
I guess I am missing something. Is there an example of a network like
the one I am trying to model? wifi-wired-bridge.cc is not suitable, as
its nodes are not mobile (and therefore it can use the strategy of
having distinct wifi helpers/channels).
Francesco
Tom Henderson
> Hi,
>
> I am trying to model a wireless network with several access points,
> belonging to different networks (e.g. 192.168.i.0/24, with each AP
> being 192.168.i.1).
> Stations are mobile, i.e. they associate/de-associate with APs while
> they move.
>
> However, I see the following problems:
> 1. if I use a single wifi helper/channel for the whole network,
> GlobalRouteManager::PopulateRoutingTables() fails with "network number
> confusion".
matched for wireless because it does not take into account any channel
characteristics. I will look into the problem you report (that "network
number confusion" is raised when multiple prefixes exist on a link) but,
regardless, you probably are not going to want to use global routing if
you want to be modeling that some STAs are out of range of some APs.
If I use different wifi helpers/channels for each AP (plus
> one for the STAs), I can assign the addresses in the way described
> above, but stations do not associate with APs, they do not even "see"
> them.
helpers/channels for each AP and separately for the STAs will result in
STAs not seeing APs. It seems like you would prefer, however, for
everything to be on the same channel.
>
> I guess I am missing something. Is there an example of a network like
> the one I am trying to model? wifi-wired-bridge.cc is not suitable, as
> its nodes are not mobile (and therefore it can use the strategy of
> having distinct wifi helpers/channels).
- Tom
>
> Francesco
> >
>
francesco
> number confusion" is raised when multiple prefixes exist on a link) but,
channel, they are on the same link. They have different prefixes, and
therefore the global route manager complains.
> regardless, you probably are not going to want to use global routing if
> you want to be modeling that some STAs are out of range of some APs.
i.e. after an association happens) set the routes, isn't it?
> If I understand correctly from the above, different wifi
> helpers/channels for each AP and separately for the STAs will result in
> STAs not seeing APs. It seems like you would prefer, however, for
> everything to be on the same channel.
beacon/probe frames) each other, and as far as I could understand
having them on the same Wifi channel is the only way to get this
behavior.
Gustavo Carneiro
I think this is the problem. When the APs share the same wireless
> characteristics. I will look into the problem you report (that "network
> number confusion" is raised when multiple prefixes exist on a link) but,
channel, they are on the same link. They have different prefixes, and
therefore the global route manager complains.
Yes, but if they have different prefixes they should also have different SSIDs (or else the network would not work in the real world). The SSID in wireless networks is almost like a VLAN ID in wired 802 networks. IMHO the GlobalRoutingManager should consider both APs to be on different L2 networks if the advertised SSIDs are different. But how to accomplish this elegantly, without breaking the existing abstractions, I do not know.
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
Tom Henderson
Francesco,
I did some repair on the examples/mixed-wireless.cc script (in the
ns-3-dev branch). It is a mixed wireless (ad hoc, CSMA, and 802.11
infra) topology, with several access points, each of which is on a
different SSID and prefix, connected by an ad hoc backbone. Each AP is
on a different SSID. There is no mobility across APs, however; this
would require roaming across SSID, as Gustavo pointed out, as well as
DHCP (which you inquired about earlier).
One of the tricky things in this topology is getting routing to work
across the different technologies. As I pointed out, GlobalRouting is
not well suited for mobile wireless networks, and OLSR does not have HNA
support to let it be used across multiple links. What I settled on, for
now, is to run GlobalRouteManager::PopulateRoutingTables (), and then
run also OLSR on the wireless ad hoc backbone. But there needs to be a
better dynamic routing solution for these types of topologies; adding
HNA support to OLSR will probably be the quickest path to that.
Are you interested in developing further the roaming across SSIDs and
DHCP servers?
- Tom
Tom Henderson
>
>
> 2008/12/30 francesco <francesco....@gmail.com
> <mailto:francesco....@gmail.com>>
>
>
> > characteristics. I will look into the problem you report (that
> "network
> > number confusion" is raised when multiple prefixes exist on a
> link) but,
>
> I think this is the problem. When the APs share the same wireless
> channel, they are on the same link. They have different prefixes, and
> therefore the global route manager complains.
>
>
> Yes, but if they have different prefixes they should also have different
> SSIDs (or else the network would not work in the real world). The SSID
> in wireless networks is almost like a VLAN ID in wired 802 networks.
> IMHO the GlobalRoutingManager should consider both APs to be on
> different L2 networks if the advertised SSIDs are different. But how to
> accomplish this elegantly, without breaking the existing abstractions, I
> do not know.
I'm hesitant to try to make GlobalRoutingManager try to become a
wireless routing oracle, because I fear that it is not going to be
possible to satisfy users' expectations on it, and people will try to
use it beyond its capabilities (requirements creep). The basic problem
is that it is hard for the GlobalRoutingManager to make the policy
decisions on what constitutes a usable neighbor relationship between
(mobile) node A and node B, because the packet reception probability is
stochastic and time varying.
I think it would be better for us to focus on providing dynamic routing
protocols for wireless and mixed wired/wireless networks, and to limit
GlobalRoutingManager for simulations on wired or static networks where
people do not care about the routing because they are busy studying
other things.
Tom
francesco
> DHCP servers?
far as my current simulation is concerned, I think I will rather go
for an oracle-based approach. When a station associates with an AP,
the oracle will:
* assign the station an address in the same subnet of the AP;
* adjust its routing table (using the node's Ipv4 object) to use the
AP as a gateway;
* make the AP aware of the presence of the node (and adjust ist routes
accordingly).
The results would be the same of DHCP, but no packet exchange would be
foreseen.
Do you think I can accomplish this disregarding the GlobalRouteManager
and relying solely on each node's Ipv4 objects?
Francesco
Tom Henderson
I think what you described above in the bullets should work.
Tom
Tom Henderson
> Hi,
>
> Attached the "magic DHCP" I was talking about.
> Functions are (shortly) documented with comments; you basically do the
> following:
> 1. add APs, stating base (network) address, e.g. "192.168.1." and first
> available IP (eg. 2 if the AP has 192.168.1.1). Note that only /24
> networks are supported;
> 2. add stations.
>
> The manager takes care for both addressing and routing. Additionally,
> you may specify one or more multicast route, in case you use it (by
> default, multicast frames sent from your stations won't be automatically
> forwarded).
>
> Also note that if you use this component you do NOT have to call
> GlobalRouteManager::PopulateTables.
> Ah, stations (more correctly: WifiNetDevices of stations) do need to
> have a (any, possibly a bogus one) address when they are not associated,
> so please make sure not to Add WifiNetDevices without an address, or
> Send from your applications will fail.
>
> Comments or suggestions are welcome (especially if you want to turn this
> stuff into a DHCP implementation ;))
>
> Francesco
>
Francesco,
I attached your files to the following tracker item so they can be
reviewed by the maintainers:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=471
You may want to add yourself to bugzilla cc list for this item to track
any discussion, or monitor the web page for changes.
Thanks,
Tom
Hisham
I have a problem similar to this one. Is there any ns3 implementation for roaming between WIFI APs?
Regards,
