Dheryta Jaisinghani defended her Ph.D. thesis on understanding the role of active scans in large-scale WiFi networks. She investigated three main problems: unnecessary active scans, WiFi indoor localization with minimal active scans, and using active scans for data transfer. Her research methodology involved analyzing real-world WiFi traffic datasets, designing solutions to address the problems, and implementing and evaluating the solutions. Some key contributions included techniques to detect growth in probe traffic, infer the causes of active scanning, and reduce unnecessary probe requests from client devices.

1. Understanding the Role of Active Scans for their
Better Utilization in Large-scale WiFi Networks
Ph.D. Thesis Defense of
Dheryta Jaisinghani
On Monday April 22, 2019
Advised By: Vinayak Naik and Sanjit K. Kaul

2. Agenda
2
1
Background
● WiFi Networks
● Connecting
with an Access
Point
● Scanning
Scope
● Problems
Investigated
● Methodology
Followed
● Challenges
2
Problems
● Unnecessary
Active Scans
● WiFi Indoor
Localization
● Data Transfer
with Active
Scans
3
Conclusion
● Summary
● Contributions
to Existing
and New
Standards
● Future Work
4

3. WiFi Network Architecture
...
Controller
AP1
WiFi Clients
AP2
APN
WiFi
Association
Ethernet
3
AP- Access Point
BSSID1
BSSID2
BSSIDN
...

4. How does a Client Connect with an Access Point?
4
Step 3
Data
Transmission
and Reception
Step 1
Discover an
Access Point
Step 2
Associate and
Authentication
Handshake
with the
Access PointAn essential initial step that
enables steps 2 and 3 and
much more!

5. Discovering an Access Point
5
Listen
Beacons
...
...
Beacons
AP
Client
Probe
Requests
...
...
Probe
Responses
AP
Client
Passive Scanning Active Scanning
Slow and Not
Preferred
Default Discovery
Protocol

6. Why Focus on Discovery?
Modern WiFi networks provide more than just basic network access functionality
6
IoTs Localization
Environment
Sensing
Access Point discovery mechanisms continue to be traditional
*Images from Internet (Open Access)
*
*

7. Agenda
7
1
Background
● WiFi Networks
● Connecting
with an Access
Point
● Scanning
Scope
● Problems
Investigated
● Methodology
Followed
● Challenges
2
Problems
● Unnecessary
Active Scans
● WiFi Indoor
Localization
● Data Transfer
with Active
Scans
3
Conclusion
● Summary
● Contributions
to Existing
and New
Standards
● Future Work
4

8. Problem Statement
● Investigate the mechanisms of discovery in large-scale and
dense WiFi networks
● Default protocol - Active Scanning is crucial
○ Excessive amounts ⇒ Performance⬇
○ Arbitrary reduction ⇒ Performance⬇
● A thorough relook needed
8

9. Problems Investigated
9
Harnessing Active Scans for
Data Transfer in WiFi-based
IoT Nodes
03 ● Best Use of Active Scans
WiFi Indoor Localization using
Existing Infrastructure in the
presence of Minimal Active
Scans
02 ● Minimal Active Scans
Understanding and Mitigating
the Impact of Unnecessary
Active Scans in WiFi Networks
01 ● Excessive Active Scans

10. Empirical Methodology Followed
Sniff WiFi Traffic
Analyze and Infer
Design a Solution
Implement the Solution
10
Management
Probe, Beacons,
Associate, Authenticate
Data Qos/Non-QoS Data
Control RTS, CTS, ACK, Polling
IEEE 802.11 Frames

11. Challenges
● Work with actual network deployments
○ Dynamic environments
● Real-time analysis and validation
○ Precision
● Multitude of devices [>15,000 vendors]
○ One solution does not fits all
● Large-scale infrastructures
○ Integrable solutions
11

12. Agenda
12
1
Background
● WiFi Networks
● Connecting
with an Access
Point
● Scanning
Scope
● Problems
Investigated
● Methodology
Followed
● Challenges
2
Problems
● Unnecessary
Active Scans
● WiFi Indoor
Localization
● Data Transfer
with Active
Scans
3
Conclusion
● Summary
● Contributions
to Existing
and New
Standards
● Future Work
4

13. Problem#1*
Understanding and Mitigating the Impact of
Unnecessary Active Scans in WiFi Networks
13
1. D. Jaisinghani, V. Naik, S. K. Kaul, R. Balan, and S. Roy, “Improving the Performance of WLANs by Reducing
Unnecessary Active Scans,” ArXiv e-prints, Jul. 2018. [Under Review]
2. D. Jaisinghani, V. Naik, S. K. Kaul, and S. Roy, “Realtime detection of degradation in WiFi network's goodput
due to probe traffic,” in WinMee -WiOpt, 2015, May 2015.
3. D. Jaisinghani, V. Naik, S. Kaul and S. Roy, “Sniffer-based Inference of the Causes of Active Scanning in
WiFi Networks,” in NCC,Chennai, India, Mar. 2017.
4. (H. Fulara, G. Singh)*, D. Jaisinghani and M. Maity and T. Chakraborty and V. Naik, “Use of Machine
Learning to Detect WiFi Networks from Unnecessary Active Scans,” WoWMoM, 2019. [*Equal Contributions]
# Best Graduate Forum Presenter Award at COMSNETS 2018

14. Research Question
What is the extent and the impact of active
scans and how to deal with them?
14

15. The Extent of Active Scans
● Analyzed 3 real-world datasets
○ Sigcomm [5 GHz, 2 Days, 14 Hours]
○ IIT-B [2.4 GHz, 1 Day, 2.5 Hours]
○ IIIT-D [2.4 GHz, 9 Days, 63 Hours]
● Clients probe lesser in 5 GHz [Sigcomm]
● Client Density ↑, Probe Requests ↑ [IIT-B]
● Frame size depends on clients and BSSIDs [50 - 300 Bytes]
● Probe Requests and Responses can arrive as early as every 0.01 ms
● Probe Response arrival time depends on #BSSIDs
● 2.4 GHz has lowest bitrate=1 Mbps, 5 GHz has lowest bitrate=6 Mbps
● 99% Probe Responses fetch redundant network information for stationary WiFi
clients
15

16. Active Scanning - 2.4 GHz vs 5 GHz
16
● WiFi networks today operate on both 2.4 GHz and 5 GHz - Different channel
characteristics
● Previous datasets could not be used because,
○ SIGCOMM is old (2008) with minimal evidence
○ IIIT-Delhi < 5 clients/day in 5 GHz
○ IIT-B - 2.4 GHz
● ∴ Venue with dual-band devices needed
○ A university in Singapore
○ Dual-Band Aruba WiFi Network
○ Comparable number of clients in both bands
○ 6 hours of traffic collected

17. Effect of RSSI drop on #Status ChangesEffect of RSSI drop on #Probe Requests
Comparison Results - 2.4 GHz vs 5 GHz
17
5 GHz sees active scans
when RSSI drops
2.4 GHz sees
active scans
at all RSSI
Stationary clients scan minimally in 5 GHz
5 GHz sees status
change when RSSI drops
2.4 GHz sees
status changes
at all RSSI

18. Importance of 2.4 GHz
● 2.4 GHz is common in developing countries like India
● Dual band WiFi devices are costly
● 85% WiFi devices still operate in 2.4 GHz
● 2.4 GHz will be the likely choice for large-scale IoT deployments
18
We focus on 2.4 GHz band

19. Impact from Client-side Perspective - Latency
19Mean latency ↑ from 3.57 ms to 21.72 ms [6x ↑]
● Stationary WiFi client
● Associated
● AP-RSSI - Good
● Logs
○ Time of Scan
○ Latency
● Duration: 5.5 hours

20. Impact from Client-side Perspective - Association
Patterns
20
38%
Discovered 11,
Chose 3 to
associate
● Stationary WiFi clients (34)
● Associated
● AP-RSSI - Good
● Logs
○ Discovered APs
○ Associated APs
● Duration: 10 days
Clients discover more, associate to few

21. Impact from Network-wide Perspective - Controlled
Setup
21
Growth in Probe Traffic
results in drop in Bandwidth
[ 20 Mbps -> 10 Mbps]

22. Impact from Network-wide Perspective - Uncontrolled
Setup
22

23. Impact from Network-wide Perspective - Uncontrolled
Setup - Results
23
ACK losses - 2.6x ⬆
Frame retries - 2.19x
⬆
Goodput - 50% ⬇
Probe traffic - ~80%
⬆
Channel Utilization >= 70%

24. Addressing the Problem
● Problem
○ Stationary clients do not benefit from active scans
○ Goodput drops in heavily utilized WiFi networks
● Challenges
○ Active Scanning is Crucial Process - Cannot Disable
○ Passive Scanning is slow - Not Preferred
○ Fast Solution - Strict timing constraints of WiFi protocol
○ ⬆Probe Traffic ⇔ ⬇Data Traffic - Detecting exact cause is
hard
24

25. Current Solutions and their Limitations
● Problem Recognition [IMC ‘15, TMC ‘10, 802.11ax]
● Reduce scanning delays
○ Modified scanning algorithms in [ICC ‘12, PERCOM ‘10]
○ Multiple radios/MPTCP [NSDI ‘15, TVT ‘14]
○ Channel frequency response [MOBICOM ‘13]
● Partially reduce probe traffic
○ Passive scanning or disable probe response on APs [WN ‘10,
WoWMoM ‘09]
● Systems for improving the performance of WiFi networks
○ PIE, JIGSAW [NSDI ‘11, SIGCOMM ‘06]
25Device Changes, Partial Reduction, Reduce Interference

26. Our Solutions
26
● Detect the growth of probe traffic - Validates the cause
● Infer the cause of growth in probe traffic - Better Network
Planning
● Reduce probe requests from client-side - Inhibits Probe
Responses

27. Detect Growth of Probe Traffic
27
Real-time growth in probe traffic
● Assumption - There is always data to be sent
● Cumulative increase of P/D > 1 is plotted against
time
● Slope >= 0.10 => Goodput drop [90% accurate]
Case Metric D Frames P Frames
Probe Traffic
⬆
1 P/D < 1 ✔ ✖ ✖
2 P/D = 1 ✔ ✔ ✖
3 P/D > 1 ✖ ✔ ✔
Probe Frames
Fresh Data Frames

28. How do Clients Decide When to Scan?
28
Discovery
Connection
Establishment
Connection
Maintenance1. Periodic Scan
2. Associated State:
Unassociated to Associated
3. Power State: Low to High
4. Loss of Beacons
5. AP-side Procedures
6. Low RSSI
7. Data Frame Losses
Causes of Active Scans
Applications
(wpa_supplicant, network
manager)
MAC Drivers
(cfg80211, mac80211)
Device Drivers
(ath9k, iwlwifi)
WiFi Chipset
(AR9462, BCM4322)
User space
Kernel space
Hardware
At client-side, it's a non-trivial process
It can be
triggered at
any of these
layers!

29. Inferring the Causes of Active Scanning
29
● Frames received in real-time
● Every cause has a distinguished signature
● Defined static rules and metrics for each cause
● DFA-based detection with states and events
Sniffer-based Inference Mechanism

30. An Example
30
AP-side Procedures
● Connection Maintenance → AP-side Procedures
● Load balancing/Rogue client
● AP deauthenticates client
● Client Scans

31. Extent of Causes in Real Datasets
31
Periodic
Scans -> Most
Common
Network
Planning
Intermittent
user activity
Network
Contention

32. Applying Inference Mechanism to Real-world Networks
● Unassociated Periodic Scans ⇒ Unassociated clients ⇒ Rogue clients
● Associated Periodic Scans ⇒ Aggressive clients
● Connection Maintenance ⇒ ↓ Coverage or ↑ Interference
● AP-side Procedures ⇒ Faulty Controller Algorithm
32
Network administrators can improve network planning

33. Reduce Probe Requests From the Client-end
33
● Revisit the causes of Active
Scans
● Stationary WiFi clients ⇒
Active Scans ❌
● Mobile WiFi clients ⇒ Passive
Scans ❌
● Time Constraints - Connection
Establishment/Maintenance
● Dynamic Decision
Associated?
Handover
No
Stationary?
Connection
Maintenance
Passive
Scans
Yes
YesNo
Active
Scans
Connection
Establishment?
Yes
No

34. Client-end Solution: Experiment Setup
34
● Live IIIT-D network
● Modified and Unmodified clients - 10 each
● Introduced causes of active scans every hour
● Client collects all connection logs
● Sniffer logs WiFi traffic
● Duration: 9 hours

35. Client-end Solution: Results
35
Metric Modified Clients Unmodified Clients
#Probe Requests 500/hour 932/hour
Time to Connect 0.25 seconds 4.35 seconds
Connection Persistence 1 minute - 0.37
5 minutes - 0.55
15 minutes - 0.80
1 minute - 0.20
5 minutes - 0.43
15 minutes - 0.73
Simple client intelligence works

36. Key Takeaways
● Device-agnostic measures without special h/w or s/w needs
● Most APs come with sniffing antennas
● Easy to integrate with existing controller
● Sniffers may miss frames
● Multiple sniffers needed for comprehensive network view
36
Excessive Active scans affect performance in 2.4 GHz

37. Problem#2*
WiFi Indoor Localization using Existing Infrastructure
in the presence of Minimal Active Scans
37
5. D. Jaisinghani, R. Balan, V. Naik, Y. Lee, and A. Misra, “Experiences & Challenges with Server-Side
WiFi Indoor Localization Using Existing Infrastructure,” in MobiQuitous, 2018, New York, USA..

38. Research Question
How to localize several thousands of
devices in real-world indoor deployments?
38

39. The Challenges
● Infrastructure, i.e., the controller and the access points
changes
● Devices cannot be modified in any way
○ Explicit/implicit participation for data generation
○ App download
○ Chipset changes
○ Extra antennas
39

40. State-of-the-art Solutions
● Accuracy of few centimeters is possible with,
a. Sophisticated techniques such as AoA, ToF/ToA, RToF, and PoA [NSDI ‘13,
MobiCom ‘14, SIGCOMM ‘15]
b. Require extra hardware such as specialized antennas and ultrasonic systems
[MobiSys ‘05, NSDI ‘13, MobiCom ‘14, SIGCOMM ‘15]
c. Special requirements such as Line-of-Sight, Visible Light, Acoustics [NSDI ‘14,
Mobiquitous ‘15, MobiSys ‘15, MobiSys ‘18]
Can they be applied to a large-scale network where several thousands of WiFi
devices are to be localized? NO
Customized hardware, Client application, Rooting the Client OS, High Energy Budget,
High Cost of deployment - Limit Generalizability and Scalability
40

41. What Do We Have?
● Lots of access points
● Few controllers that manage these access points
● Access points can measure RSSI from the clients
● Only available data is RSSI measurements from access points -
○ We can at least attempt to localize
○ That's all we have
41

42. Solution
Fingerprint-Based WiFi Localization
● Scalability
○ Albeit the manual effort for setup, fingerprinting-based
localization is scalable
● Device Friendly
○ No client-side changes / No AP-side changes
● Integrable
○ Seamless integration with existing infrastructure is possible
Premise of fingerprint-based solutions - Clients always scan!
42

43. Fingerprinting Process
Offline Online
Fingerprints
∀ Li
∈ L, Known landmark Li,
RSSI Vector= < Li
, B, AP1
: RSSIi
; ...;
APn
: RSSIn
; >
Unknown landmark Lx,
RSSI Vector= < B, AP1
: RSSI'i
; ...;
APn
: RSSI'n
; >
Distance, Di
in Signal Space between Lx
and ∀ Li
∈ L,
Di
= sqrt((RSSIAP1
- RSSI'
AP1
)2
+ (RSSIAP2
- RSSI'
AP2
)2
+ … + (RSSIAPn
- RSSI'
APn
)2
)
Predicted Landmark = Li
with minimum Di
Already stored
in database
Collected in
real-time
43

44. System Architecture
...
Controller
AP1
WiFi Clients
AP2
APN
WiFi
Association
Ethernet
44
Location ServerRTLS Server

45. System Architecture (Contd.)
● 750+ dual-band access points
● Centrally controlled by 11 WiFi controllers
● 4000 associated clients per day
● RTLS data feed received every 5 seconds
45
Timestamp Age ChannelClient MAC AP Association Status Data Rate RSSI
RTLS Data Feed

46. Characterizing the Landmarks
46
Landmarks = Water
Sprinklers on the ceiling
Landmarks across floors
(Overlapping Region A)
Landmarks across floors
(Overlapping Region B)
Landmarks = water sprinklers, deployed every 3 meters

47. Ground Truth Data Collection
47
3203 landmarks, 86 hours data
● 4 different WiFi states
○ Emulate real-world usage scenarios
○ Modulate Scanning Frequency
○ Disconnected → Inactive → Intermittent → Active
WiFi On
State: Disconnected
WiFi On
State: Connected and
Inactive
WiFi On
State: Connected and
Intermittent
WiFi On
State: Connected and
Active
Scanning Frequency
Low High
Timestamp at every landmark is recorded at granularity of seconds

48. Data Processing Challenges
● Traffic Distinction
○ Scanning Records
○ Non-Scanning Records
● Offline fingerprints ➡ Scanning records
● Online fingerprints ➡ Scanning + Non-scanning records
● RTLS data feeds does not distinguish
● Proposed inference
○ Scanning records - fixed and lowest data rates
○ Non-scanning records - variable data rates
48

49. Problems Discovered
49
● Cardinality: Set of access points reporting for a client
● Fingerprinting-based Solutions - Effective and Efficient match
○ Clients always trigger active scans
○ Same set of APs respond
● Online and offline cardinalities are different - #Matches Affected
○ Cardinality mismatch
○ RSSI mismatch
○ High Client Scan Latency
Result → Clients are teleported !!

50. Evidence 1 - Cardinality Mismatch
50
OnlineOffline
5 GHz - 80%
2.4 GHz - 40%
Cardinality ⬇ from 16 ➡ 6 (Max)
Minimal Access Points to Match

51. Evidence 2 - RSSI Mismatch
51
Client close to AP Client far from AP
50 dB
5 dB
30 dB
10 dB
Non-Scanning Frames
Scanning Frames
Scanning Frames are Better

52. Evidence 3 - High Client Scan Latency
52
Very few scans
Scans ⬆
5 GHz Scans ⬇
Dual-Band Scans ❌
Stationary client do NOT scan

53. Cause 1 - Cardinality in Presence and Absence of Scans
Scans PresentScans Absent
No Access
Points Reports
Max. Access
Points in 5 GHz
No of Access
Points ⬆
Max. Access
Points in 5 GHz
No Access
Points Reports
Scans + 2.4 GHz is Better 53

54. Cause 2 - RSSI variation 2.4 GHz and 5 GHz
But,
RSSI variation in 2.4 GHz > 5
GHz (Higher range and
interference)
5 GHz is Better 54

55. Summary of the Problems
55
Distance of
Transmission
Variation in RSSI #Scanning Frames
2.4 GHz High High High
5 GHz Low Low Low
Distance of
Transmission
Variation in
RSSI
Frequency
Scanning Frames High Low Low
Non-scanning Frames Low High High
Improves accuracy
Reduces accuracy
Non-Trivial to solve

56. Recommendations to Reduce the Localization Errors
56
Baseline Maximum #APs AP with Maximum RSSI AP of Association
No floor
detection
logic
Floor from
which
maximum
number of
APs report
the client
Floor from
which
strongest
RSSI is
received
Floor of AP
to which
client is
associated
with
Detect floor before localizing
Metrics: Floor Error and Same Floor Error

57. An Example
57
Floor 2
AP1
AP2
AP3 AP4
Floor 1
Client
-50 dBm
-60 dBm
-70 dBm
-52 dBm
Floor 3
Maximum Number of APs
Floor 2
AP2
AP3 AP4
Floor 1
-50 dBm
-60 dBm
-70 dBm
-52 dBm
Floor 3
Client
AP1
AP with Maximum RSSI
Floor 2
AP2
AP3 AP4
Floor 1
Client
-50 dBm
-60 dBm
-70 dBm
-52 dBm
Floor 3
AP1
AP of Association

58. Reduction in Localization Errors
● 5 GHz band outperforms 2.4 GHz band
● Worst Heuristic - Maximum APs
○ Reason - Distant APs also respond
● Best Heuristic - AP of association
○ 17 meters (2.4 GHz), 20 meters (5 GHz)
○ Floor Errors- 78% ⬇ (2.4 GHz), 46% (5 GHz)
○ Same Floor Errors - 58% ⬇ (2.4 GHz) , 3.8% (5 GHz)
○ Reason - Clients associate with the nearest AP
● Compared with SignalSLAM [IPIN ‘13]
○ ~4 meters better, no client-side changes
58

59. Key Takeaways
● Few meters accuracy is OK
○ Contextual Location Aware Applications -
Marketing/Business use-cases
○ Tracking assets - employees/students
● Simple floor-detection heuristics can combat the challenges
● Limited by RTLS information
59
Reduced active scans hamper services like Localization

60. Problem#3
Harnessing Active Scans for Data Transfer in
WiFi-based IoT Nodes
60
6. D. Jaisinghani, H. Fulara, G. Singh and M. Maity and V. Naik, “Demo: Elixir - Sending Data in
WiFi-based IoT without the Data Frames,” Mobicom, 2018, New Delhi, INDIA
7. D. Jaisinghani, H. Fulara, G. Singh, M. Maity and V. Naik, “Sending Data in WiFi-based IoT
without the Data Frames,” Under Review.
# Won First prize at nationwide WiFi competition - WiFi ThinkFest 2017

61. When WiFi Fails
61
A WiFi Association is mandatory to enable data transfer
Case Signal Quality Associated? Cause Effect
1 Bad ✖ Sparse AP Deployment No Association
2 Bad ✔ Reduced RSSI
Connection
Maintenance/Handovers
3 Good ✖ Overloaded APs/Admin Policies No Association
4 Good ✔
High Channel Utilization and
Losses
Connection
Maintenance/Handovers

62. Research Question
Is it possible to transfer data in the absence of an ongoing WiFi
association, for example, in challenged scenarios?
62

63. Default States of a WiFi Client
63
Wake UpSleep
Transmit
Data
Interface
ON
Scan
Associated
Discover
APs
Check
Association
Successful
Association
Data
Unavailable
Data
Available
Failed
Association
Until this is done
This is not possible

64. Proposed Solution - ViFi Protocol [Scan (V) comes before Associate (W)]
64
Probe Requests
Probe Responses
Exchange of Data
Access
Points
IoT Nodes
Wake Up,
Scan &
Transmit
Data
Data
Available
Idle
Transmission
Complete
Interface
ON
Data
Available
+
The Idea Reduction in States
WiFi Clients always scan - Active Scan

65. Assumptions
● IoT nodes are sensors
● Data to be transmitted is small (few bits) and infrequent
● IoT nodes can trigger active scans
● At least 1 AP is available
● AP is open and configurable
65

66. Challenges to Implement ViFi
● Conformance to Existing Standards
○ No new packets should be introduced
● Simple to Deploy
○ Should be capable of operating on diverse set of devices
● Reliable Data Transfer
○ Should be able to transmit data at low/variable RSSI
● Co-exist Seamlessly with Default Protocols
○ Performance of nodes with default protocols should not be
hampered
66

67. State-of-the-Art Solutions
● Management frame stuffing [HotMobile ‘07, MSR Patent ‘05]
○ Interference Management [ arXiv ‘17 ]
○ Traffic Management [ VTC ‘14, AINA ‘16 ]
○ Localization [ TENSYMP ‘16 ]
○ Disaster Recovery [ Mobisys ‘16 ]
○ Location-based Information Services [ WMNC ‘16]
67
Application-based solutions, performance impact?

68. Protocol Implementation
68
Userspace App
Libnl Library
Client
Userspace App
Libnl Library
AP
Probe Request
Probe Response
WiFi
System Architecture
MAC Header (22) Frame Body (2320) FCS (4)
Fixed Fields Elements
Element ID (1) Length (1) OUI (3/5) Content
Default Frame Structure
Sequence Number More Data Length Data
Proposed Frame Structure

69. Proposed Protocol
69
Client AP1
Probe Response#1
AP2
APN
Channel 1 Channel 6 Channel 11
Probe Response#6
Probe Response#11
Probe Request#1
Probe Request#6
Probe Request#11
Stuff Data in
Probe Request
Trigger Active
Scan
Implicit
Acknowledgement
Extract
Data
Extract
Data
Extract
Data

70. Evaluation
70
Compare WiFi and ViFi Impact of ViFi on WiFi
Experiments
● IoT Nodes - Raspberry Pi
● AP - OpenWRT and hostapd
● Network conditions - Good and Bad
● Data - 300 Bytes
● Data generation intervals - 1 second and 120 seconds

71. Compare WiFi and ViFi
71
IoT Nodes -
WiFi Protocol
Access PointSniffer
IoT Nodes -
ViFi Protocol
Compare the effect

72. Number of Frames
72
WiFi transmits
~470% ⬆
frames,
32% retries
WiFi continues to
send discovery
frames

73. Airtime Utilization
73
WiFi consumes
at least 8x
higher Airtime

74. Delivery Rate & Goodput
74
ViFi delivers better or at par
with no retries
ViFi maintains better or at
par goodput

75. Impact of ViFi on WiFi
75
Non-IoT Nodes -
WiFi Protocol
Access PointSniffer
IoT Nodes -
ViFi Protocol
Non-IoT Nodes -
WiFi Protocol
Access PointSniffer
IoT Nodes -
WiFi Protocol
Compare the effect Unchanged

76. Contention Time
● When contention/collisions ⬆ ⇒ Inter-frame arrival time increase ⬆
● Affects all upper layer metrics - throughput, jitter, latency
● ⬆Contention time ⇒ nodes are struggling
76
IoT nodes
Contention faced
by non-IoT nodes
ViFi reduces contention

77. Key Takeaways
● ViFi serves as an Elixir - when WiFi fails
● ViFi eliminates network traffic
● Saves up to 18% energy
● Apt for low bit-rate applications - ambient data collection,
emergency broadcasts, ultra dense environments like India's
Kumbh Mela
● In Good network conditions, ViFi experiences higher delay
● Data generation interval needs to be well thought off
● Not suited for high-end data intensive transfers
77

78. Agenda
78
1
Background
● WiFi Networks
● Connecting
with an Access
Point
● Scanning
Scope
● Problem
Statement
● Methodology
Followed
● Challenges
2
Problems
● Unnecessary
Active Scans
● WiFi Indoor
Localization
● Data Transfer
with Active
Scans
3
Conclusion
● Summary
● Contributions
to Existing
and New
Standards
● Future Work
4

79. Conclusion
● Detailed analysis on active scanning protocol
● Methods to mitigate impact of active scans
● Practical challenges in localizing clients
● ViFi protocol for low-end IoT nodes
● Datasets and source codes are public
79
Active Scanning is default discovery protocol, all
latest and upcoming standards will benefit from our
device-agnostic approaches

80. Future Work
● Performance enhancements with Software Defined Networking
and Machine Learning
● Device-agnostic WiFi-based indoor localization
● Evaluate Association-free WiFi (The proposed ViFi) for
○ Security
○ Recovery
○ Downlink data transfer
○ MAC address randomization
80

81. Publications
1. D. Jaisinghani, V. Naik, S. K. Kaul, R. Balan, and S. Roy, “Improving the Performance of WLANs
by Reducing Unnecessary Active Scans,” ArXiv e-prints, Jul. 2018. [Under Review]
2. D. Jaisinghani, V. Naik, S. K. Kaul, and S. Roy, “Realtime detection of degradation in WiFi
network's goodput due to probe traffic,” in WinMee -WiOpt, May 2015, Bombay INDIA.
3. D. Jaisinghani, V. Naik, S. Kaul and S. Roy, “Sniffer-based Inference of the Causes of Active
Scanning in WiFi Networks,” Mar. 2017, NCC, Chennai, INDIA.
4. (H. Fulara, G. Singh)*, D. Jaisinghani, M. Maity and T. Chakraborty and V. Naik, “Learning to
Rescue WiFi Networks from Unnecessary Active Scans,” WoWMoM, 2019. Washington DC, USA
[Core A, *-Equal Contributions]
5. D. Jaisinghani, R. Balan, V. Naik, Y. Lee, and A. Misra, “Experiences & Challenges with
Server-Side WiFi Indoor Localization Using Existing Infrastructure,” in MobiQuitous, 2018, New
York, USA. [Core A]
6. D. Jaisinghani, H. Fulara, G. Singh, M. Maity and V. Naik, “Demo: Elixir - Sending Data in
WiFi-based IoT without the Data Frames,” Mobicom, 2018, New Delhi, INDIA [Core A*]
7. D. Jaisinghani, H. Fulara, G. Singh, M. Maity and V. Naik, “Sending Data in WiFi-based IoT
without the Data Frames,” Under Review.
81

82. Acknowledgements
82
Vinayak Naik
IIIT-Delhi, INDIA
Sanjit K. Kaul
IIIT-Delhi, INDIA
Sumit Roy
U. Washington, USA
Rajesh Balan
SMU, Singapore
Mukulika Maity
IIIT-Delhi, INDIA
Sambuddho
Chakravarty
IIIT-Delhi, INDIA
Vivek Bohara
IIIT-Delhi, INDIA
Karthik Dantu
U. Buffalo, USA
Nirupam Roy
U. Maryland, USA
Srihari Nelakuditi
U. South Carolina, USA
Mythili Vutukuru
IIT-Bombay,
INDIA

83. Appendix
83

84. Salient Features of Active Scanning
● Probe Requests and Probe Responses are transmitted at lowest bit-rate
● Probe traffic is broadcast traffic
● Stationary WiFi clients trigger active scanning unintelligently
● Frequent active scans fetch same information
● WiFi clients consume ~44.3% higher energy and lose up to 16.7% throughput
[IMC'15]
● Performance of clients suffer in dense WiFi networks due to unnecessary
active scans [TMC'10]
● Recognized in IEEE 802.11ax - High Efficiency WiFi Network (HEW) status
update meeting
84

85. The Protocol of Active Scanning
Client AP1
Probe Response#1
AP2
APN
Ch# 1 Ch# 6 Ch# 11
Probe Response#11
Probe Response#6
Probe Request#1
Probe Request#6
Probe Request#11
ACK#1
ACK#6
ACK#11
85

86. Effect of RSSI drop on #Probe Requests
Comparison Results - 2.4 GHz vs 5 GHz
86
5 GHz sees active scans
when RSSI drops
2.4 GHz sees
active scans
at all RSSI
Stationary clients scan minimally in 5 GHz
[Confirmed with #Status Changes Metric]
5 GHz sees more
active scans?
#Probe Requests Recorded Per Minute Per Client

87. Uncontrolled Network Setup - Channel Utilization
87

88. Devices Studies for Causes of Active Scans
88
Device Type Chipset Vendor Operating System Device Driver
Laptop Atheros, Intel,
Broadcam
Ubuntu 14.04/12.10
and Windows 8.1/7
Ath9k, iwlwifi
Tablets Qualcomm,
Broadcom
Android KitKat and
iOS 8.1
OS provided
Smartphones Broadcom,
MediaTek,
Qualcomm
Android KitKat,
Marshmellow,
JellyBean,
Cyanogen, and
Windows
OS Provided
USB Adapter Realtek and Atheros Ubuntu 14.04/12.10,
Window 8.1/7
rtl8812AU,
ath9k_htc

89. Implementing Sniffer-Based Inference with a DFA
89

90. States and Events
90

91. Cause Detection
91

92. Other Empirical Observations
● ↑ History of SSIDs ⇒ ↑ Probe Requests
● WiFi clients search for non-existing APs
● APs respond to all clients
● Dense deployment of APs ⇒ ↑ Probe Responses
92

93. Problem Statement - Localization
Highlight challenges and propose easy to integrate solutions
to build a universal indoor localization system – one that can
spot localize all WiFi enabled devices on campus without any
modifications to the client or infrastructure-side
93

94. Improvement in Localization Errors
94
Baseline Maximum #APs AP with Maximum RSSI AP of Association
2.4 ghz 5 ghz 2.4 ghz 5 ghz 2.4 ghz 5 ghz 2.4 ghz 5 ghz
Cardinal
ity
Same
Floor
Floor
Error
Same
Floor
Floor
Error
Same
Floor
Floor
Error
Same
Floor
Floor
Error
Same
Floor
Floor
Error
Same
Floor
Floor
Error
Same
Floor
Floor
Error
Same
Floor
Floor
Error
1 >50 20.00 29.50 3.10 >50 48.00 29.60 03.49 49.20 14.70 28.30 02.09 32.30 04.90 27.60 01.28
2 >50 18.30 26.80 02.00 >50 33.33 27.00 05.60 24.20 05.60 27.00 03.46 21.60 00.70 25.80 01.48
3 >50 33.15 20.12 00.00 >50 40.00 24.00 00.00 36.00 14.70 20.12 00.00 22.80 05.50 20.12 00.00
4 >50 18.49 NA 00.00 33.00 13.40 NA NA 24.00 11.00 NA NA 18.90 04.40 NA NA
5 19.20 10.25 NA NA 26.00 14.60 NA NA 17.49 00.00 NA NA 17.49 00.00 NA NA
6 23.00 04.17 NA NA 22.00 00.00 NA NA 16.00 00.00 NA NA 22.00 00.00 NA NA

95. Sniffer-Based Inference Dataset
95

96. Large Dataset for Sniffer Based Inference
96

97. Problem Statement - ViFi
We consider WiFi-enabled IoT nodes and APs. The IoT nodes are
sensor nodes, who want to transmit few bits of infrequent data.
They can trigger an active scan and at least one access point
responds. In such a network, we want to enable the IoT nodes to
transmit data to an AP, in the absence of a WiFi association
with any AP.
97