Wireless Communications Research Overview
Download
Report
Transcript Wireless Communications Research Overview
Wireless Communication and Networks
Applications of Wireless
Communication
Wireless Communication
Technologies
Wireless Networking and
Mobile IP
Wireless Local Area
Networks
Student Presentations and
Research Papers
Wireless Medium Access
http://web.uettaxila.edu.pk/CMS/AUT2012/teWCNms/
Outline
Network and Application Layer Enhancements
Microsoft Case Studies
MultiNet/Virtual WiFi
WiFi Profiler
MultiNet: Connecting to Multiple IEEE
802.11 Networks Using a Single Wireless
Card
There are a number of scenarios where it is desirable to have a
wireless device connect to multiple networks simultaneously.
Currently, this is possible only by using multiple wireless network
cards in the device.
Unfortunately, using multiple wireless cards causes excessive
energy drain and consequent reduction of lifetime in battery
operated devices.
Microsoft Research’s MultiNet facilitates simultaneous connections
to multiple networks by virtualizing a single wireless card.
The wireless card is virtualized by introducing an intermediate layer
below IP, which continuously switches the card across multiple
networks.
The goal of the switching algorithm is to be transparent to the user
who sees his machine as being connected to multiple networks.
VirtualWiFi is transparent for the upper layer protocols, and works
well over popular IEEE 802.11 wireless LAN cards.
Motivation behind MultiNet
The MultiNet virtualization architecture enables several new
applications that were earlier not possible using a single wireless
card e.g.:
Concurrent Connectivity:
A user can connect her machine to an ad hoc network, while
staying on her authorized infrastructure network.
For example, consider the case where Kisco’s employees
conduct a business meeting with Macrosoft’s employees at
Macrosoft’s headquarters.
With MultiNet and a single wireless network card, Kisco
employees can share documents, presentations, and data with
Macrosoft’s employees over an ad hoc network.
Macrosoft’s employees can stay connected to their internal
network via the access point infrastructure while sharing
electronic information with Kisco’s employees.
Macrosoft does not have to give Kisco employees access in their
internal network in order for the two parties to communicate.
Motivation behind MultiNet
Network Elasticity:
The range of an infrastructure network can be
extended by allowing border nodes to act as relays for
authorized nodes that are outside the range of the
Access Point (AP).
For example, a node X, associated to a home AP,
is being used to browse the web.
Another node Y is moving while connected to the
same AP and looses its connection because it goes
out of range.
With MultiNet, if X is within range of Y, it can
connect to Y over an ad hoc network, and forward
Y’s traffic on to the AP.
Motivation behind MultiNet
Gateway Node:
A
node that is part of a wireless ad hoc
network and close to an AP, connected to the
Internet, can become a gateway node for the
ad hoc network.
This node becomes a bridge for other nodes
on the ad hoc network, passing their packets
to and from the Internet.
Motivation behind MultiNet
Network Security:
Different groups (e.g. human resources personnel,
secretaries, developers etc.) within a company may
be given different permissions to access data servers.
These servers could be on physically different
networks.
For a privileged user, who has permission to access
different networks, having MultiNet is valuable.
S/he would not have to disconnect and reconnect
between networks every time s/he wishes to access
resources on different networks.
Motivation behind MultiNet
Increased Capacity:
The
capacity of ad hoc networks can be
increased when nodes within interference
range can communicate by switching on
orthogonal channels.
Virtual Machines:
Users
can connect different virtual machines,
to physically different wireless networks.
MultiNet Architecture
MultiNet Architecture
MultiNet Implementation
Virtual WiFi related
Publications
"A Virtualization Architecture for Wireless Network Cards"
Ranveer Chandra
PhD Thesis, Cornell University, September 2005.
"MultiNet: Connecting to Multiple IEEE 802.11 Networks Using a Single Wireless Card"
Ranveer Chandra, Paramvir Bahl and Pradeep Bahl
Proceedings of IEEE Infocom 2004, Hong Kong, March 7-11, 2004.
Infocom Presentation
MultiNet: Enabling Simultaneous Connections to Multiple Wireless Networks Using a Single
Radio
Ranveer Chandra, Paramvir Bahl and Pradeep Bahl
Demo and Poster in ACM/USENIX MobiSys, San Francisco, May 5-8, 2003
Poster in Mesh Networking Summit, Snoqualmie, WA, June 23-24, 2004
MultiNet: Enabling Simultaneous Connections to Multiple Wireless Networks Using a Single
Radio
Paramvir Bahl, Pradeep Bahl and Ranveer Chandra
Microsoft Tech Report, MSR-TR-2003-46, June 2003
Virtual WiFi Applications related
Publications
"Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks"
Atul Adya, Paramvir Bahl, Ranveer Chandra and Lili Qiu
Proceedings of ACM Mobicom, Philadelphia, September 26-30, 2004.
"SSCH: Improving the Capacity of IEEE 802.11 Multihop Networks Using Slotted Seeded Channel
Hopping"
Paramvir Bahl, Ranveer Chandra and John Dunagan
Poster in Mesh Networking Summit, Snoqualmie, WA, June 23-24, 2004
"SSCH: Slotted Seeded Channel Hopping for Capacity Improvement in IEEE 802.11 Ad-Hoc Wireless
Networks"
Paramvir Bahl, Ranveer Chandra and John Dunagan
Proceedings of ACM Mobicom, Philadelphia, September 26-30, 2004.
Mobicom Presentation
"WiFiProfiler: Cooperative Fault Diagnosis in Wireless LANs"
Ranveer Chandra, Venkata N. Padmanabhan and Ming Zhang
Proceedings of ACM/USENIX MobiSys, Uppsala, Sweden, June 19-22, 2006.
MobiSys Presentation
"Opportunistic Use of Client Repeaters to Improve Performance of WLANs"
Paramvir Bahl, Ranveer Chandra, Patrick P. C. Lee, Vishal Misra, Jitendra Padhye, Dan Rubenstein
and Yan Yu
Proceedings of ACM CoNEXT, Madrid, Spain, December 9-12, 2008.
Virtual WiFi Download URL
http://research.microsoft.com/enus/downloads/994abd5f-53d1-4dba-a9d8-8ba1dcccead7/
> 12 MB in size
Microsoft Research
Netsh
WCN
ISV App
IHV App
OEM App
Provided by:
Microsoft
Hosted Network APIs
WLAN Service
Networking Stack
Networking Stack
NWiFi Filter Driver
VWiFi Filter Driver
Primary Adapter
NDIS Port 1
IHV Miniport Driver
(ExtSTA, NetMon, ExtAP)
WiFi Hardware
VWiFi Miniport Driver
Private
Interface
IHV
OEM
Legend:
Control
Secondary Adapter
VWiFi Filter Driver
NDIS Port 0
User Mode
Kernel Mode
ISV
VWiFi Bus Driver
Data
Control
& Data
How to start and stop SoftAP
// open handle
dwError = WlanOpenHandle( WLAN_API_VERSION_2_0 , NULL, &dwNegotiatedVersion,
&hClientHandle);
// check return value
// configure softap
dwError = WlanHostedNetworkInitSettings( hClientHandle, &FailReason, NULL );
// check return value
// start softap
dwError = WlanHostedNetworkStartUsing( hClientHandle, &FailReason, NULL ) ;
// check return value
// use softap
// stop softap
dwError = WlanHostedNetworkStopUsing( hClientHandle, &FailReason, NULL ) ;
// check return value
// close handle
dwError = WlanCloseHandle(hClientHandle, NULL);
© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
WiFiProfiler: Cooperative Diagnosis in
Wireless LANs
Microsoft Research
Wireless Woes
Users often wonder why:
“My machine says: wireless connection unavailable”
“I get poor performance on wireless”
“My wireless card keeps trying to authenticate”
“Is it just me?”
Wireless Woes
Users often wonder why:
“My machine says: wireless connection unavailable”
“I get poor performance on wireless”
“My wireless card keeps trying to authenticate”
“Is it just me?”
Many places have no/minimal network admin
Hotspots: cafes, airports
Transient networks: conferences, IETF meetings
Prior Work: Operator View
Infrastructure-based monitoring (Aruba, DAIR)
Focuses on operator perspective (e.g., rogue APs)
Monitoring at clients (e.g., [Adya 2004])
Fault diagnosis using infrastructure support
Also focuses on operator perspective
Correlate client observations at AP (MOJO)
Detect PHY level anomalies
WiFiProfiler Goal: User View
Enable clients to diagnose network failures without requiring
admin/infrastructure support:
Reduce user frustration
Reduce load on admin, when there is one
Help users help themselves
State of the Art: Local Diagnosis
Wireless Connection Manager, WZC
• Reasonable detection, Poor diagnosis
Bad NIC
MAC
Filtering
Bad AP
Bad WEP
Key
Cannot Associate
WiFiProfiler
Based on two key observations:
Clients form Information Plane with peers
Even when client cannot connect to AP
Extent of problem indicates cause
Diagnose faults by correlating peers’ health
WiFiProfiler Overview
Healthy Client
Dissatisfied Machine
Access Point
Create Information
Plane
Healthy Client
(Cannot connect to
WEP-enabled AP)
Diagnose Problem:
Same WEP key?
Diagnose range of problems across layers!
Faults and Some Causes
No AP Detected
Location
H/w or s/w
No Association
Security
DHCP Server
No IP Address
Firewall/proxy
End-to-End Failure
WAN Disconnect
WAN congestion
Poor Performance
Wireless problem
WiFiProfiler Design Goals
Transparency:
Minimal user impact/involvement
Deployability:
Work with off-the-shelf cards and unmodified drivers
Scalability:
Work with a large number of clients
Security:
Prevent compromise of clients and AP
WiFiProfiler Architecture
Sensing: What is monitored?
Communication: How is it shared?
Diagnosis: How are faults diagnosed?
Sensing
Monitor health of client’s connectivity
Static info (e.g., NIC type)
Dynamic info (e.g., assoc. success/failure)
Fault
No Association
Some Causes
H/w or s/w
Security
Sensed Info
NIC Model, Make,
Driver version
Auth/Encryption
setting, key info
Sensed Information
User-level service (daemon) polls various layers
Wireless: NIC, BSSID, RSSI, Beacon Loss, 1-way hash of
key, Interface Queue
IP: IP Address, DHCP, DNS
Transport: Failed connections, Server Ports
Application: Web proxy settings
Snapshot obtained once every second
Summarized information < 1200 bytes
Communication
H
Req. Health
Sensed Info
Establishing the Information Plane
802.11 NICs can connect to only one network at a time
Challenges:
Discovery: How does H know that D needs help?
Parallelism: How does H send packets to D?
D
Discovery
D initiates ad hoc network with distinct SSID
Special SSID format denotes request for help
H receives beacon even when associated to AP
SSID:
Help:169.254.10.125:5000
D
169.254.10.125
Port: 5000
H
Parallelism using VirtualWiFi
Approach: Virtualize card, buffer packets, switch b/w networks
Application Layer
User-level
Kernel-level
TCP/IP, Network Stack
Virtual Interface 1
Virtual Interface 2
VirtualWiFi Layer
Wireless Card
Virtual Interface 3
Communication Protocol
WiFiProfiler uses 2 (virtual) adapters:
Primary adapter activated in normal use
Helper adapter dedicated for WiFiProfiler
Activated only when needed
SSID:
Help:169.254.10.125:5000
D
Primary VNIC
169.254.10.125
Port: 5000
Helper VNIC
H
Diagnosis
Initiated by user
Correlate peers’ info and infer likely cause
Rule-based techniques instead of black-box
Suggest steps for problem resolution
Change configuration settings
e.g. local DNS server, web proxy, WEP key
Change location, contact admin
Diagnose faults across layers of network stack
Diagnosing Association Failure
If another peer has successfully associated with the AP:
Is Sec.
config
Same?
NO
Bad Sec. setting
(Fix it)
YES
Low
Signal
Level?
YES
Bad signal
(change location)
NO
Similar card
Associated?
NO
YES
MAC Filtering
(contact admin)
S/w or H/w config
(change NIC or
update driver)
Diagnosis Features
Inherent uncertainty in some cases
Need info from AP to confirm MAC filtering
Conflicting info from peers
Used to eliminate branches in diagnosis procedure, e.g.
NIC type
Vulnerability to bogus info from attackers
Use information from large number of peers
Susceptible to Sybil attack
Evaluation
Sensing: Low overhead
(used < 1% CPU on 1.33 GHz laptop)
Communication using VirtualWiFi:
Healthy clients spend < 2 sec sending info
Sick clients get information within 30 seconds
Much of the delay in discovery (scanning delays)
Little Impact on Healthy Clients
25
Time (in seconds)
Download while Helping
20
Download when not Helping
15
Extra 0.5 to 3 seconds!
10
5
0
10K
100K
1M
Download Size (in bytes)
Effectiveness of WiFiProfiler
Too far from AP
MAC Filtering
Port blocked
Access Point
Port blocked
Port blocked
Relevant diagnosis at all clients within 30 seconds!
WiFiProfiler Summary
Enables cooperative diagnosis in WLANs
Without infrastructure support, low overhead
Working system on Windows XP
Future work:
Security: Privacy, Sybil Attacks, Passive Mode
Long-term Profiling
Q&A
?