Wireless in the real world Gabriel Weisz October 8, 2010

advertisement
Wireless in the real world
Gabriel Weisz
October 8, 2010
Architecture and Evaluation of an
Unplanned 802.11b Mesh Network
(Roofnet)
• The idea: Share internet access via an unplanned mesh network,
using omnidirectional roof mounted antennas and multi-hop
routing to ease deployment
• Distributed devices for volunteers to install at home, consisting of a
PC with an 802.11b card and an antenna to install on the roof
– The 802.11b card used supports a non-standard “Pseudo-IBSS” ad-hoc
mode to avoid IBSS partitioning issues
• Nodes attempt to auto configure
– If the user has an internet connection, the node shares
– If the user doesn’t, the node is a DHCP server and provides internet
access
• Nodes generate their own address for use on the Roofnet network,
and perform NAT for their clients
• Users behind nodes cannot communicate with each other
Roofnet Routing
• Tries to find highest throughput route between
any pair of nodes
• Source based routing with link-state and DSRstyle on demand querying
• Estimated transmission time metric
• Bit rate adjusts automatically as packets sent,
based upon actual data transmissions
• 627 kbit/second inter-node performance
• 1395 kbit/second performance from internet
gateways, with average latency of 22 ms
Roofnet Questions and Issues
• Why 802.11b? 802.11G was widely available by then.
• Why PC’s? The Linksys WRT54G was widely available
by then, and the open source firmware had been
available for several years
• Shouldn’t Roofnet network be isolated from user’s
network for users sharing their internet connection?
• It seems like the different wiring configuration for
clients providing internet connectivity could be
confusing. Why not just connect the DSL or cable
modem to the device? Would resolve this and the
previous issue.
• Do modern devices support “Pseudo-IBSS?”
• How does this scale to hundreds of nodes?
White Space Networking with Wi-Fi
like Connectivity (WhiteFi)
• The idea: The FCC decided to allow unused UHF bandwidth
to be used for unlicensed communication. Create devices
for Wi-Fi like data transmission
• Lots of bandwidth exists here. Good spatial propagation
characteristics may make this a good mechanism for citywide deployments
• Issues are primarily due to the fact that white space devices
must not interfere with incumbents (people who’ve paid
for the spectrum). These users include TV stations and
microphones
– Spectrum is fragmented, and availability varies widely in space
and time
• Solution: support variable channel widths, continuously
probe for channel availability, and have a backup channel to
communicate changes in availability
More on the WhiteFi Solution
• Real Hardware:
– A PC with a standard wireless card
– A UHF translator to downconvert the output of the
wireless card to UHF bands and limit the bandwidth
– Universal Software Radio Peripheral (USRP) Software
Defined Radio (SDR) used to sample the UHF spectrum and
detect other signals
• Software:
– Channel selection by evaluating Multichannel Airtime
Metric (Mcham)
– Signal Inspection before Fourier Transform (SIFT) used by
clients to search spectrum in time domain rather than
frequency domain in order to speed up AP discovery.
– Switch to backup channel if a primary user discovered, and
send chirps about available whitespaces
WhiteFi Results
• Sift has a high packet detection rate across
different channel sizes
• Sift can detect AP’s with higher capture ratios
farther away
• AP Discovery time goes down from 7.5 seconds to
2.5 seconds in rural areas, and from 2.5 seconds
to 1.8 seconds in urban areas. Would this
actually matter to end users?
• Spatial variation mechanism makes good use of
available bandwidth
WhiteFi Questions
• How does the system behave with multiple
AP’s?
• Do we need to avoid interfering with
microphones that may be working illegally?
• Do chirps interfere with primary users (who
are legal)?
• Should other MAC protocols (such as CDMA)
be considered?
• How can the security issues be addressed?
Self-Management in Chaotic Wireless
Deployments
• Many wireless deployments are unplanned (due to
individuals or small groups implementing them) and
unmanaged (due to management difficulty)
• A large number of access points were using channel 6 (40odd %). Some were using 2 or 11, and almost nobody was
using anything else
– Other channels not really independent
– Why not 1 instead of 2?
• Performance at endpoints can suffer significantly in dense
environments
• Automated power control and rate adaptation algorithms
can reduce interference and ensure robust end-client
performance
Download