IoT Networking via Cross-technology Communication
A DISSERTATION
SUBMITTED TO THE FACULTY OF THE GRADUATE SCHOOL
OF THE UNIVERSITY OF MINNESOTA
BY
Ruofeng Liu
IN PARTIAL FULFILLMENT OF THE REQUIREMENTS
FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY
Advisor: Prof. Tian He
June, 2022
© Ruofeng Liu 2022
ALL RIGHTS RESERVED
Acknowledgements
This dissertation is accomplished with tremendous help from many amazing people.
First of all, I was extremely fortunate to work with my advisor Prof. Tian He. His
guidance carried me through all the stages of my graduate study and his never-ending
passion for innovation constantly inspired me. I am also incredibly grateful to Prof.
Antonia Zhai, Prof. Feng Qian, and Prof. Jarvis Haupt for serving as the committee
members of my preliminary exam, thesis proposal, and final defense. They provided
valuable feedback that significantly improve the quality of the dissertation.
I cherish the awesome time in MiNDs group and sincerely appreciate the contribu-
tions of the former and current members including Dr. Zhimeng Yin, Dr. Wenchao
Jiang, Dr. Song Liu, Dr. Song Min Kim, Dr. Desheng Zhang, Dr. Shuai Wang, Dr.
Zhijun Li, Dr. Yongrui Chen, Dr. Weiwei Chen, Dr. Deming Gao, Yi Ding, Shuai
Wang, Ling Liu, Sen Liu, Jin Ye, Nan Yu, and Songyuan Li. It is a pleasure to work
with these wonderful researchers. In addition, I would like to acknowledge Eric Olson
from the Intellectual Property Office of University of Minnesota for his assistance in the
technology commercialization of my research outcomes. Finally, I thank my family and
friends for their support during this arduous but fruitful journey.
The research in this thesis was supported in part by NSF grants CNS-1525235, CNS-
1718456, and CNS-1717059.
i
Dedication
To my family
ii
Abstract
The prevalence of Internet of Things (IoT) brings various heterogeneous wireless
techniques, such as Wi-Fi, LTE, ZigBee, Bluetooth, and LoRa. Due to the scarcity
of spectrum resources, these wireless technologies commonly share the unlicensed in-
dustrial, scientific and medical (ISM) radio band. The coexistence scenario motivates
the studies of IoT networking among heterogeneous wireless devices, which breaks the
boundary between wireless protocols and paves way for a lot of novel applications (e.g.,
cross-technology data dissemination, data collection, location services, etc.).
This dissertation focuses on the key enabler of IoT networking among heterogeneity
- cross-technology communication (CTC) which allows heterogeneous wireless devices
to directly exchange data without modifying their hardware. To address the critical
roadblock of CTC - incompatibility in their physical (PHY) layers, we propose two
approaches, demonstrating the feasibility of CTC both from high-speed to low-speed
radios and from low-speed to high-speed ones.
First, we present LTE2B which enables CTC from high-speed radios (e.g., LTE) to
low-speed radios (e.g., ZigBee and Bluetooth). The key technical contribution is a time-
domain signal emulation (TDE) approach which allows a LTE transmitter to produce
emulated ZigBee or Bluetooth signal by approximating their time-domain waveform.
In addition, it addresses other practical constraints (e.g., turbo coding constraint) to
achieve transparent CTC with full compatibility with LTE standards. Our experiment
result shows that LTE smartphones can directly disseminate messages to ZigBee devices
within a 400-meter range.
Second, we introduce XFi which shows the feasibility of CTC in the reverse direction,
i.e., from low-speed radios (e.g., ZigBee and LoRa) to high-speed Wi-Fi. To address
the fundamental limitation of bandwidth disparity, XFi adopts signal hitchhiking - low-
speed IoT packets from ZigBee and LoRa devices can hitchhike on the high-speed Wi-Fi
traffic and be captured by Wi-Fi radios. The unique discovery is that Wi-Fi devices
can obtain the hitchhiking IoT data from the errors in decoded Wi-Fi payloads that are
available in the software. The key insight enables CTC with zero modification to Wi-Fi
iii
hardware. Our evaluation demonstrates that Wi-Fi can collect data from 8 IoT devices
in parallel with an overall throughput of 1.8 Mbps.
Finally, we adopt CTC technique in a commercial Bluetooth location service to study
and address the challenges of applying cross-technology design in real-world scenarios.
We propose WiBeacon which repurposes ubiquitously deployed WiFi access points (AP)
into virtual BLE beacons via only moderate software upgrades. This offers fast deploy-
ment of BLE LBS with zero additional hardware costs and low maintenance burdens.
WiBeacon is carefully integrated with native WiFi services, retaining transparency to
WiFi clients. We implement WiBeacon on commodity WiFi APs (with various chipsets
such as Qualcomm, Broadcom, and MediaTek) and extensively evaluate it across vari-
ous scenarios, including a real commercial application for courier check-ins. During the
two-week pilot study, WiBeacon provides reliable services, i.e., as robust as conventional
BLE beacons, for 697 users with 150 types of smartphones.
iv
Contents
Acknowledgements i
Dedication ii
Abstract iii
List of Tables ix
List of Figures x
1 Introduction 1
2 Background 4
2.1 IoT Networking Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Comparison of Heterogeneous IoT protocols . . . . . . . . . . . . . . . . 5
3 Related Work 7
3.1 Wireless Coexistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Multi-radio Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Packet-level Cross-technology Communication . . . . . . . . . . . . . . . 8
3.4 Physical-layer Cross-technology Communication . . . . . . . . . . . . . . 8
4 Signal Emulation 10
4.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 MOTIVATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Frequency Domain Emulation . . . . . . . . . . . . . . . . . . . . 13
v
4.2.2 Time Domain Emulation . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 SC-FDMA EMULATION . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1 Opportunity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.2 Background: Modulation in LTE . . . . . . . . . . . . . . . . . . 17
4.4.3 Background: Demodulation in ZigBee . . . . . . . . . . . . . . . 18
4.4.4 Emulation Challenges . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.5 TDE under Misaligned Sample Rates . . . . . . . . . . . . . . . 18
4.4.6 TDE under SC-FDMA . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.7 TDE under Duration Constraints . . . . . . . . . . . . . . . . . 23
4.5 Reverse LTE Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.1 Background: LTE Channel Coding . . . . . . . . . . . . . . . . . 24
4.5.2 Challenges in Reversing Turbo Coding . . . . . . . . . . . . . . 25
4.5.3 Reverse Turbo Coding . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6 PERFORMANCE EVALUATION . . . . . . . . . . . . . . . . . . . . . 27
4.6.1 System Implementation . . . . . . . . . . . . . . . . . . . . . . . 27
4.6.2 Evaluation Setting . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6.3 Chip Error Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6.4 Symbol Error Rate . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6.5 Frame Reception Rate . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6.6 LTE2B Performance: Indoor and Outdoor . . . . . . . . . . . . . 32
4.6.7 Repeated Transmission . . . . . . . . . . . . . . . . . . . . . . . 34
4.6.8 LTE2B Performance: Mobility . . . . . . . . . . . . . . . . . . . 34
4.6.9 LTE2B in Bluetooth Low Energy . . . . . . . . . . . . . . . . . . 35
4.6.10 Time-Domain Emulation in WiFi . . . . . . . . . . . . . . . . . . 36
4.6.11 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Signal Hitchhiking 38
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 MOTIVATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 XFi in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
vi
5.4 Background and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5 Waveform Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.5.1 Channel Decoding and Error Correction . . . . . . . . . . . . . . 46
5.5.2 Feasibility of Waveform Reconstruction . . . . . . . . . . . . . . 47
5.5.3 Waveform Reconstruction Algorithm . . . . . . . . . . . . . . . . 48
5.6 Robust Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.6.1 Signal Erasure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.6.2 Combat Signal Erasure: Symbol-level . . . . . . . . . . . . . . . 51
5.6.3 Combat Signal Erasure: Chip-level . . . . . . . . . . . . . . . . . 52
5.7 Practical Signal Hitchhiking . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.7.1 Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.7.2 Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.8 limitation and discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.9 performance evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.9.1 Evaluation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.9.2 Overall Performance . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.9.3 PHY Layer Performance . . . . . . . . . . . . . . . . . . . . . . . 58
5.9.4 Symbol Error Rate . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.9.5 Frame Reception Rate . . . . . . . . . . . . . . . . . . . . . . . . 59
5.9.6 XFi:LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.10 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Location Service via CTC 64
6.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2 MOTIVATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3 OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4 BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.1 iBeacon Preliminary . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.4.2 Limitation of Existing CTC . . . . . . . . . . . . . . . . . . . . . 70
vii
6.5 WIBEACON Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.5.1 WiBeacon Broadcast via CCK . . . . . . . . . . . . . . . . . . . 72
6.5.2 Tackle Signal Imperfection . . . . . . . . . . . . . . . . . . . . . 73
6.5.3 Misalignment Compensation . . . . . . . . . . . . . . . . . . . . 76
6.6 Integration with WiFi Services . . . . . . . . . . . . . . . . . . . . . . . 77
6.6.1 Compatible Integration . . . . . . . . . . . . . . . . . . . . . . . 77
6.6.2 Dynamic WiBeacon Scheduling . . . . . . . . . . . . . . . . . . . 78
6.7 LIMITATION and DISCUSSION . . . . . . . . . . . . . . . . . . . . . . 80
6.7.1 Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.7.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.7.3 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.8 SYSTEM IMPLEMENTATION . . . . . . . . . . . . . . . . . . . . . . . 82
6.9 PERFORMANCE EVALUATION . . . . . . . . . . . . . . . . . . . . . 83
6.9.1 Evaluation Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.9.2 WiBeacon Broadcast Reliability . . . . . . . . . . . . . . . . . . 84
6.9.3 Integration with WiFi Services . . . . . . . . . . . . . . . . . . . 88
6.9.4 Overall Service Performance . . . . . . . . . . . . . . . . . . . . . 89
6.9.5 Pilot Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.9.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7 Future Works 94
7.1 CTC Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.2 CTC with Machine Learning . . . . . . . . . . . . . . . . . . . . . . . . 95
7.3 Cross-technology Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8 Conclusion 96
Bibliography 97
viii
List of Tables
2.1 Comparison of Wireless Techniques . . . . . . . . . . . . . . . . . . . . . 6
5.1 Symbol-to-chip Mapping in ZigBee (802.15.4) . . . . . . . . . . . . . . . 51
5.2 Summary of XFi Performance. . . . . . . . . . . . . . . . . . . . . . . . 57
6.1 Representative WiFi Devices Tested. . . . . . . . . . . . . . . . . . . . . 83
ix
List of Figures
4.1 Frequency Domain Signal Emulation. . . . . . . . . . . . . . . . . . . . . 13
4.2 FDE-emulated Signal vs. Standard. . . . . . . . . . . . . . . . . . . . . 14
4.3 Time Domain Signal Emulation. . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Architecture of LTE2B. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 SC-FDMA Modulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6 How a ZigBee Receiver Demodulates. . . . . . . . . . . . . . . . . . . . . 17
4.7 Sample Distribution: Time vs. Frequency. . . . . . . . . . . . . . . . . . 19
4.8 Emulation Error Distribution: TDE vs. FDE. . . . . . . . . . . . . . . . 19
4.9 Emulated Signal: TDE vs. FDE. . . . . . . . . . . . . . . . . . . . . . . 20
4.10 Chip Errors: TDE vs. FDE. . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.11 Emulated Signal in SC-FDMA. . . . . . . . . . . . . . . . . . . . . . . . 21
4.12 QAM point Flip in SC-FDMA. . . . . . . . . . . . . . . . . . . . . . . . 22
4.13 LTE Uplink Subframe Structure. . . . . . . . . . . . . . . . . . . . . . . 22
4.14 Channel Coding Data Flow. . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.15 Turbo Coding Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.16 Non-negligible Impacts of CRC on Coded Bits. . . . . . . . . . . . . . . 25
4.17 Computation of CRC Bits. . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.18 Experiment Setting for LTE2B . . . . . . . . . . . . . . . . . . . . . . . 27
4.19 Hamming Distance (a) TDE (b) FDE. . . . . . . . . . . . . . . . . . . . 29
4.20 Symbol Error Ratio (a) All symbols (b) GI-polluted vs. GI-free Symbols. 30
4.21 FRR vs. RSSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.22 FRR vs. Duration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.23 Hallway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.24 Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
x
4.25 Indoor FRR (a) Hallway (b) Library. . . . . . . . . . . . . . . . . . . . . 32
4.26 Outdoor Experiment Site . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.27 FRR vs. Distances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.28 FRR vs. Tx Distance (retransmission) . . . . . . . . . . . . . . . . . . . 34
4.29 FRR vs. Frame Duration (retransmission) . . . . . . . . . . . . . . . . . 34
4.30 FRR in Mobility and Duty Cycle . . . . . . . . . . . . . . . . . . . . . . 35
4.31 LTE2B in BLE (a) Emulation (b) FRR. . . . . . . . . . . . . . . . . . . 36
4.32 FRR WiFi TDE vs FDE (a) ZigBee (b) BLE. . . . . . . . . . . . . . . . 36
4.33 Light Control Application of LTE2B . . . . . . . . . . . . . . . . . . . . 37
5.1 (a) XFi Enables a WiFi Smartphone to Collect Data from Heterogeneous
IoT Devices. (b) XFi Analyzes the Decoded WiFi Payload to Obtain
ZigBee or LoRa Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Demodulation Procedures in WiFi Receiver. . . . . . . . . . . . . . . . . 44
5.3 FFT of WiFi Signal with Hitchhiking IoT Data. . . . . . . . . . . . . . 45
5.4 Error Correction in LDPC Decoder. . . . . . . . . . . . . . . . . . . . . 46
5.5 Error Correction (Flip) Ratio vs. Bit Error Ratio. . . . . . . . . . . . . 47
5.6 XFi Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Parity Removal Erasures IoT waveform. . . . . . . . . . . . . . . . . . . 49
5.8 (a) CP Removal of WiFi Symbol. (b) CP Removal of IoT Waveform
Erasures IoT waveform. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.9 Overall Pattern of Signal Erasure. . . . . . . . . . . . . . . . . . . . . . 50
5.10 Decoding ZigBee Symbol with Blacklist. . . . . . . . . . . . . . . . . . . 52
5.11 ZigBee Chip. (a) Uniform Samples of Standard ZigBee Chip. (b) Erasure-
aware Samples of Partially Reconstructed ZigBee Chip. . . . . . . . . . 53
5.12 The downlink WiFi frame from AP consists of a cross-technology polling
notification to IoT devices (t1 − t2) and a carrier of IoT signal (t2 − t3). 54
5.13 Power Spectrum and Channel Allocation. . . . . . . . . . . . . . . . . . 55
5.14 Experimental Setting for XFi. . . . . . . . . . . . . . . . . . . . . . . . . 57
5.15 Reconstructed ZigBee vs. Standard ZigBee. . . . . . . . . . . . . . . . . 58
5.16 Chip Error Distribution in ZigBee Symbols. . . . . . . . . . . . . . . . . 59
5.17 Symbol Error Ratio vs. Distances. . . . . . . . . . . . . . . . . . . . . . 59
5.18 Frame Reception Ratio vs. Distances. . . . . . . . . . . . . . . . . . . . 60
xi
5.19 Frame Reception Ratio with RS code. . . . . . . . . . . . . . . . . . . . 60
5.20 Spectrum of Reconstructed LoRa Waveform. . . . . . . . . . . . . . . . 60
5.21 LoRa Performance (Spreading Factor = 5). . . . . . . . . . . . . . . . . 61
6.1 WiBeacon Turns Ubiquitous WiFi APs into Virtual BLE beacons for
Location-based Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Frame Format, Modulation and Demodulation of an iBeacon Broadcast
Frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3 Previous OFDM Method Suffers from Severe Chip Errors Due to the
Cyclic Prefix Restriction. . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.4 Complementary Code Key (CCK) Modulation Produces 11 MHz QPSK
Chips w/ Quadrature Phases and Transmit in Sequence. . . . . . . . . . 72
6.5 CCK Method: Target BLE Chip (top), Basic CCK Method (middle),
and Signal Imperfections Caused by Restricted CCK Codewords (bottom). 73
6.6 WiBeacon Exploits Low-Pass Filtering (a) of an BLE Receiver to Elim-
inate Signal Imperfections. The BLE Signal Produced via Our CCK
Method (b) has Spiky and Separated Errors (Grey Regions in (b)). Spiky
Errors are Smoothed out by Low-pass filtering (c) and thus Incurs Zero
Chip Errors (d). In Contrast, Previous OFDM Method (e) produces
Chunky and Concentrated Errors (Grey Regions in (e)) that are Re-
tained after Low-pass Filtering (f) and Causes Severe Chip Errors (g).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7 Codebook Adjustment Compensates Misalignments (∆f = fw − fb = 1
MHz in the example). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.8 Opportunities for Dynamic Scheduling. . . . . . . . . . . . . . . . . . . . 78
6.9 Explore WiFi Temporal Whitespaces . . . . . . . . . . . . . . . . . . . . 79
6.10 Evaluation Scenarios (Commodity WiFi AP and BLE Beacon at a Hall-
way, a Lab, and a Bridge). . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.11 Chip Errors: CCK vs. OFDM. . . . . . . . . . . . . . . . . . . . . . . . 84
6.12 Frame Reception Ratio vs. RSSI. . . . . . . . . . . . . . . . . . . . . . . 85
6.13 Indoor Performance: WiBeacon vs. BLE. . . . . . . . . . . . . . . . . . 85
6.14 Outdoor FRR: WiBeacon vs. BLE. . . . . . . . . . . . . . . . . . . . . . 86
6.15 Impact of WiFi Transmission Power. . . . . . . . . . . . . . . . . . . . . 87
xii
6.16 Frame Reception vs. Misalignments. . . . . . . . . . . . . . . . . . . . . 87
6.17 Transparency to WiFi Traffic. . . . . . . . . . . . . . . . . . . . . . . . . 88
6.18 Transparency to Ambient BLE Devices. . . . . . . . . . . . . . . . . . . 89
6.19 Distribution of Detection Interval. . . . . . . . . . . . . . . . . . . . . . 89
6.20 Proximity Estimation Accuracy. . . . . . . . . . . . . . . . . . . . . . . . 90
6.21 Pilot Study. (a) WiBeacon Deployments in 20 Restaurants. (b) 150
Smartphone Models Served by WiBeacon. (c) RSSI: WiBeacon vs. BLE
Beacon. (d) WiBeacon is as Accurate as BLE Beacon in Courier Detections. 91
xiii
Chapter 1
Introduction
Internet of things (IoT) is a disruptive technology that brings connectivity and intel-
ligence to physical objects. They are rapidly expanding to every industrial vertical
(smart factory, warehouse, transportation, etc.) as well as many aspects of our daily
life (e.g., office automation and smart home). According to a study from Statista [1],
the number of connected IoT devices will reach 75.44 billion in the year 2025. To enable
the connectivity of IoT devices, a wide range of wireless technologies (e.g., Wi-Fi, LTE,
Bluetooth, ZigBee, and LoRa) have been invented and deployed to accommodate di-
verse applications. For example, there are more than 22.2 billion WiFi devices deployed
in the year 2021 [2], providing high-speed data services such as social media and video
conference, whereas Bluetooth and ZigBee devices are also shipped in 760 million and
30 million respectively for low-power IoT applications such as health monitoring and
location tracking [3].
Due to the scarcity of spectrum resources, these wireless technologies share the un-
licensed spectrum, i.e., industrial, scientific, and medical (ISM) radio band. The coex-
istence of wireless technologies motivates us to propose a new IoT networking paradigm
- cross-technology communication (CTC) which enables the incompatible wireless de-
vices to directly exchange data. We envision that CTC can break the boundary between
wireless technologies and pave the way for a lot of interesting applications. For example,
a smartphone can use its Wi-Fi or LTE interface to directly control or collect sensing
data from the ambient ZigBee or LoRa sensors while providing a friendly user interface
for data visualization and a powerful computing platform for sensor fusion and machine
1
2learning. In addition, ubiquitously installed Wi-Fi access points might be reused to
provide location services for low-power IoT devices (e.g., Bluetooth wearable), which
cuts down the maintenance cost of additional IoT infrastructure.
However, cross-technology communication (CTC) is technically challenging because
these heterogeneous wireless devices adopt highly incompatible physical (PHY) layers
and media access control (MAC) protocols, and are running different upper-layer wire-
less services. The common belief is that wireless devices cannot understand a message
in a heterogeneous wireless protocol and will treat it as noise. In this dissertation, we
propose a series of novel designs to break this common belief, showing that CTC is 1)
theoretically feasible, 2) technically implementable on commodity wireless devices (e.g.,
smartphone), and 3) practically applicable to serve real-time applications. The outline
of the dissertation is as follows.
• PHY-layer Compatibility via Signal Emulation (Chapter 4). This chap-
ter studies the feasibility of cross-technology communication from high-speed ra-
dios (e.g., LTE and Wi-Fi) to low-speed radios (e.g., ZigBee and Bluetooth). The
key idea proposed is signal emulation, in which we use the signal of high-speed
radios to emulate the waveform of low-speed techniques. We implement signal em-
ulation technique on LTE which enables LTE SC-FDMA modulator to produce
emulated ZigBee or Bluetooth signal. In addition, it addresses other practical
constraints (e.g., turbo coding constraint) to achieve transparent CTC without
modifying LTE hardware. Our experiment results have shown that LTE smart-
phone can directly send a message to a ZigBee device at a 400-meter distance.
• PHY-layer Compatibility via Signal Hitchhiking (Chapter 5). The chap-
ter discusses cross-technology communication in the reverse direction (i.e., from
low-speed to high-speed radios), where signal emulation is inapplicable due to the
significant disparity in bandwidth. To address the fundamental challenge, this
chapter presents signal hitchhiking technique that allows low-speed IoT packets
to hitchhike on the traffic among high-speed radios. Further, we discover that
high-speed radios can recover the hitchhiking IoT data despite the information
loss due to the incompatible decoding procedure. We implement this technique
on Wi-Fi and the evaluation demonstrates that a Wi-Fi radio can simultaneously
3collect data from 8 ZigBee or LoRa devices with an overall throughput of 1.8
Mbps.
• Location Service via CTC with Service-level Compatibility (Chapter
6). This chapter presents an application of CTC to solve problems in the real
world. Specifically, we repurpose already deployed WiFi infrastructures to serve
as virtual BLE beacons for large-scale BLE location services, which cuts down
the deployment and maintenance burden. With software upgrades, existing WiFi
access points (AP) broadcast BLE location identifiers to mobile devices. We
report our experience of deployment in a real commercial LBS application, i.e.,
meal courier tracking in intelligent food delivery. During our two-week pilot study,
it provides location services for 697 meal couriers and helps to track 1780 food
orders. The result of the study demonstrates that CTC provides as reliable services
as conventional BLE beacons.
The dissertation is organized as follows. Chapters 2 and 3 provide the background
knowledge on wireless protocols in IoT networks and the related literature. Chapters
4 and 5 discuss two critical techniques that address PHY-layer compatibility among
heterogeneous protocols. Chapter 6 demonstrates the real-world applications of CTC in
Bluetooth location service. The dissertation is wrapped by future work and conclusion
in Chapters 7 and 8.
Chapter 2
Background
2.1 IoT Networking Techniques
The proliferation of IoT applications brings about a wide spectrum of wireless tech-
nologies. In the work, we study five representative technologies that operate on the
unlicensed industrial, scientific, and medical (ISM) radio band: Wi-Fi, unlicensed LTE,
Bluetooth, ZigBee, and LoRa.
• Wi-Fi. Wi-Fi is the most commonly used wireless local area network (WLAN)
protocol. It is based on the IEEE 802.11 family of standards (i.e., b/g/n/ac/ax)
designed to provide high-speed Internet connection for laptop computers, tablet
computers, smartphones, etc. In the year 2019, over 3.05 billion Wi-Fi devices are
shipped.
• unlicensed LTE. Unlicensed LTE consists of a family of cellular network stan-
dards operating in the unlicensed spectrum including LTE in Unlicensed spectrum
(LTE-U), Licensed-Assisted Access (LAA), and MulteFire. LTE-U and LAA are
extensions of the Long-Term Evolution (LTE) wireless standard intended to allow
cellular network operators to offload some of their data traffic by accessing the
unlicensed spectrum, while MulteFire operates entirely in the unlicensed band.
• BLE. Bluetooth Low Energy (BLE) is a wireless personal area network (WPAN)
technology that is widely applied in smart wearable, healthcare, and location
4
5tracking. Compared to Classic Bluetooth, BLE significantly reduced power con-
sumption while maintaining a similar communication range.
• ZigBee. Zigbee is a low-power wireless personal area network (WPAN) tech-
nique based on IEEE 802.15.4 specification. Its targeted applications are home
automation, wireless sensor network, industrial control system, etc.
• LoRa. LoRa is an emerging technique designed for low-power wide-area networks
(LPWAN). LoRa enables long-range transmissions with low power consumption.
The key use cases of LoRa include both outdoor scenarios (e.g., smart agriculture)
as well as indoor scenarios (e.g., smart buildings and metering).
2.2 Comparison of Heterogeneous IoT protocols
Table 2.1 compares the frequency band, data rate, bandwidth, physical layer (modula-
tion and channel coding), and energy consumption of five representative IoT protocols.
• Frequency bands. These heterogeneous IoT protocols coexist in ISM bands.
For example, all the techniques in this study use 2.4 GHz. Furthermore, both
Wi-Fi and unlicensed LTE also coexist in 5 GHz. The coexistence provides the
opportunity for cross-technology communication.
• Data rates. Designed for different applications, heterogeneous IoT protocols vary
dramatically in data rates. At a high level, we can classify them into high-speed
protocols (Wi-Fi and LTE) that provide several hundred Mbps maximum data
rates and low-speed protocols (BLE, ZigBee, and LoRa) with less than 1 Mbps
data rates. To achieve the data rates, these techniques are designed with distinct
physical layers and consume different amounts of energy as discussed below.
• Bandwidth. In general, high-speed protocols support large bandwidths, leading
to higher baseband sample rates of the radios, whereas low-speed protocols have
limited bandwidths, requiring lower sample rates. As a result, a Wi-Fi channel
radio overlaps with 2 ZigBee channels, 8 BLE and LoRa channels.
• Modulation. High-speed protocols (i.e., Wi-Fi and LTE) commonly adopt QAM
to boost data rates whereas low-speed protocols (i.e., ZigBee, BLE, and LoRa) use
6GFSK, OQPSK, and CSS which provide limited data rates but are more robust
to noise. Furthermore, both Wi-Fi and the LTE eNodeB (i.e., base station) en-
code data onto multi subcarriers with Orthogonal frequency-division multiplexing
(OFDM) for spectrum efficiency. In contrast, LTE UEs (e.g., smartphone) and
low-power IoT devices modulate data onto a single carrier, which leads to better
energy efficiency.
• Coding. Wi-Fi and LTE use highly sophisticated channel coding methods such
as low-density parity-check (LDPC) and Turbo code to protect the data against
the noisy channel. In contrast, ZigBee and LoRa choose more basic coding or
spreading approaches (e.g., DSSS and Hamming code). It is noteworthy that
BLE does not provide any channel coding for the simplicity of the protocol.
• Energy. Due to larger bandwidths and more sophisticated PHY layers, high-
speed protocols consume more energy than low-speed ones. Thus, high-speed
radios are usually used in the high-end devices for multi-media services while low-
speed radios are typically used in the low-cost IoT devices, wearables, location
beacons that have limited battery budgets.
Wi-Fi LTE BLE ZigBee LoRa
Freq. band 2.4&5 GHz 2.4&5 GHz 2.4 GHz 2.4 GHz Sub-1 &2.4 GHz
Data rates 450 Mbps 300 Mbps 1 Mbps 250 Kbps 27 Kbps
Bandwidth 20/40/22 MHz 1.4-20 MHz 1 MHz 2 MHz 125/500 KHz
Modulation QAM-OFDM QAM-SCFDMA GFSK OQPSK CSS
Coding LDPC Turbo N/A DSSS Hamming
Energy High High Low Low Very Low
Table 2.1: Comparison of Wireless Techniques
Chapter 3
Related Work
3.1 Wireless Coexistence
Traditional researches on wireless coexistence commonly consider heterogeneous pro-
tocols as enemies that compete from the spectrum resource, creating cross-technology
interference (CTI). So the focus of these studies are protecting the homogeneous commu-
nication against CTI via forward error correction (FEC) [4–10], retransmission [11,12],
CTI avoidance [55, 75, 14, 40, 10], and signal recovery [52, 67, 27, 9, 35]. Recently
Cross-technology communications (CTC) has emerged as a promising direction in the
wireless coexistence. Instead of considering the coexistence as a source of interference,
CTC leverages it as an opportunity to establish direct communication among hetero-
geneous techniques. Researchers envision that CTC not only effectively addresses CTI
(e.g., via explicitly negotiating spectrum allocation among heterogeneity) but inspires
many novel applications (e.g. cross-technology data distribution, localization, MIMO,
time synchronization, etc).
3.2 Multi-radio Gateway
To exchange messages among heterogeneous wireless protocols, the de facto solution
is a multi-radio gateway, which offers indirect connection [13] since it is assumed that
these heterogeneous technologies cannot communicate with each other directly due to
the incompatible PHY layers. Although the multi-radio gateway is a viable approach,
7
8it suffers a few emerging issues when wireless networks become increasingly ubiquitous,
mobile, and dense. For instance, to support mobility, either a full coverage of gateways
or mobile gateways is needed, introducing high deployment cost and design complexity.
In dense networks, extra traffic overhead flowing into and outwards from the gateways
escalates the collision and interference in wireless co-existence environments.
3.3 Packet-level Cross-technology Communication
Early studies of CTC use packets to construct unique energy patterns that are distin-
guishable by different wireless radios. For example, Esense [14], Howies [15], WiZig [16],
and EMF [17] encode the data via the duration of the packets. FreeBee [18] modulates
information by shifting the timing of beacons. Finally, B2W2 [19] controls the en-
ergy level of Bluetooth packets and then demodulates through WiFi CSI. Since energy
sensing is widely available across various wireless radios (e.g., WiFi, ZigBee, and LTE-
LAA), packet-level CTC is generally applicable. However, these methods only exploit
coarse-grained packet-level information and thus suffer from extremely low data rates.
3.4 Physical-layer Cross-technology Communication
To boost the data rate, the recent advances in physical-layer CTC propose to emulate
the waveform of the CTC receiver at the transmitter side or decode the heterogeneous
packets at the receiver side. The projects discussed in this dissertation all belong to the
physical-layer CTC. Therefore, we briefly compare this dissertation with the represen-
tative works in this branch.
WEBee [20] is the pioneering work that enables Wi-Fi to ZigBee CTC by emulating
the target ZigBee waveform at the Wi-Fi transmitter. We found that WEBee is based
on frequency domain emulation (FDE) - emulating the target signal in the frequency
domain. As a result, it inherently suffers from high quantization errors, leading to
significant packet loss. WIDE [21] revises FDE to improve the performance of WEBee
but still inevitably suffers from the errors due to the inherent limitation of FDE. In
Chapter 4, we introduce the time-domain emulation (TDE). By adopting idea of TDE,
we significantly reduce the quantization errors, leading to a more reliable CTC. In
9addition, the work in [22] takes advantage of the LTE modulator to emulate WiFi control
packets for reducing the cross-technology interference. However, this design requires
modification of the LTE stack, since it essentially bypasses the LTE protocol constraints
(e.g., header, CRC and coding constraints). Chapter 4, we introduce methods that make
CTC fully compliant with the LTE standard.
The second branch of physical-layer CTC focuses on decoding the heterogeneous
packets at the receiver side. SymBee [23] and LEGOFi [24] propose to decode ZigBee
signal in the WiFi device. However, they modify WiFi demodulation procedures, and
thus cannot be deployed on commodity WiFi hardware. Besides, their designs are tightly
coupled with the unique features of ZigBee signal and thus cannot be generalized to other
wireless techniques (e.g., LoRa). In Chapter 5, we introduce the first receiver-side CTC
that works on commodity WiFi radios and it is also the first general method that can
be extended to various IoT technologies.
Chapter 4
Signal Emulation
4.1 INTRODUCTION
This chapter introduces cross-technology communication from high-speed radios (e.g.,
LTE and Wi-Fi) to low-speed radios (e.g., ZigBee and Bluetooth), which can enable
several interesting applications. For example, the lighting condition of ZigBee-enabled
smart bulbs can be adjusted remotely via LTE network. LTE-based Multefire network
[25] can share the coordination information to the incumbent low-power IoT devices in
the 2.4 GHz unlicensed band to mitigate the severe coexistence problem.
To achieve CTC, we present signal emulation technique. Our key insight is that
high-speed radios are commonly equipped more sophisticated modulator, allowing it
to generate significantly more complex waveform than low-speed radios. By carefully
selecting payload data, high speed radios can produce signal that approximates the
standard waveform of low-speed protocols. For example, as we mention in Table 2.1,
LTE has a 20 MHz bandwidth, which 10 times larger than ZigBee. In addition, LTE
adopts higher-order modulation schemes (e.g., QAM) than ZigBee (OQPSK). Therefore,
the waveform produced by a LTE radio has a larger degree of freedom (DoF) such that
there could be specific LTE waveform that approximates standard ZigBee signal.
We notice that high-speed wireless techniques commonly support both frequency-
domain modulation (e.g., OFDM) and time-domain modulation (e.g., SC-FDMA). Pre-
sumably, the target signal of low-speed radios could be emulated from either frequency
domain or time domain. However, we observe that frequency-domain emulation (FDE)
10
11
[20] inherently suffers from high quantization errors, leading to the loss of near half of
the transmitted CTC packets. This inherent unreliability hinders many critical IoT ap-
plications, such as channel coordination and controlling IoT devices, since they generally
require reliable communication for performance guarantee.
To offer reliable emulation, we are the first to introduce the time-domain emulation
(TDE), which approximates the target signal in the time domain. Specifically, after
sampling the target signal, TDE chooses the nearest quadrature amplitude modulation
(QAM) points in the time domain. Compared with the FDE based techniques, TDE
significantly reduces quantization errors, thus improving the CTC reliability. For vali-
dating the idea of TDE, we design and implement LTE2B, a PHY-layer CTC technique
based on TDE that enables an LTE network to deliver messages via LTE smartphones
to commodity ZigBee and BLE devices. As the benefit of TDE, LTE2B offers reliable
emulation performance - to emulate a ZigBee packet with more than 99% reliability,
it only needs a modulation scheme as low as quadrature phase shift keying (QPSK).
In contrast, frequency-domain emulation requires 64 QAM (a much higher modulation
scheme than QPSK) for emulating the same waveform, while it still suffers from severe
packet losses (around 50%) [20].
In addition, LTE2B is fully compliant to the LTE and ZigBee/BLE protocol, gener-
ating the decodable ZigBee/BLE signal purely based on the IP payload of a LTE packet.
Specifically, neither the LTE smartphones nor the ZigBee/BLE devices require hard-
ware and firmware modification, indicating this technology can be deployed rapidly in
existing network infrastructure. To achieve full compliance, LTE2B addresses multiple
practical challenges. Unlike Wi-Fi, ZigBee and BLE, LTE is probably the most com-
plicated wireless standard designed so far, aiming at a high configurability, flexibility,
and efficiency. Such complexity introduces constraints in multiple dimensions includ-
ing misaligned sample rates, coding constraints, modulation constraints, and duration
constraints, etc. In order to repurpose a LTE modulator into a time domain signal
emulator, LTE2B penetrates each constraint and involves tackling a series of highly
challenging tasks.
To summarize, our intellectual contributions are:
• We propose the first CTC technique based on time-domain emulation (TDE) which
emulates the target waveform in the time domain in contrast to existing frequency
12
domain emulation (FDE) [20]. TDE significantly improves the emulation accuracy
with limited resources, demonstrating its efficiency and generality.
• We design LTE2B to demonstrate the feasibility of TDE on commodity wireless
devices. LTE2B is the first CTC work that bridges WAN and PAN, so that
it leverages the best of both worlds, i.e., the full coverage capability of the LTE
devices and energy-efficiency and low-cost of the ZigBee/BLE devices. Such a new
wireless architecture will support emerging applications such as lighting, irrigation
and access control within smart and connected communities.
• To implement LTE2B while being compliant to the LTE protocols, LTE2B pene-
trates the complicated LTE stack and several practical constraints, e.g., misaligned
sample rates, flipped QAM points, and turbo coding constraint. By doing this,
LTE2B is a transparent design which is compatible with commodity LTE smart-
phones, commodity BLE devices, and ZigBee devices, allowing user applications
to control these IoT devices purely based on the LTE IP payload. These inno-
vations provide generic guidance for penetrating the constrained layers of other
wireless systems.
• Our LTE2B design, implementation, and evaluation are very extensive, given the
high complexity of the LTE standard. Specifically, we implement the LTE2B
sender on LTE smart-phone Nexus 5X and the LTE2B receiver on CC2530/CC1350
Zigbee/BLE SoC without any hardware or firmware modification. Our extensive
evaluation demonstrates that LTE2B can achieve a robust, long-distance CTC
performance under a full range of wireless configurations.
4.2 MOTIVATION
There are emergent scenarios for disseminating data from the network using high-speed
radios (e.g., LTE) to the ones with low-speed radios (e.g., ZigBee and Bluetooth). Specif-
ically, personal area network (PAN), e.g., ZigBee and BLE are traditionally believed to
be private and isolated. However, in the era of the internet of things (IoT), there is
an increasing need to push information from the wide-area network (WAN) e.g., LTE
to these isolated PAN devices. For instance, pushing Internet weather forecast to BLE
13
thermostats makes building temperature control more energy efficient. Switching on/off
smart bulbs based on sunset/sunrise times can save the electricity cost for local com-
munities.
CTC can connect these isolated IoT devices to the Internet at a low cost. In specific,
CTC senders emulate the target waveform of the CTC receivers with incompatible PHY
layers, which eliminates the requirement for deploying extra multi-radio gateways. In
this section, we analyze two potential methods to achieve the signal emulation. We
first identify that frequency-domain emulation (FDE) [20] has inherent limitations for
providing reliable CTC between WAN and PAN. After that, we analyze the possibility
of time-domain emulation (TDE) and its unique advantages for reliable communication
in contrast to FDE.
4.2.1 Frequency Domain Emulation
FDE approximates a target waveform from the frequency domain, which is designed for
frequency-domain modulator, i.e., orthogonal frequency division multiplexing (OFDM).
As Fig. 4.1 shows, to emulate a target time-domain waveform, FDE first needs to
convert it into the frequency domain with Fast Fourier Transform (FFT). Then FDE
approximates the FFT results by quantizing them to the nearest predefined discrete
QAM points. Quantization changes the frequency domain components from ideal values,
thus adding quantization error to the emulated signal. The quantization errors in FDE
are non-trivial. Fig.4.1 plots the distribution of FFT results in the constellation with ’x’,
which is extremely dispersed. Hence, some frequency components are significantly far
away from the legitimate QAM points (grey rectangles), leading to severe quantization
errors.
t
I
Q
Ă
Ă
FFT I
Q
Quantize
Target Signal in 
Time Domain
 Emulation in 
Frequency Domain
Figure 4.1: Frequency Domain Signal Emulation.
To reduce the quantization errors, FDE usually requires sender to use high modu-
lation schemes with dense QAM points. Fig.4.2 compares the ZigBee signal emulated
14
by WEBee using different modulation schemes. When reducing the modulation scheme
from 64QAM to QPSK, the number of QAM points available for emulation decreases
from 64 to 4. With fewer available QAM points, the quantization errors are signifi-
cantly increased, causing severe distortion in the emulated signal. Thus, WEBee fixes
transmitter to use 64QAM while it still loses 50% of the CTC packets due to inevitable
quantization error.
0 20 40 60 80 100 120
-2
-1
0
1
2
In
-p
h
a
se
QPSK Emulated Standard
0 20 40 60 80 100 120
-2
-1
0
1
2
In
-p
h
a
se
64QAM Emulated Standard
-2 0 2
-2
0
2
QPSK
-2 0 2
-2
0
2
64QAM
Figure 4.2: FDE-emulated Signal vs. Standard.
The inherent inaccuracy and stringent requirement of high modulation schemes limit
FDE’s applicability. For example, LTE devices only support up to 16QAM in the uplink,
while they cannot set the modulation schemes freely due to the central control of the
base station. Thus, it is still an open and critical question whether WAN technology,
e.g., LTE can emulate low-power IoT waveform with limited resources while achieving
high accuracy.
4.2.2 Time Domain Emulation
Besides FDE, transmitters, e.g., LTE and WiFi may also be capable to emulate IoT
signal directly in the time domain using the time domain emulation (TDE). We observe
that in addition to OFDM which modulates QAM points in the frequency subcarriers,
SC-FDMA in LTE (as we will discuss in Section 4.4) and DSSS/CCK in 802.11 can
transmit a sequence of QAM in the time domain.
The benefit of TDE is obvious. In contrast to the disperse distribution in the
frequency domain, waveforms of IoT transmissions are typically extremely simple in the
time domain. This is because IoT devices are designed for low cost and complexity
15
I
Q
 Emulation in 
Time Domain
Target Signal in 
Time Domain
t
I
Q
Ă
Ă
x1 x2 x3 x4
x1 
x2 x3 
x4 
Figure 4.3: Time Domain Signal Emulation.
and thus the IoT waveforms must be simple enough to be decoded directly in the time
domain with robustness. We take OQPSK waveform depicted in the Fig.4.3 as an
example. The ideal samples in the time domain, i.e., xn are located right at the 4 QAM
points (grey rectangles). Thus, mapping the ideal samples to discrete QAM in the time
domain for the emulation incurs zero quantization errors.
Because of this reason, by using significantly lower modulation schemes, e.g., four
QAM points in QPSK, TDE is able to perfectly track the waveform of the ideal sig-
nal, significantly improving the accuracy of the emulation. Compared to the stringent
requirement for modulation schemes in FDE, TDE can be generically applied to wide
range of settings, which significantly outperforms FDE in the applicability.
This fundamental difference between FDE and TDE inspires us to explore the pos-
sibility of performing TDE on the commodity device, e.g., LTE smartphone for offering
reliable CTC with limited resources, e.g., modulation schemes.
4.3 Overview
This section presents the overview of LTE2B, a transparent time domain emulation
from commodity LTE to both commodity ZigBee and BLE. For the illustration
purpose, our design description focuses on using ZigBee receivers as an example, while
the evaluations of both ZigBee and BLE are introduced in Section 4.6.
.
Fig.4.4 compares the high-level structure of the LTE transmitter and LTE2B. The
LTE transmitter converts source bits to the baseband signal in two steps: (i) source
bits are encoded by channel coding into coded bits for robustness. (ii) These coded
bits are modulated by Single-Carrier Frequency Division Multiple Access modulation
(SC-FDMA) into a LTE baseband signal.
16
Channel Coding
SC-FDMA 
Modulation
Transmission Path Emulation Path
Coded bits
LTE
Signal
Source bits
SC-FDMA 
Emulation
Reverse Channel 
Coding 
Coded bits
Source bits
(i) (ii)
(a)(b)
ZigBee
Signal
Figure 4.4: Architecture of LTE2B.
LTE2B is completely transparent time-domain emulation that is fully compliant with
LTE system, i.e., it takes the emulation path to figure out the source bits which generate
special waveform decodable by ZigBee. Specifically, in Section 4.4 LTE2B emulates the
ZigBee waveform in the time domain for offering accurate emulation. Then in section
4.5, we discuss how to penetrate complicated LTE coding stack to provide desired coded
bits for time-domain signal emulator.
4.4 SC-FDMA EMULATION
In this section, we introduce how LTE2B emulates the ZigBee signal in the time domain,
while being transparent to the SC-FDMA modulation in the LTE stack. Specifically,
we address several challenges, such as mismatched sample rate, time-domain QAM
flip, duration and guarding interval constraints. As a generic method, time-domain
emulation is also applicable to other CTC scenarios (e.g., LTE to BLE and 802.11 CCK
to ZigBee) as evaluated in Section 6, while we focus on the LTE to ZigBee in the section.
4.4.1 Opportunity
Note that LTE2B requires the frequency overlap between LTE and ZigBee/BLE devices.
Although the current 3GPP standards limit LTE to the licensed bands, the recent LTE-
based MulteFire [26], proposes to work at the 2.4 GHz for extending the LTE ecosystem.
Since LTE2B is validated via the current 3GPP specifications and commodity smart-
phones and MulteFire is based on 3GPP specifications, LTE2B can be directly applied
to the emerging MulteFire in the near future for enabling CTC.
In addition, LTE UEs are controlled by the LTE base station at the running time,
17
i.e., the allocated central frequency and the bandwidth are allocated by the LTE base
station. To enable LTE2B, the LTE base station could configure the UEs running
LTE2B specifically for the CTC purpose, while this configuration can be achieved easily
by setting the LTE resource scheduler without violating the 3GPP specifications.
4.4.2 Background: Modulation in LTE
To explain how to enable time-domain emulation in LTE, it is necessary to first introduce
the SC-FDMA modulation in the transmitter of LTE UE (user equipments). Fig.4.5
shows the detailed procedures of SC-FDMA: (i) Coded bits are mapped to a sequence of
time-domain discrete QAM points based on the assigned modulation scheme, typically
QPSK. (ii) The sequence of QAM points are then converted to the frequency domain
using Discrete Fourier Transform (DFT). (iii) Once in the frequency domain, they are
mapped to the desired subcarriers in the overall LTE spectrum. (iv) Finally, to create
the transmitted signal, Inverse Discrete Fourier Transform (IDFT) is performed creating
a time-domain SC-FDMA symbol. As we will further discuss in section 4.4.7, twelve
SC-FDMA symbols will be concatenated with guarding intervals and reference signal
into an uplink subframe.
Constellation 
Mapping
 DFT
Subcarrier 
Mapping
IDFT
Coded 
bits SC-FDMA
Symbol(i)   (ii)          (iii)          (iv)
Figure 4.5: SC-FDMA Modulation.
As the procedure demonstrates, SC-FDMA modulates coded bits into a sequence of
time-domain QAM and transmits them sequentially in a single carrier. This is signif-
icantly distinct from orthogonal frequency division multiplexing (OFDM), where bits
are modulated into a set of QAM points in the frequency domain and transmitted par-
allelly in multiple subcarriers. This unique capability of producing QAM sequence in
time domain enables time-domain signal emulation in LTE.
ADC
I/Q
 samples
 ZigBee
Signal
Chip-Symbol 
Mapping1,-1,-1,1
ChipsO-QPSK
Demodulator
ZigBee
Symbols
Figure 4.6: How a ZigBee Receiver Demodulates.
18
4.4.3 Background: Demodulation in ZigBee
To quantify the accuracy of emulated ZigBee signal, we demonstrate how ZigBee devices
demodulate the OQPSK signal in Fig.4.6. First, the baseband signal is sampled by ADC
using 2MHz sample rate to generate discrete I/Q samples of the ZigBee signal. Second,
OQPSK demodulator decodes chips from I/Q samples.
Last, a set of 32 ZigBee chips are mapped to one of 16 ZigBee symbols by matching
the received chip sequences with the ideal direct-sequence spread spectrum (DSSS)
sequences of each symbol defined in a symbol-to-chip mapping table. Note due to the
inherent redundancy in DSSS, a small number of chips errors due to imperfect emulation
can be tolerated by DSSS.
4.4.4 Emulation Challenges
In Section 2, we demonstrate that a sequence of time-domain QPSK points are able
to perfectly emulate time-domain samples of ideal ZigBee waveform. In addition, our
analysis of the SC-FDMA modulation procedure in section 4.4.2 shows that such QAM
points sequence can indeed be produced by SC-FDMA modulator in the time domain.
As a result, LTE2B is able to emulate the ZigBee waveform in the time domain. How-
ever, the complicated LTE stack imposes several practical constraints and challenges
which must be addressed. Specifically, LTE2B needs to emulate ZigBee signal with
different sample rates (The sample rate is directly decided by the allocated bandwidths
from the LTE base station), as demonstrated in Section 4.4.5. In addition, we need to
solve the unique challenges of using TDE with LTE’s SC-FDMA modulation.
4.4.5 TDE under Misaligned Sample Rates
TDE is able to perform perfect one-to-one mapping in the time domain when ZigBee
and LTE have the same sample rate. However, LTE standard specifies that the sample
rate of LTE uplink must be a multiple of 180 kHz because the granularity of bandwidth
allocation is 180kHz. Since the ZigBee sample rate is 2 MHz, the sample rates of ZigBee
and LTE are misaligned, resulting in inevitable quantization errors in TDE as well. In
this section, we introduce how LTE2B offers generic TDE under misaligned samples
rates, and why TDE is better than FDE.
19
-2 -1 0 1 2
-2
0
2
-2 -1 0 1 2
-2
0
2
Figure 4.7: Sample Distribution: Time vs. Frequency.
-2 -1 0 1 2
0
0.1
0.2
-2 -1 0 1 2
0
0.1
0.2
Figure 4.8: Emulation Error Distribution: TDE vs. FDE.
In Fig.4.7 and Fig.4.8, we study the impact of misaligned sample rate on TDE and
FDE. We demonstrate by emulating the ZigBee waveform sampled at one legitimate LTE
sample rate: 1.8MHz with both QPSK TDE and QPSK FDE. As shown in the left part
of Fig.4.7, due to the misaligned sample rate, the ZigBee samples no longer concentrate
on the four discrete QAM values, i.e., ±1 ± i. Instead, they form four concentrated
clusters closely around the four ideal QAM values. The misaligned sample rates bring
ZigBee samples small and bounded quantization errors when they are mapped to the
closest LTE QAMs in TDE. In comparison, the frequency equivalence of ZigBee samples
shown in the right part of Fig.4.7 keep disperse under the LTE sample rate, making
them hard to be well represented by a limited number of, e.g., four, frequency-domain
QAM points in FDE.
In Fig.4.8, we quantitatively illustrate the quantization errors in “In-phase” when
the normalized signal is emulated by TDE and FDE respectively. We find that the
TDE quantization error is concentrated near 0 and bounded by 0.7, while its FDE
counterpart is far more dispersed and can be as large as 2.2. The comparison in Fig.4.8
clearly shows TDE outperforms FDE in quantization error for the ZigBee waveform
under the mismatched LTE sample rate.
To have a perceptual comparison of the waveform emulated by FDE and TDE, we
depict the ideal and emulated waveforms of ZigBee symbol ‘0’ under 1.8MHz sample rate
in Fig.4.9 as a proof-of-concept example. In each subfigure of Fig.4.9, the ideal ZigBee
20
0 20 40 60
-2
-1
0
1
2
In
-p
h
a
se
TDE ZigBee
0 20 40 60
-2
-1
0
1
2
FDE ZigBee
Figure 4.9: Emulated Signal: TDE vs. FDE.
waveform is with the red dotted line while the emulated one is with the blue concrete
line. We find the TDE emulated waveform better matches the ideal waveform compared
to the FDE emulated one, although the latter shows the correct trend. The waveform
comparison perceptually proves that TDE achieves better emulation than FDE under
misaligned sample rate.
In addition to the waveform comparison, we also evaluate the ZigBee receiver’s
performance with the signal emulated from TDE and FDE. In the experiment, we
emulate the waveform of ZigBee frames consisting of over 100 random ZigBee symbols
with QPSK TDE and QPSK FDE respectively under various valid LTE sample rates
range from 1.08 MHz to 4.5 MHz. We collect the demodulated ZigBee frames and
calculate the average chip errors per ZigBee symbol at the receiver side. From Fig.4.10,
we find the average chip errors of TDE is about 8 out of the 32 chips per ZigBee
symbol under the sample rate of 1.08MHz and dramatically decrease as the sample
rate increases. The chip errors reach zero when the sample rate is over 2MHz, which
is the standard ZigBee sample rate. It shows that TDE can emulate ZigBee waveform
with no chip error under large enough sample rate.
1.08 1.62 1.8 2.16 2.7 3.24 3.6 4.5
LTE Sample Rate (MHz)
0
2
4
6
8
10
A
v
er
a
g
e 
C
h
ip
 E
rr
o
rs
  
  
  
  
 
p
er
 S
y
m
b
o
l
TDE
FDE
Figure 4.10: Chip Errors: TDE vs. FDE.
21
In comparison, the average chip errors per ZigBee symbol are always within the
range of [8, 12] for FDE under the sample rate from 1.08MHz to 4.5 MHz. Considering
that the ZigBee receiver cannot correctly demodulate a ZigBee symbol when the average
chip errors are larger than 6 [27], QPSK FDE fails to emulate decodable ZigBee frames.
From the comparison in Fig. 4.10, we find the performance of FDE does not improve
even with large enough sample rate, which is due to the inherent errors during the
FDE. Surprisingly, when the bandwidth is 1.62 MHz or 1.8 MHz, our TDE is able to
successfully emulate the ZigBee waveform, although the bandwidth is smaller than the
2 MHz ZigBee bandwidth, demonstrating the unique advantages of TDE.
4.4.6 TDE under SC-FDMA
In Section 4.4, we introduce the TDE with misaligned sample rates. Since LTE2B
needs to be fully transparent with existing LTE stack, it has to consider the impacts
of LTE PHY layer. Specifically, to allow multiple LTE user equipments (UE), such as
smartphones, to access the spectrum at the same time, SC-FDMA utilizes “subcarrier
mapping” to shift the signal from the baseband to the target frequency. However,
this frequency shift also modifies the time-domain QAM points used in the emulation
procedure. As a result, LTE2B needs to address this constraint for emulating the target
signal.
0 10 20
(a) SC-FDMA Input
-1
0
1
In
-p
h
a
se
0 10 20
(b) SC-FDMA Output
-1
0
1
Figure 4.11: Emulated Signal in SC-FDMA.
The Phenomenon: Due to the SC-FDMA modulation in LTE, the time-domain sig-
nal before and after this procedure are different, leading to errors in the time domain
emulation. To begin with, we analyze the change of time-domain waveform. Fig.4.11(a)
depicts the emulation of the ZigBee symbol 0 using QPSK. However, after the SC-
FDMA modulation, some QAM points are flipped around the origin, while the other
QAM points remain the same as shown in Fig.4.11(b). As a result, LTE2B needs to
22
address this phenomenon so that its time domain emulation is accurate.
The Solution: To enable time-domain emulation under SC-FDMA, we analyze its
impacts on the signal. Specifically, we compare the time-domain QAM points before and
after the SC-FDMA. With a time-domain QAM point series S0, S1, S2, ...Si, ..., where
i means the index ,we have the following interesting conclusions: (1) the QAM points
with even indices are kept the same; (2) the QAM points with odd indices are flipped
w.r.t. the origin in the constellation. Note that the detailed analysis of SC-FDMA and
the theoretical proof of the interesting phenomenon are in the Appendix.
.
Q
I
Q
I
S0
S1S2
Flip
S0
S2
S1
SC-FDMA
Desired Sequence Sequence w/ QAM Flip
Figure 4.12: QAM point Flip in SC-FDMA.
Take Fig 4.12 as an example. With the original input sequence S0, S1, S2, the SC-
FDMA will change the QAM points with odd indices. Specifically, both S0 and S2 are
kept the same, while S1 is flipped by rotating the QAM point with 180 degrees around
the origin point.
This discovery leads to our key design that solves the problem in the time-domain
emulation. For the targeted time-domain sequence S0, S1, ..., SN−1, LTE2B produces a
sequence S′0, S′1, ..., S′N−1, where S2k = S
′
2k, and S2k+1 = −S′2k+1 (0 ≤ k&k ∈ Z) as
SC-FDMA input. In other words, we flip the samples with odd indices to cancel out
the impacts of SC-FDMA and produce the desired sequence at the output.
SC-FDMA Symbol Guarding Interval DMRS
6 LTE Symbols for ZigBee Embedding
...
 4.7µs
 71.35µs
 16µs
Emulated 
ZigBee Symbols
... ...
Figure 4.13: LTE Uplink Subframe Structure.
23
4.4.7 TDE under Duration Constraints
So far, we have shown that a SC-FDMA symbol can be used to emulate OQPSK signal.
Yet, one single SC-FDMA symbol is still not long enough for one ZigBee frame so
LTE2B embed one ZigBee frame in one LTE subframe which consists of 12 SC-FDMA
symbols. Due to the existence of reference signal (DMRS) and guarding intervals (GI)
in the predefined subframe structure, we cannot control the entire waveform in one
subframe. As shown in Fig.4.13, DMRS are in the 4th and 11th SC-FDMA symbols
and the duration of each DMRS is 71.35µs, which will destroy four ZigBee symbols
(16µs) if the emulated signal tries to cover these regions. Thus in order to maximize
the duration of ZigBee frame, LTE2B embeds the ZigBee waveform in the middle six
LTE symbols. LTE signal in the other six symbols and DMRS are incompatible to
ZigBee and will be naturally ignored by ZigBee receiver. The maximum duration of the
emulated frame is 428.6µs, which can support 26 ZigBee symbols.
Besides DMRS, LTE appends a 4.7µs guarding interval in front of each symbol
to eliminate inter-symbol interference (ISI). GI signal is also out of our control. But
luckily it has a much shorter duration than DMRS and only overlaps with 9 ZigBee
chips. Our empirical study in Section 4.6.3 demonstrates that GI only influences 6 out
of 26 emulated ZigBee symbols with maximum 6 chip errors which are tolerable due to
the redundancy in DSSS.
Finally, other IoT technology, e.g., BLE does not provide the redundancy like ZigBee.
Luckily, due to the lack of redundant code, the duration of BLE frame is also much
shorter. For example, LTE2B can emulate a 16-byte BLE frame of 128us duration
with only 2 LTE symbols. Thus, the emulation of BLE signal avoids DMRS and only
needs to deal with one LTE GI. Since GI is a cyclic copy of the LTE symbol, LTE2B
carefully manipulates the LTE symbol to create the specific signal in GI. Due to the
space limitation, we put the details into the technical report [28].
4.5 Reverse LTE Channel Coding
Section 4.4 shows how LTE2B emulates the target ZigBee signal in the time domain
with given coded bits. However, we are still halfway to success, because LTE2B are
designed to emulate ZigBee signal purely based on the payload in IP packets (i.e., via
24
         Payload
A CRCCRC Attach
Turbo Coding
Interleaving 
MAC
PHY
ZigBee Embedding
(i)
(ii)
(iii)
   
Coded bits
LTE 
Subframe
Hdr
Source bits
H
E
Figure 4.14: Channel Coding Data Flow.
socket programming). Thus, given desired code bits, we need to penetrate multiple LTE
channel coding layers, as shown in Fig.4.14, reversely and figure out the right payload.
4.5.1 Background: LTE Channel Coding
To explain the reverse engineering process in detail, we need first introduce the extremely
complicated channel coding scheme in LTE. In Fig.4.14, we illustrate three main steps
in LTE channel coding: CRC attachment, turbo coding, and interleaving. Note that
although the real LTE channel coding is much more complex and may repeat each step
multiple times, our discussion about how to reverse engineer each channel coding step
still satisfies. The functionality of the three steps are as follows.
(i) CRC attachment: CRC parity bits are calculated from the source bits, denoted
as code block A, which contains the entire IP packet including the headers. The CRC
parity bits are then appended to the trailer of code block A.
(ii) Turbo coding: Code block A and its appended CRC code block are then encoded
by a turbo encoder into code block E, which contains the whole input bits, i.e., code
block A and CRC, as well as some redundant bits generated by the turbo coding.
(iii) Interleaving: Finally, bits in the code block E will go through a complex
interleaving process, including the rate matching, concatenation, and permutation as
detailed in [29]. The output code block H is coded bits which are modulated into the
LTE subframe shown in Fig.4.14, where the middle six SC-FDMA symbols are used to
emulate ZigBee frames..
25
4.5.2 Challenges in Reversing Turbo Coding
The reverse of channel coding includes reversing both the interleaving process and the
turbo coding. The former is fully reversible because interleaving by definition does not
insert or remove data bits but only reorder them. The reverse of turbo coding, however,
is much more complicated.
=
×GF(2) 
A
(unknown)
CRC
E
(known)
Turbo Coding Matrix
GM
N
N-24
24
M
1 1
Figure 4.15: Turbo Coding Matrix
We find the procedures of turbo coding can be represented via matrix multiplications
in Galois field GF(2) because turbo coding involves only linear operations, as illustrated
in Fig.4.15. In the figure, the matrix G is an M × N (typically 7200 × 10680) coding
matrix derived from the turbo encoder utilized in LTE, E is an M × 1 output matrix
of turbo coding, and A is an (N − 24)× 1 matrix containing (N − 24) LTE source bits
followed by 24 CRC parity bits. Our goal is to find the unknown code block A from the
coded block E. However, we observe two phenomena that make the task challenging.
0 50 100 150 200 250 300
Number of Coded bits Affected
0
5
10
15
20
25
C
R
C
 b
it
 i
n
d
e
x
Figure 4.16: Non-negligible Impacts of CRC on Coded Bits.
(i) Simple solution does not work: The simple solution of matrix inverse, i.e.,[
A CRC
]T
= inv(G)×GF (2)E does not work, because the CRC bits are uncontrollable.
In other words, we can only control block A instead of
[
A CRC
]T
for the CRC block
26
is determined following the LTE standard. It is a constraint that LTE2B must satisfy
to be fully compliant to the LTE standard.
(ii) Impact of CRC bits is non-negligible: One may expect we can simply ignore
the 24-bit CRC, for its length is relatively small compared to the source bits N or the
coded bits M , so its impact on the coded bits may be limited. It is true for some coding
schemes, such as the convolutional code widely used in WiFi, where each CRC bit will
affect only several (typically < 10) coded bits [30]. However, in the turbo code, the
impact of each CRC bit spreads to the whole coded bits due to turbo code’s internal
feedback mechanism [29]. In Fig.4.16, we illustrate the impact of each CRC bit on the
final coded bits. In the figure, the Y -axis is the index of the 24 CRC bits, while the
X-axis is the number of coded bits each CRC bit will affect. We find that although
there are only 24 CRC bits, one CRC bit may affect up to 250 coded bits, leading to
significant TDE error if we do not deal with them carefully.
CRC=
CRC Matrix
R
A
(unknown)
24
N - 24
N - 24
1
1
24×GF(2) 
Figure 4.17: Computation of CRC Bits.
4.5.3 Reverse Turbo Coding
To tackle the uncontrollable CRC issue, we have to formulate the CRC and use that as
a constraint when calculating code block A. We find the calculation of CRC from the
source bits, i.e., code block A, can also be expressed as the matrix multiplication. As
shown in Fig. 4.17, R is a 24 × (N − 24) matrix indicating the LTE CRC calculation
operations. We substitute CRC in Fig. 4.15 with this formula:
(G×GF (2)
[
IN−24 RT
]T
)×GF (2) A = E, (4.1)
where IN−24 is an identity matrix. With this equation, LTE2B is able to compute the
code block A with any wanted coded bits E while satisfying the CRC constraints.
We also notice that solving a large system of equations is time-consuming. To
provide real-time performance, LTE2B computes the specific inverse matrixes offline.
27
The inverse matrix is only required to be calculated once while online calculation only
involves matrix multiplication which requires significantly less computation.
LTE2B (Commodity)
Nexus 5X
(UE)
LTE (USRP)
OAI eNodeB
CC2530
ZigBee (Commodity)
BLE (Commodity)
CC1350
Figure 4.18: Experiment Setting for LTE2B
4.6 PERFORMANCE EVALUATION
This section presents the implementation and evaluation of LTE2B over commodity
devices.
4.6.1 System Implementation
LTE2B sender has been implemented on a commodity LTE smartphone LG Nexus
5X. Since LTE2B works completely in the application layer and only uses socket system
calls, it is compliant with any LTE UEs with any chipsets. Specifically, LTE2B computes
its LTE packet payload with the target IoT signal at the application layer, and then
transmits the packet following the whole LTE stack.
Implementation of LTE2B in the application layer is extremely challenging because
source bits in the turbo coding will not only contain IP payload but also various types of
protocol headers, e.g, TCP/IP. Similar to CRC, these protocol headers have a non-trivial
impact on the decoded bits. Since we cannot control these coded bits via modifying the
IP payload, LTE2B leverages the segmentation feature [31] to eliminate protocol header
bits in the source bits.
In specific, when the size of the source bits is larger than the capacity of a single
28
subframe, LTE encoder will segment them into two partitions, which are then indi-
vidually encoded and modulated into subframes. Thus, in order to create a subframe
without upper layer protocol headers, LTE2B generate IP payload with large enough
size such that the headers and the source bits for TDE will be separated into different
partitions and modulated into different subframe. In this way, LTE2B is enable to fully
control the coded bits of a subframe from the application layer and generate desired
TDE waveform that can be demodulated by commodity ZigBee and BLE devices. Due
to the space limitation, we omit other implementation details, which can be found in
our website [28].
4.6.2 Evaluation Setting
Fig.4.18 illustrates the evaluation settings of LTE2B. LTE2B sender is commodity LTE
smartphone LG Nexus 5X. The receivers we use are commodity ZigBee CC2530 and
commodity BLE CC1350. In the experiment, Nexus 5X connects to a base station
running Openairinterface(OAI) LTE base station [32]. We deploy the open-source LTE
base station in order to control the carrier frequency of LTE devices. Specifically, the
base station operates on LTE band 7 with 2505MHz central frequency and 10MHz
bandwidth. Commodity ZigBee and BLE devices are tuned to 2503MHz which overlaps
with LTE spectrum, which can be done by configuring the “FREQCTRL” register in
software without modifying the hardware. Note that the emerging LTE-based Multe-
Fire will operate at 2.4 GHz unlicensed band and also follow the 3GPP specifications,
enabling LTE2B to work directly between MulteFire and ZigBee/BLE. However, due
to the lack of MulteFire equipment, we conduct the experiments on commodity LTE
smartphones in 2.5 GHz as a proof of concept.
The results provided are based on QPSK modulation schemes and 2.16MHz band-
width if there is no extra explanation. We note that TDE’s emulation performance
increases with higher modulation schemes (less quantization error), while we evaluate
QPSK as the bottom line for our design. The evaluations start with the detailed mea-
surements of LTE2B’s performance in PHY layers (i.e., chip error rate and symbol error
rate). Then link-layer experiments (i.e., frame reception ratio) are conducted under
a wide range of settings including indoor/outdoor, Line-of-Sight(LOS)/None-Line-of-
Sight(NLOS), mobile and low duty cycle. Each experiment is repeated 10 times. Each
29
time, 10000 LTE2B frames are sent and the statistical results are obtained.
To demonstrate the generality of TDE, we also evaluate TDE with other technolo-
gies, e.g., WiFi and BLE in Section 4.6.9 and 4.6.10.
0 2 4 6
Hamming Distance
0
20
40
60
80
100
P
ro
b
a
b
il
it
y
(%
)
TDE
(a)
8 10 12 14
Hamming Distance
0
20
40
60
80
100
P
ro
b
a
b
il
it
y
(%
)
FDE
(b)
Figure 4.19: Hamming Distance (a) TDE (b) FDE.
4.6.3 Chip Error Rate
Chip is the basic unit in ZigBee demodulation. ZigBee receiver collects 32 ZigBee chips
and maps them to the nearest ZigBee symbol with minimum chip errors in Hamming
distance. To examine the accuracy of the time-domain signal emulation, we emulate
random ZigBee frames with both LTE2B (TDE-QPSK) and WEBee (FDE-QPSK) and
collect chip errors in the received ZigBee symbols. We use Nexus 5X as LTE2B trans-
mitter and USRP B210 as WEBee transmitter. The received signal strength at ZigBee
side is fixed to -72dBm. As depicted in Fig.4.19(a), 80% symbols have no chip errors
while the rest have tolerable chip errors caused by guarding intervals (GI). While one
GI overlaps with 9 chips, our empirical study shows it only flip at most 6 chips, which
can be corrected by DSSS. In contrast, as shown by Fig.4.19(b), FDE causes signifi-
cantly more chip errors. Symbols emulated by FDE may suffer from 14 chip errors,
which definitely lead to demodulation failure. In order to improve the accuracy of emu-
lation and produce demodulatable ZigBee signal, WEBee fix the modulation scheme of
WiFi to 64QAM. In contrast, LTE2B works well under any modulation schemes that
LTE supports and is well suitable for LTE system where the modulation schemes are
dynamically controlled by the base station.
This gives us an interesting insight that emulating OQPSK signal defined in time
domain directly via QAM samples that are also in time-domain can yield significantly
30
fewer emulation errors than approximating the converted frequency domain version of
the signal using frequency-domain QAM.
-78 -82 -87 -92 -97 -99
RSSI(dBm)
0
10
20
30
40
50
S
E
R
(%
)
All symbols
ED
-99
A l sy bols
-78 -82 -87 -92 -97 -99
RSSI(dBm)
0
10
20
30
40
50
S
E
R
(%
)
GI-polluted
GI-free
ED
Figure 4.20: Symbol Error Ratio (a) All symbols (b) GI-polluted vs. GI-free Symbols.
4.6.4 Symbol Error Rate
In ZigBee, one symbol error leads to CRC check failure and thus failure of the whole
packet. Hence symbol error rate (SER) is an important criterion of the accuracy of
signal emulation. We collect the SER of ZigBee frames emulated by LTE2B in a wide
range of received signal strengths (RSSI). Fig.4.20(a) demonstrates that LTE2B achieves
nearly zero SER when RSSI is as low as -92dBm. SER begins to increase when RSSI
goes below -92dBm, which coincides with the increase of error rate for those symbols
overlapped with guarding interval as shown in Fig.4.20(b). In contrast, SER of GI-free
symbols remains stable, which again demonstrate the stability of TDE. As the positions
of GI are fixed, the application of LTE2B may optionally forbid the usage of these
vulnerable symbols or adopt coding technology to reduce the frame errors. In contrast,
the majority of symbols in FDE-QPSK emulated ZigBee frame have more than eight
chip errors even in the high RSSI (-72dBm) as demonstrate in Fig.4.19(b). Thus most
of them fail to be demodulated at ZigBee receiver.
4.6.5 Frame Reception Rate
The section evaluates the performance of the frame reception rate (FRR) by conducting
experiments with LTE2B, WEBee and standard ZigBee under varied settings. One
frame is considered lost if any received symbol is wrong.
31
Impact of RSSI (vs. FDE & Standard ZigBee)
Fig.4.21 compares the frame reception rate of LTE2B frames, WEBee frames and the
standard ZigBee frames under the same RSSI. Since FDE introduces high quantization
errors, it is not feasible for emulating ZigBee signal with QPSK modulation. Instead,
WEBee frames are generated with FDE-64QAM, a much higher modulation scheme than
QPSK with dense QAM points for reducing the quantization errors. It is clear that when
RSSI is above -92dBm, LTE2B achieves the same performance as the standard ZigBee.
The FRR of both LTE2B and standard ZigBee drops at -92dBm. LTE2B’s FRR drops
faster mainly due to the increasing failures in GI-polluted symbols discussed in section
4.6.4. In the extremely low SNR (i.e, -99dBm), ZigBee receiver can still receive 25% of
LTE2B frames. In contrast, even with 64QAM, the FRR of WEBee drops dramatically
when RSSI is below -80dBm. This result demonstrates that TDE is inherently more
reliable than FDE when emulating the IoT signal.
-78 -82 -87 -92 -97 -99
RSSI(dBm)
0
20
40
60
80
100
F
R
R
(%
)
LTE2B
WEBee
(64QAM)
ZigBee
Figure 4.21: FRR vs. RSSI.
0.4 0.6 0.8 1
Duration(ms)
0
20
40
60
80
100
F
R
R
(%
)
-62dBm
-72dBm
-82dBm
-92dBm
Figure 4.22: FRR vs. Duration.
Impact of Frame Duration
In the previous experiment, we fix the duration of frames to be 0.42ms, which is the
maximum length achievable for the emulated signal in commodity LTE UE. To further
evaluate the performance of our time-domain emulation method, we use MATLAB
LTE System toolbox [33] to generate emulated ZigBee signal with various lengths and
transmit via USRP. As Fig. 4.22 shows, the impact of frame length on the FRR is
almost negligible when signal strength is high. When the receive signal strength is low
(≤ −92dBm), increasing frame duration shows more impact on frame errors, which is
clearly because the longer frame overlaps with more guarding intervals.
32
4.6.6 LTE2B Performance: Indoor and Outdoor
In this section, we evaluate LTE2B in various real-life scenarios. The transmission
power of LTE UE is about 16dBm. Note that this 16dBm is legitimate in LTE stan-
dards, while the maximum allowed power for UE is 23dBm. Also, 16dBm conforms
to FCC’s requirement on transmission power in the unlicensed band (typically 30dBm)
and complies with ZigBee or BLE standard.
ZigBee 
(CC2530)
LTE UE
(Nexus 5X)
Base 
Station
Figure 4.23: Hallway
LTE UE
(Nexus 5X)
Base 
Station
ZigBee 
(CC2530)
Figure 4.24: Library
We first compare the indoor performance of LTE2B with WEBee in two settings,
i.e., hallway (LOS, depicted in Fig.4.23) and library (NLOS, depicted in Fig.4.24). For
a fair comparison, the transmission power of WEBee is also configured to be 16dBm.
Fig.4.25 demonstrates that in all the distances, LTE2B achieves above 97% FRR. Thus,
with one LTE device, we can control all IoT devices equipped with low power ZigBee
on a large scale. We also notice that the indoor FRR of LTE2B is significantly higher
than WEBee [20] (50%) while the LTE2B uses much lower modulation schemes than
WEBee. This demonstrates the benefit of TDE in both applicability and reliability.
10 20 30 40 50
Distance(m)
30
40
50
60
70
80
90
100
F
R
R
(%
)
LTE2B
WEBee
10 20 30 40 50
Distance(m)
30
40
50
60
70
80
90
100
F
R
R
(%
)
LTE2B
WEBee
(a) (b)
Figure 4.25: Indoor FRR (a) Hallway (b) Library.
33
One key advantage of LTE2B is long distance (supporting outdoor applications in
the scale). So we extensively evaluate the gain of communication range from LTE2B in
the outdoor environment by comparing it with a commodity ZigBee transmitter with
1dBm maximum transmission power. Fig.4.26 depicts the outlook of the experiment
scenario, which is a 1340-foot long bridge. For a fair comparison, we fix both the CC2530
transmitter and LTE UE at the one end of the bridge, while moving ZigBee receiver to
the other end. The FRR experiments are tested every 15 meters.
LTE UE 
(Nexus 5X)
Base 
Station
ZigBee 
(CC2530)
Figure 4.26: Outdoor Experiment Site
Fig.4.27 demonstrates the frame reception ratio for both standard ZigBee commu-
nication from CC2530 and LTE2B at different distances. It is clear that the standard
ZigBee has limited transmission distance: the maximum communication range is 120m.
In contrast, LTE2B is able to deliver the ZigBee message to a much longer distance.
For example, LTE2B achieves an FRR of 94% at a distance of 180m, while it still man-
ages to maintain 52% FRR at 400m. This huge distance discrepancy demonstrates that
LTE2B can cover IoT sensors in large scale in one hop. This unique benefit removes
the requirement of relay nodes in the ZigBee network, which significantly reduces the
hardware cost, and maintenance cost. In addition, LTE2B also removes the bottleneck
problem on the relay nodes, improving the overall system life time.
0 100 200 300 400
Distance (m)
0
20
40
60
80
100
F
R
R
 (
%
)
Standard ZigBee
LTE2B
Figure 4.27: FRR vs. Distances
34
4.6.7 Repeated Transmission
Because of the accurate signal emulation, LTE2B works extremely reliably in the indoor
scenarios and outdoor scenarios when the communication distance is less than 180m. To
further support reliable communication for longer distance, e.g., 400m, we can transmit
LTE2B frame multiple times for improving the overall reliability. Fig.4.28 shows the
frame reception ratio of LTE2B frame with varying number of transmission at the
4 different distances, from 250 m to 400 m. Specifically, LTE2B can achieve 99%
frame reception rate via repeating the frame 3 times for 300m and 4 times for 400m,
demonstrating the reliable communication of LTE2B. In addition to the transmission
distance, we also study the performance of retransmission for frames with different
durations. In this experiment, the transmission distance between the sender and receiver
is fixed to 400m, while LTE2B transmits frames from 0.4 ms to 1 ms. From Fig.4.29, we
can see repeated transmission performs similarly for these 4 frame durations, suggesting
that LTE2B’s robust performance.
1 2 3 4 5
#trans
0
20
40
60
80
100
F
R
R
(%
)
distance = 250m
distance = 300m
distance = 350m
distance = 400m
Figure 4.28: FRR vs. Tx Distance (re-
transmission)
5
distance = 250m
distance = 300m
distance = 350m
distance = 400m
1 2 3 4 5
#trans
0
20
40
60
80
100
F
R
R
(%
)
duration = 0.4ms
duration = 0.6ms
duration = 0.8ms
duration = 1ms
Figure 4.29: FRR vs. Frame Duration
(retransmission)
4.6.8 LTE2B Performance: Mobility
LTE2B is designed to work with the mobile applications. For example, with LTE2B
ambulances equipped with in-vehicle LTE can directly control the ZigBee traffic lights.
In this experiment, we test mobility performance LTE2B with different moving speeds:
walking (4mph), bicycling (10mph) and driving (30mph). Moreover, the ZigBee receiver
performs low power listening with varying duty cycle ratios, e.g., the ZigBee turn off
the wireless radio periodically for preserving energy, while one LTE2B frame is repeated
35
50 times from the smartphone. In Fig.4.30, we demonstrate that when the user walk
or bicycle, 5% duty cycle ratio is enough to guarantee reliable message delivery from
LTE2B to ZigBee sensors at low power mode. Even in the driving scenarios with the
moving speed of 30 mph, LTE2B achieves reliable communication with only 10% duty
cycle ratio. This series of experiments demonstrate the reliability of TDE in LTE2B,
and the potential deployment of LTE2B for emerging mobile IoT applications, e.g.,
smart city and autonomous driving.
2 4 6 8 10 12 14 16
Duty Cycle Ratio (%)
60
70
80
90
100
F
R
R
(%
)
walk(4mph)
bicycle(10mph)
drive(30mph)
Walk
Bicycle
Drive
Figure 4.30: FRR in Mobility and Duty Cycle
4.6.9 LTE2B in Bluetooth Low Energy
In addition to the emulation of OQPSK ZigBee signal, we also implement LTE2B to
enable the CTC from LTE to Bluetooth Low Energy (BLE) following the TDE described
in Section 4. This emulation of Gaussian frequency shift keying (GFSK) waveform
demonstrates that the TDE is generic and can be generally applied to various scenarios
for enabling CTC. Note that although existing commodity smartphones generally adopt
BLE transceivers, LTE transceivers with the higher transmission power (23dBm) can
significantly improve the coverage of BLE signal, which will come in handy in the
applications such as advertising, neighbor discovery and control, while commodity BLE
receivers generally have limited transmission energy. In addition, the emerging LTE-
based Multefire devices in the 2.4 GHz band may not be equipped with BLE transceivers
[25], while LTE2B enables direct communication among them.
In Fig.4.31, we demonstrate the emulated GFSK waveform of BLE and frame recep-
tion ratio of a 14 Bytes BLE advertisement frame. BLE does not provide redundancy
mechanism (e.g., DSSS) and thus any bit error will lead to packet corruption. Due to
36
0 50 100
Index
-1
0
1
In
-p
h
a
se
LTE2B BLE
-72 -77 -82 -87 -92
RSSI(dBm)
0
50
100
F
R
R
(%
)
CRC Fail
CRC Pass
(a) (b)
Figure 4.31: LTE2B in BLE (a) Emulation (b) FRR.
the simplicity of GFSK in the time domain, TDE is able to emulate it accurately. Thus,
with high RSSI, i.e., above -77 dBm, LTE2B is able to achieve 100% FRR, while still
offering good reliability in low RSSI conditions.
2 4 6 8 10
Distance(m)
40
60
80
100
F
R
R
(%
)
WiFi TDE
WEBee(FDE)
2 4 6 8 10
Distance(m)
40
60
80
100
F
R
R
(%
)
WiFi TDE
WEBee(FDE)
(a) (b)
Figure 4.32: FRR WiFi TDE vs FDE (a) ZigBee (b) BLE.
4.6.10 Time-Domain Emulation in WiFi
Time-domain emulation is a generic method that can be applied to other technology,
i.e., WiFi. Besides OFDM modulation for FDE, commodity WiFi devices also support
DSSS/CCK modulation that can be utilized for TDE. Due to the space limitation,
we omit the implementation details and demonstrate the performance with CC3200
commodity WiFi in this section. In Fig. 4.32, we compare the frame reception ratio
of emulated ZigBee and BLE signal using TDE (802.11 QPSK-CCK) and FDE (802.11
64QAM). In both cases, TDE significantly outperforms FDE even if the modulation
scheme, i.e., QPSK is much lower. This further proofs that TDE is a generic technique
that dramatically improve the accuracy of CTC.
4.6.11 Application
In this section, we implement LTE2B to control the color and intensity of a ZigBee-
equipped light bulb for demonstrating its potential benefits. When receiving the ZigBee
control messages from users, the ZigBee sensor adjusts the light bulb to a specific color
37
and light intensity. To enable CTC, LTE2B is running as an Android application in the
application layer, and receives the user commands for computing the payload in the UDP
packet used for emulation. Following Section 4.4 and Section 4.5, LTE2B computes the
needed LTE payload for any ZigBee control messages, and then transmit this packet for
emulating the ZigBee waveform. Our experiments validate that LTE2B achieves reliable
control of the lighting condition of the smart bulb in real-time, suggesting that LTE2B
can be directly applied to emerging IoT applications.
LTE 
smartphone
ZigBee 
Controlled 
Light
LTE Base Station
Figure 4.33: Light Control Application of LTE2B
4.7 Summary
This chapter presents LTE2B, the first work that bridges the WAN technology (e.g.,
LTE) with PAN technology (e.g., ZigBee and BLE). In contrast with frequency-domain
CTC approaches with high errors, LTE2B comes up with time-domain emulation for
offering reliable CTC even with limited modulation schemes such as QPSK. To realize
time-domain emulation in the LTE system, LTE2B tackles several practical challenges
so that it is completely compliant with existing standards and has been implemented
in commercial COTS devices (e.g., LG Nexus 5X) with > 99% accuracy over a long
distance (e.g., 400m). We also demonstrate the feasibility of using the IP payload via
a commercial smartphone to control and configure a commodity ZigBee-enabled light
bulb.
Chapter 5
Signal Hitchhiking
5.1 Introduction
This chapter presents cross-technology communication (CTC) from low-speed radios
(e.g., ZigBee, Bluetooth, and LoRa) to high-speed radios (e.g., Wi-Fi). The proposed
technique can inspire many useful applications. One the most promising application is
enabling mobile devices (e.g., smartphones) to directly collect data from incompatible
IoT devices (e.g., ZigBee sensors, LoRa smart meters, and wireless baby monitors).
More specifically, people desire to use their mobile devices to interact with the diverse
IoT devices, manage IoT data, and conduct data fusion operations. However, due to the
constraints in the size and complexity, mobile devices are manufactured with limited
types of wireless radios such as WiFi and Bluetooth, which inhibits them from directly
collect data from heterogeneous IoT devices.
CTC can alleviate this issue by extending the pervasively available radio in mobile
devices, i.e., WiFi, to support heterogeneous IoT techniques in the overlapping ISM
spectrum. By doing this, we envision that with a moderate software upgrade, mobile
devices can collect data from various types of heterogeneous IoT devices directly, which
paves the way for a lot of novel IoT applications.
However, communications from low-speed IoT radio to WiFi are technically chal-
lenging due to their distinct physical layers. The signal emulation discussed in Chapter
4, i.e., manipulating high-speed WiFi radio to emulate low-speed ZigBee signal is not
applicable because IoT radios generally have very limited capabilities - it is impossible
38
39
for a ZigBee radio with a 2 MHz bandwidth to produce a 20 MHz WiFi signal.
To address this problem, there are a few previous attempts [23, 24]. Yet, they are
fundamentally limited in compatibility and generality. Specifically, they need to modify
the WiFi demodulation procedure for customized decoding of raw IoT signal, making
them incompatible with billions of existing commodity WiFi radio in the smartphone.
In addition, they are inherently restricted to only support ZigBee without serving other
IoT techniques that are being increasingly diversified.
We propose XFi - the first design that achieves data collection from diverse low-
speed IoT devices using commodity WiFi radio with only a software upgrade. The
basic idea is signal hitchhiking - when a smartphone is receiving a WiFi packet from
an AP, IoT devices transmit simultaneously, leading to intentional collisions with the
WiFi packet in the air. In this way, low-speed IoT data hitchhikes on the high-speed
WiFi packet and enters the WiFi radio of the smartphone.
The most critical question XFi needs to address is how to obtain the IoT data
hitchhiking on the received WiFi packet. With our goal of serving diverse IoT techniques
with distinct physical layers in minds, XFi proposes a general approach: reconstruct
and decode, i.e., 1) reconstruct the I/Q waveform of hitchhiking IoT data and then 2)
decode the reconstructed IoT waveform. Although the idea sounds straightforward, it is
extremely challenging to accomplish in a commodity WiFi device with only a software
upgrade. In particular, commodity WiFi hardware does not expose raw I/Q data to
the software - It only returns the decoded WiFi payload after WiFi demodulation. To
reliably retrieve IoT data from the decoded payload, XFi has to tackle several critical
challenges imposed by WiFi demodulation procedures.
• Waveform Reconstruction: Commodity WiFi receiver applies forward error cor-
rection (FEC) algorithm to correct errors incurred by wireless interference. Con-
sequently, the hitchhiking IoT signal could be considered by FEC as interference
and eliminated amid error correction, rendering it challenging to reconstruct IoT
waveform from the decoded WiFi payload. Counter-intuitively, we observe that
IoT waveform is retained even after error correction, so that XFi manages to
reconstruct a large portion of IoT waveform from the decoded payload.
• Robust Decoding: Commodity WiFi receiver discards informationless segments
40
of WiFi signal (e.g., guard intervals between WiFi symbols). Thus, IoT signal
hitchhiking on these discarded segments cannot be recreated in the reconstructed
waveform. To cope with the challenge and reliably obtain IoT data, we enhance
IoT decoders, which provides them robustness against discarded waveform.
Importantly, our proposed methods are generally applicable to various types of IoT
techniques, which is essential for our motivation for supporting diversified IoT devices.
We demonstrate the applicability to two representative IoT techniques using highly dis-
tinct physical layers: ZigBee and LoRa while they can be extended to other techniques.
In summary, our intellectual contributions are as follows:
• XFi is the first cross-technology communication design from low-speed radios to
commodity high-speed radios. It enables direct data collection from diverse IoT
techniques with a commodity WiFi radio.
• Our design simultaneously features generality to various IoT techniques and com-
patibility with commodity WiFi hardware. To achieve this, XFi obtains IoT data
only using decoded payload while tackling critical challenges, e.g., waveform con-
struction and robust decoding.
• We implement XFi on COTS WiFi devices (e.g., RTL8812au) and evaluate XFi
across various scenarios. The results demonstrate that XFi can concurrently re-
ceive 2 streams of ZigBee or 8 streams of LoRa with 97% accuracy while reaching
a throughput of 1.8 Mbps.
5.2 MOTIVATION
This section presents the motivation of cross-technology IoT data collection using com-
modity WiFi radio in a smartphone.
Deficiency of IoT Support in Smartphone: Internet of Things (IoT) has been
widely deployed, where a large number of heterogeneous IoT devices are generating
more than 500 zettabytes IoT data per year [34]. A natural way for people to interact
with these ubiquitous IoT devices is through their mobile devices (e.g., smartphones),
which brings several unique benefits. For example, a smartphone can provide a friendly
41
user interface for visualizing and managing IoT data, while the powerful computing
capability of the smartphone also offers an ideal platform for analyzing heterogeneous
IoT data through sensor fusion and machine learning operations.
The challenge, however, is that wireless techniques adopted in IoT devices are in-
creasingly diversified while our mobile device is constrained to provide limited options of
wireless techniques. For instance, environmental sensors are commonly equipped with
ZigBee, while smart meters could adopt LoRa. There are also a large number of IoT
devices (e.g., health wearable and baby monitors [35]) that use proprietary wireless pro-
tocols. In contrast, restricted by the size and complexity, a smartphone is only equipped
with radios such as WiFi, while cramming additional IoT interfaces (e.g., ZigBee) into
smartphones [36] has been proved commercially inviable.
Conventionally, a smartphone has to indirectly access the data in heterogeneous IoT
devices via extra IoT gateways [37]. However, the dedicated gateway incurs additional
hardware cost, deployment complexity, and administration burden, which prevents it
from being ubiquitously deployed. In addition, an IoT gateway with a specific wireless
radio cannot serve other emerging IoT techniques. As a result, there is an emergent
need for a low-cost and general method for the heterogeneous IoT data collection on
mobile devices.
Cross-technology Data Collection via Commodity WiFi: We propose to
directly collect data from heterogeneous IoT devices with commodity WiFi radio avail-
able in every smartphone. With a moderate software upgrade, smartphones can access
diversified IoT devices without extra gateways.
Although direct communications from heterogeneous IoT radio to WiFi have been
studied in recent works [23, 24], they commonly work on physical layers requiring a
redesign of WiFi decoder. Therefore, they are incompatible with commodity WiFi
hardware in mobile devices. Furthermore, their designs are tightly coupled with unique
features of ZigBee signal, which cannot be generalized to other types of IoT techniques
that are increasingly diversified.
In XFi, we simultaneously address the challenges in both compatibility and gener-
ality, enabling mobile devices to obtain IoT data of various heterogeneous techniques
using only the decoded WiFi payload that is accessible from WiFi software.
42
:L)L$3
'HFRGHG:L)L3D\ORDG
=LJ%HHIUDPHV
/RUDIUDPHV
6PDUWSKRQH6HUYHU
;)L6RIWZDUH
:DYHIRUP
5HFRQVWUXFWLRQ
=LJ%HH
'HFRGHU
/RUD
'HFRGHU
D;)L6FHQDULR
E;)L6RIWZDUH$UFKLWHFWXUH
Figure 5.1: (a) XFi Enables a WiFi Smartphone to Collect Data from Heterogeneous
IoT Devices. (b) XFi Analyzes the Decoded WiFi Payload to Obtain ZigBee or LoRa
Data.
5.3 XFi in a Nutshell
Overview. XFi enables a commodity WiFi radio in mobile devices to collect data
from diversified narrowband IoT devices (e.g., ZigBee and LoRa1) with only a software
upgrade. The high-level idea is signal hitchhiking demonstrated in Fig.5.1(a): a mobile
device downloads a standard WiFi data packet from the associated WiFi AP. When the
WiFi packet is being delivered by AP, IoT devices send data in the overlapped spectrum
such that low-speed IoT data can hitchhike on the high-speed WiFi packet in the air
and enter the WiFi radio of the mobile device. In the rest of chapter, we will refer
to ZigBee or LoRa radios as “IoT devices” and ZigBee or LoRa data frames as “IoT
frames”.
Applicable scenarios. XFi is applicable in a wide range of scenarios since WiFi
APs have been ubiquitously deployed for Internet service. For example, over 79% US
households get WiFi at home [38] while there are 432 million public APs worldwide [39].
Additionally, XFi is also possible to be applied in mobile scenarios without WiFi APs. It
is an increasingly common situation that people carry more than one mobile device. For
instance, 60 million US people are using smartwatches in addition to smartphones [40],
which can serve as WiFi transmitters with only a software upgrade.
1Note that while LoRa initially operates on the sub-GHz band, 2.4GHz LoRa transceivers (e.g.,
SX1280/SX1281) have been deployed since 2017.
43
System architecture. The critical component of the system is XFi software in-
stalled in mobile devices. As depicted in Fig.5.1(b), it is able to obtain the hitchhiking
IoT data without accessing raw I/Q signal. Specifically, XFi software only uses the
decoded WiFi payload returned by commodity WiFi hardware as the input. To retrieve
IoT data, it first reconstructs IoT waveform by analyzing the decoded WiFi payload
(Section section 5.5) and then reliably decodes the reconstructed IoT waveform with
our enhanced IoT decoders (Section section 5.6).
XFi has three unique features:
• Compatibility: XFi retrieves heterogeneous IoT data only via the decoded pay-
load available in WiFi software. Therefore, it is fully compatible with commodity
WiFi devices and does not require any hardware modification.
• Generality: XFi manages to reconstruct raw RF waveform of hitchhiking IoT
data regardless of the wireless technique it uses. This capability makes XFi gener-
ally applicable to various IoT protocols that coexist with WiFi on ISM band. We
demonstrate the generality with two popular techniques (i.e., ZigBee and LoRa)
with highly different physical layers.
• Efficiency: XFi allows the wide-band WiFi receiver to concurrently receive and
decode multiple heterogeneous narrowband IoT transmissions, significantly im-
proving the network efficiency of densely-deployed IoT devices. Taking Fig.5.1(a)
for example, XFi is able to simultaneously decode the transmissions from two
ZigBee devices and four LoRa devices allocated at different channels.
5.4 Background and Challenges
This section introduces the background of commodity WiFi receiver and then analyzes
the challenges of obtaining IoT data under the constraints of WiFi demodulation pro-
cedures.
5.4.1 Background
In Fig. 5.2, we illustrate how the WiFi receiver works. (i) Preamble detection searches
the predefined training signal, i.e., WiFi preamble in the received 20 MHz signal. If
44
Premeable 
Detection
CP
Removal
FFT
QAM
Demapping
Channel 
Decoding
t[n] t’[n] f[n]
20MHz Signal
Coded Bits
Decoded Bits
(i) (ii) (iii)
(v) (vi)
Figure 5.2: Demodulation Procedures in WiFi Receiver.
the preamble is detected, WiFi receiver conducts the following OFDM demodulation
procedures. Otherwise, the signal is rejected. (ii) For a signal t[n] that passes pream-
ble detection, the cyclic prefix (CP), i.e., the 0.8us at the beginning of each 4us WiFi
symbol is removed because it is an “informationless” guarding interval between WiFi
symbols for eliminating the inter-symbol interference. (iii) The surviving time-domain
waveform t′[n] is transformed into the frequency domain by Fast Fourier Transform
(FFT). Each WiFi symbol is transformed into 64 frequency components that corre-
spond to 64 WiFi subcarriers over 20 MHz WiFi spectrum. (v) The QAM demapping
discretizes the continuous-value frequency components into bits. Then bits on all the
subcarriers are serialized to a sequence of coded bits (or a codeword). (vi) The channel
decoder corrects errors in coded bits using forward error correction (FEC) algorithm
and produces decoded bits that are available in WiFi software. Note The corrupted
decoded bits with CRC check failure by default are dropped by low-level WiFi software
for efficiency. However, we can intentionally access these data by editing the filter in
the driver.
5.4.2 Challenges
The top of Fig.5.3 shows signal hitchhiking where the input signal to WiFi receiver is 20
MHz WiFi signal with one or more narrowband IoT frames that hitchhike on it. Since
XFi is compatible with commodity WiFi hardware, the mixed signal is demodulated
through the WiFi decoding pipeline, i.e., (i)-(vi) in Fig. 5.2, which produces the decoded
bits. Our objective is to use these decoded bits to reconstruct IoT waveform and then
decode the waveform to obtain IoT data. To achieve this, XFi has to address several
challenges in a top-down order.
• Waveform Reconstruction. Channel decoder adopts forward error correction
45
(FEC) to protect WiFi transmissions against interference. Presumably, FEC consid-
ers hitchhiking IoT signal as interference and attempts to eliminate it in the decoded
output. Specifically, in the step (vi), the channel decoder performs error correction to
recover collision-free WiFi data, which may prevent the reconstruction of IoT waveform
using the decoded bits. In Section section 5.5, our in-depth look into the channel decod-
ing algorithm reveals a counter-intuitive phenomenon that IoT waveform can survive
channel decoding because it creates an excessive number of errors.
• Robust Decoding. While a large portion of IoT waveform can be reconstructed
from the decoded payload, there are still a lot of waveform segments erased amid WiFi
demodulation. For example, CP removal in the step (ii) erases the IoT waveform hitch-
hiking on the cyclic prefix, causing problems to IoT decoders. To reliably decode the
partially reconstructed waveform, Section section 5.6 enhances decoder’s robustness
against signal erasure by leveraging a unique signal erasure pattern.
•Other Challenges. XFi has to address other practical challenges. For example, WiFi
receiver only decodes after receiving WiFi preamble. For signal hitchhiking, IoT devices
need to know when to transmit in order to be simultaneous with WiFi transmitter, which
is discussed in Section section 5.7.
))7
W¶>Q@
=LJ%HH
:L)L6SHFWUXP0+]

I>Q@
 
/RUD6XEFDUULHUV

=LJ%HH6XEFDUULHUV 2WKHU:L)L6XEFDUULHUV
 
/RUD
Figure 5.3: FFT of WiFi Signal with Hitchhiking IoT Data.
5.5 Waveform Reconstruction
This section presents the design to reconstruct the raw waveform of hitchhiking IoT
data from decoded WiFi payload.
46
5.5.1 Channel Decoding and Error Correction
As an OFDM receiver, a commodity WiFi receiver converts the time-domain signal into
the frequency domain via FFT, so that it can demodulate the received data at each
subcarrier. Fig.5.3 demonstrates that each narrowband IoT signal interferes with the
WiFi data in the specific subcarriers. For example, ZigBee signal disturbs subcarrier
13 to 20, while LoRa signal disturbs subcarrier 6 to 9. So ideally, XFi can examine the
changes of values on the corresponding subcarriers to reconstruct each hitchhiking IoT
signal.
However, channel decoder performs error correction (FEC) on the received data to
get rid of narrowband interference, which could potentially recover the original value
on the subcarriers and eliminate hitchhiking IoT signal. In Fig. 5.4, we use a toy
example to illustrate the error correction of Low Density Parity Check (LDPC) decoder
in WiFi. Specifically, the received data on the subcarriers are first mapped to coded
bits consisting of “data bits” (d0, d1, d2) and “parity bits” (p0, p1, p3). The hitchhiking
ZigBee signal disturbs the data bit d1 such that d1 is changed to an incorrect value: 0.
While we desire to infer the IoT data from such errors, FEC comes in to detect
and correct them. As the top of Fig. 5.4 shows, data bits d1, d2, and parity bits p1
are connected to a common parity check constraint for error detection. The binary
parity check fails since the summation in gf(2), i.e., d1 ⊕ d2 ⊕ p1 6= 0. Similarly, the
other two parity checks that d1 is associated with also fail. Therefore, the parity checks
come to a consensus that d1 is incorrect, so LDPC decoder might flip d1 for the parity
check constraints to be satisfied. If this happens, error correction might unfortunately
eliminate the influence of ZigBee waveform in the coded bits.
1 0 0 0 1 0Coded bits
Parity Check
Disturbed by ZigBee 
Parity bitData bit
d0 d1 d2 p0 p1 p2
Figure 5.4: Error Correction in LDPC Decoder.
It is noteworthy that the real coded bits in WiFi are much longer than the example
(typically 1944) with the 324 parity checks. Thus, the decoder needs to repeat the
47
procedure above multiple times for the coded bits to converge. Finally, WiFi versions
targeted by the chapter include 802.11n/ax/ac, which are supported in majority of
commodity mobile devices.
5.5.2 Feasibility of Waveform Reconstruction
Counter-intuitively, we observe that LDPC decoder almost keeps the corrupted coded
bits intact. In specific, when coded bits are severely disturbed by heterogeneous IoT
signal, channel decoder only flips an extremely limited number of “coded bits” (≤ 2%).
Our key insight for this phenomenon is that the channel decoding algorithm has an
Error Correction Capability. When received coded bits have errors that exceed the
algorithm’s capacity, parity checks fail to reach a consensus and the decoder becomes
ineffective in correcting errors.
0.2 0.8 1 1.5 2 2.5 3 5 8 10 15 30 50 80 100
Bit Error Ratio(%)
0
20
40
60
80
100
Flipped
Not Flipped
Figure 5.5: Error Correction (Flip) Ratio vs. Bit Error Ratio.
In the section, we demonstrate this observation with an empirical experiment while
the theoretical proof is given in the Appendix. Specifically, we first generate a valid
WiFi codeword and then purposely inject varying ratios of bit errors into the codeword
such that it gradually moves away from the correct value. We use LDPC decoder to
decode each modified WiFi codeword and calculate the percentage of errors that are
corrected (flipped) to examine the effectiveness of LDPC decoder under different bit
error ratios.
The result in Fig. 5.5 shows that LDPC decoder is able to perform with a small bit
error ratio (e.g., 1.5%), while it becomes ineffective and only flips 1.8% bits when the bit
error ratio exceeds 5%. The interference created by hitchhiking IoT signal (e.g., ZigBee
and LoRa) is sufficient to make LDPC decoder ineffective. For example, ZigBee has a 2
MHz bandwidth, which is equivalent to 15% of bit errors, while LoRa with a 0.8 MHz
48
bandwidth incurs around 7% of bit errors. Consequently, channel decoder preserves IoT
signal hitchhiking on each subcarrier, so that XFi can reconstruct the IoT waveform by
elaborately analyzing decoded bits. Since these decoded bits are available in software,
our design can be compatible with commodity WiFi hardware.
Coded bit Reconstructor
Decode bits  e.g., 010101111
Subcarrier Mapper 
Coded bits 010101111xxx
IFFT IFFT
6     9 13            20 
LoRa 
Decoder
ZigBee
Decoder
LoRa 
Decoder
...
Waveform
Reconstruction
(§5)
Enhanced IoT
Decoder (§6)
IFFT...
...
Figure 5.6: XFi Architecture.
5.5.3 Waveform Reconstruction Algorithm
In this section, we present the details of reconstructing IoT waveform with decoded bits.
As Fig.5.6 demonstrates, waveform reconstruction is a general module that recreates
IoT signal of various techniques in the separated channels by analyzing the decoded
bits returned to WiFi software. The reconstructed IoT waveforms are then demodulated
using the enhanced IoT decoders to obtain IoT data, which we will discuss in section 5.6.
Specifically, XFi first approximates coded bits with decoded bits. As discussed in
section 5.5.2, channel decoder becomes ineffective due to the excessive interference from
IoT signal, so decoded bits provide a close approximation of coded bits. Second, coded
bits are mapped to frequency domain, i.e, subcarriers. Finally, each individual IoT signal
resides in the separated narrowband, so XFi aggregates the changes of values on the
corresponding subcarriers and then performs inverse fast fourier transform (IFFT) to
reconstruct IoT waveform. For example, when a ZigBee frame is at the frequency range
from −4 MHz to −6 MHz w.r.t the center frequency of WiFi, XFi aggregates the value
changes on 13th to 20th subcarriers and performs IFFT to compute the time-domain
ZigBee waveform.
49
Note that decoded bits do not contain the parity bits which are dropped by WiFi
receiver as we will further discuss in section 5.6.1. In Fig.5.6, we mark unknown parity
bits as “x” when approximating coded bits and the corresponding IoT waveform cannot
be reconstructed. We tackle the challenge in section 5.6.
5.6 Robust Decoding
Waveform construction effectively recovers a large portion of IoT waveform. Yet, there
are still a lot of waveform segments that are erased amid WiFi demodulation, imposing
challenges to obtaining the hitchhiking IoT data. This section first analyzes two major
sources of signal erasure (i.e., Parity and CP). Then we introduce our enhanced IoT
decoders that provide robustness against signal erasure in the software.
Coded bits (after error correction) Decoded bits
Parity 
Removal
ParityData bits5/6 1/6 5/6
Lost
Figure 5.7: Parity Removal Erasures IoT waveform.
5.6.1 Signal Erasure
Parity Removal
As we mention in section 5.5.1, LDPC decoder takes the data bits and parity bits as
input, and then tries to correct errors in data bits with parity bits. After that, it discards
the parity bits and only passes data bits to the software.
Although we observe that the error correction has negligible impacts, the removal of
parity bits inevitably leads to signal erasure because parity bits also contain IoT signal.
As Fig. 5.7 depicts, when the coding rate of LDPC is 56 ,
1
6 of coded bits are parity bits.
Consequently, 16 of IoT signal is erased and cannot be accessed by XFi via decoded bits.
CP Removal
Besides parity removal, CP removal also incurs signal erasure. As depicted in Fig.
5.8(a), for each WiFi symbol with a duration of 4us, WiFi receiver drops the guarding
signal in the first 0.8us, which is called cyclic prefix (CP). In a standard WiFi symbol,
50
4us
Identical
WiFi Symbol
Non-WiFi 
Waveform
CP(0.8us)
Not Identical
CP
Lost
No Loss
CP 
Removal
CP 
Removal
(a)
(b)
Figure 5.8: (a) CP Removal of WiFi Symbol. (b) CP Removal of IoT Waveform Erasures
IoT waveform.
the transmitted waveform at CP is identical to the last 0.8us of a symbol, suggesting
that the WiFi receiver will not lose any information for removing CP. In contrast, due
to heterogeneity between wireless protocols, non-WiFi signal (e.g., ZigBee) does not
have this CP feature, as we demonstrate in Fig.5.8(b). As a result, when WiFi receiver
removes “CP” in IoT signal every 4us, a segment of 0.8us IoT signal is lost, imposing
challenges for obtaining IoT data.
Data bits Parity bits 
0.8us 3.2us
 CP Removal Parity Removal
4us
24us
Reconstructed
Figure 5.9: Overall Pattern of Signal Erasure.
Summary of Signal Erasure Pattern
The overall signal erasure pattern is illustrated in Fig.5.9 where 13 of IoT waveforms are
erased by WiFi hardware. The erased waveform partitions are marked by red ‘x’, which
can not be accessed from decoded bits. Specifically, In every 24us, XFi suffers from
the one 3.2us signal erasure due to parity removal. In addition, XFi also suffers from
0.8us signal erasure due to CP removal every 4us. These two factors are the dominating
waveform loss in XFi, while XFi also suffers from the quantization error when QAM
demapping discretizes subcarriers and the bit flippings (< 1.8%) during error correction
(section 5.5.2). Our evaluation (section 6.9) shows both quantization and bit flippings
have limited impacts and do not lead to decoding errors.
51
To reliably decode the reconstructed waveform with signal erasure, XFi customizes
the IoT decoder to incorporate the signal erasure pattern with the symbol-level (sec-
tion 5.6.2) and chip-level (section 5.6.3) redundancy of IoT signal. To make our de-
scription concrete, our discussion focuses on ZigBee while the idea generally applies to
other techniques (e.g., LoRa). In section 6.9, we provide evaluation results for both
techniques.
5.6.2 Combat Signal Erasure: Symbol-level
ZigBee symbols contain redundant information for the protection against interference
In the section, we combine the signal erasure pattern observed in section 5.6.1 with this
redundancy to offer ZigBee decoder robustness against signal erasure. Note that symbol-
level redundancy is widely provided by various IoT techniques, e.g., LoRa spreads sym-
bols into chirps. Although our description focuses on ZigBee, this idea is applicable to
other IoT protocols.
ZigBee Symbol
ZigBee adopts direct sequence spread spectrum (DSSS) which spreads each ZigBee
symbol (4 bits) into 32 binary chips following the DSSS table (Table 1). This inherent
redundancy introduced by DSSS helps XFi to decode partially reconstructed ZigBee
signal, as discussed later. In a standard ZigBee receiver, a set of 32 ZigBee chips
are then mapped to a ZigBee symbol by comparing the hamming distances between
the demodulated chip sequence and the 16 standard DSSS sequences in Table 1. The
symbol with the smallest hamming distance is selected.
Symbol (4 bits) Chip Sequence (32 bits)
0 0 0 0 11011001110000110101001000101110
0 0 0 1 11101101100111000011010100100010
... ...
1 1 1 1 11001001011000000111011110111000
Table 5.1: Symbol-to-chip Mapping in ZigBee (802.15.4)
52
Erasure-Aware Symbol Decoding
As analyzed in section 5.6.1, the reconstructed IoT waveform suffers from the signal
erasure in specific sections, i.e., CP and parity. This knowledge motivates us to design
an erasure-aware DSSS decoding algorithm adapted to the unique signal erasure pattern.
x1011001x1000011x1010010xxxxxxxxReceived DSSS 
CP Data Bits Parity Bits
11011001110000110101001000101110Standard DSSS 
Hamming Distance          =        0
xor
Blacklist
Figure 5.10: Decoding ZigBee Symbol with Blacklist.
In specific, XFi can use the signal erasure pattern to identify which ZigBee chips
are undetermined and thus cannot be trusted in DSSS decoding. Therefore, when XFi
calculates the hamming distance, it blacklists these undetermined chips, and only utilizes
the remaining chips for improving symbol decoding reliability. As Fig.5.10 shows, XFi
blacklists the chips which are missing due to CP removal and parity removal, while
it only relies on the chips that can be reconstructed from data bits. In this example,
the chip sequence has the smallest hamming distance to ZigBee symbol 0, and is thus
decoded as symbol 0. By doing this, XFi offers the decoder robustness to missing chips.
Note that this procedure is after the detection of ZigBee preamble, which is discussed
in section 5.7.1.
5.6.3 Combat Signal Erasure: Chip-level
In addition to symbol-level redundancy, XFi explores the resilience in ZigBee chip to
enhance the decoder’s robustness.
ZigBee Chip
ZigBee chips are modulated by offset quadrature phase-shift keying (OQPSK) where
each ZigBee chip is encoded by a 0.5us phase shift. Specifically, as Fig.5.11(a) depicts,
chip 1s are modulated by positive phase shifts (pi2 ) while chip 0s are represented by
negative phase shifts (−pi2 ). The standard OQPSK demodulator uniformly samples the
signal every 0.5us (e.g., S1 and S2) and calculates phase shifts between samples.
53
S1
S2
I
Q
I
Q
(a) Standard ZigBee Samples (b) CP-aware ZigBee Samples
1S¢
2S¢
Erased by 
CP removal
Figure 5.11: ZigBee Chip. (a) Uniform Samples of Standard ZigBee Chip. (b) Erasure-
aware Samples of Partially Reconstructed ZigBee Chip.
Erasure-aware Chip Demodulation
ZigBee chips may partially suffer from signal erasure as the dashed line in Fig.5.11(b)
indicates. To decode these chips, XFi introduces the erasure-aware chip decoding by
elaborately benefiting from the feature of ZigBee chip. Specifically, in one chip, the phase
is monotonically increasing or decreasing, so the sign of phase shift can be calculated by
any two distinct samples. Therefore, as Fig.5.11(b) shows, instead of sampling uniformly
in 2 MHz, XFi carefully chooses the two samples, i.e., S′1 and S′2 in the reconstructed
waveform to avoid the signal erasure.
5.7 Practical Signal Hitchhiking
Section section 5.5 and section 5.6 demonstrate the feasibility of decoding IoT signal,
when it collides into an ongoing WiFi frame. This section further discusses two addi-
tional issues for realizing XFi in practical scenarios. Specifically, section 5.7.1 introduces
how to notify IoT devices, so that they could utilize the signal hitchhiking opportunity.
In section 5.7.2, we discuss the design of WiFi payload that maximizes the signal hitch-
hiking reliability.
5.7.1 Coordination
To achieve signal hitchhiking, IoT devices must send data to a WiFi device when the
WiFi device is receiving an ongoing frame from WiFi AP. Interestingly, such coordina-
tion can be achieved by the WiFi frame itself. More specifically, we elaborately select
54
WiFi AP
WiFi Device
TX
RX
Rx TX
WiFi Preamble Cross-tech Polling Carrier of IoT Frames
t0 t1 t2t2+∆t t3
t0 t1 t2 t3
ZigBee/LoRa
Figure 5.12: The downlink WiFi frame from AP consists of a cross-technology polling
notification to IoT devices (t1 − t2) and a carrier of IoT signal (t2 − t3).
the WiFi payload such that the corresponding WiFi frame delivered by AP can simulta-
neously accomplish 3 critical goals: (1) polls IoT devices to send data, (2) carriers IoT
data into WiFi receiver, and (3) allocates IoT devices to distinct channels for avoiding
collisions.
The WiFi frame structure and the complete signal hitchhiking procedures are demon-
strated in Fig.5.12. First, as a legitimate WiFi frame, the frame starts with WiFi
preamble at t0. Upon the detection of the preamble, the WiFi radio begins receiving
and decoding, which provides an opportunity to capture the IoT signal. Second, the
segment of WiFi payload from t1 to t2 notifies the IoT devices of the opportunity of sig-
nal hitchhiking. In specific, XFi adopts WiFi→IoT CTC techniques recently proposed
in [20] to embed a legitimate ZigBee or LoRa packet in the WiFi frame that contains
a list of IoT devices to be queried and their allocated channels. After receiving the
notification, IoT devices tune the transmitter to the allocated channel, temporarily dis-
able collision-avoid mechanism (e.g., CSMA), and then start transmissions at t2 + ∆t.
Narrowband IoT frames collide with the rest part of the WiFi frame, which carries them
into the WiFi device.
Note that the WiFi frame and IoT frames do not need to be strictly synchronized,
as Fig.5.12 depicts. XFi reconstructs the complete narrowband signal from t2 to t3,
which is then match-filtered with the predefined ZigBee or LoRa preamble to detect the
beginning of IoT frames (i.e., t2 + ∆t).
55
:L)L6XEFDUULHU,QGH[
         
'&3LORW
=LJ%HH/RRD
f
0+]0+]0+]0+]0+]0+]
Figure 5.13: Power Spectrum and Channel Allocation.
5.7.2 Power Control
An issue arises immediately: High energy of WiFi can saturate the WiFi subcarriers,
leading to the corruption of IoT frames. To address the problem, XFi introduces a
power control mechanism - by elaborately selecting the WiFi payload, we can minimize
the WiFi energy on specific subcarriers. In particular, XFi carefully chooses the payload
that produces WiFi signal from t2 to t3 in Fig.5.12, so that the subcarriers capturing IoT
signal take minimal values. By doing this, XFi effectively minimizes the WiFi energy
at the frequency ranges where IoT frames hitchhike. Fig.5.13 depicts the visual power
spectrum density, where blue indicates low energy and yellow refers to high energy.
Obviously, several narrowbands with visibly lower energy than other subcarriers (e.g.,
pilots) are produced, thus improving the IoT signal’s signal-to-noise ratio.
With the power control, XFi utilizes WiFi spectrum with extremely high efficiency.
As the top of Fig.5.13 shows, we create two continuous 4 MHz channels and four 2 MHz
channels that can pack 2 ZigBee frames or 8 LoRa frames. Besides, XFi carefully allo-
cates guarding bands between channels to mitigate the interferences between channels.
The evaluation demonstrates that the power control mechanism effectively carries IoT
data over WiFi transmission.
5.8 limitation and discussion
Implementation of XFi on smartphones. XFi works in WiFi software, so it is
compatible with commodity WiFi hardware in smartphones, requiring only a moderate
driver upgrade. As a proof of concept, we prototype and evaluate XFi with commodity
WiFi NIC in a Linux PC because it is convenient to patch Linux open-source WiFi
56
drivers and obtain corrupted WiFi frames. WiFi drivers of smartphone are close-source
and need be patched with special patch tools (e.g., NexMon [41]), which is left to future
works.
Limitation of communication Range: XFi cannot support long range commu-
nications with IoT devices, which is because XFi can reconstruct IoT signals only when
the signal is strong enough to corrupt WiFi packets. For long ranges, IoT signals can-
not significantly interfere with WiFi packets due to the limited transmission power of
low-power IoT transmitters and uncertainty of the channel. As a result, IoT signals will
be eliminated by error correction of LDPC decoder.
Generalization of XFi. The proposed approach in XFi generally applies to other
IoT techniques. To extend XFi to another technique, one can directly adopt signal
hitchhiking and waveform reconstruction to capture and reconstruct its waveform while
replacing the decoder (Section section 5.6) to one specific to target technique. Addi-
tionally, it is possible to extend XFi to scenarios in other frequency bands, e.g., com-
munication among WiFi 802.11ah and sub-GHz IoT devices.
XFi overhead. XFi introduces little overhead to WiFi and IoT network. Due to
WiFi’s collision avoidance mechanism, i.e., CSMA, other WiFi traffic will back off when
IoT frames are in transmission. Besides, XFi allows parallel data collection from multi-
ple IoT devices to make efficient use of WiFi’s wide spectrum. Finally, our coordination
design in Section section 5.7 is compatible with the receiver-initiated ZigBee and LoRa
protocol (e.g., [42]), so IoT devices can perform duty cycle to minimize the overhead of
idle listening.
5.9 performance evaluation
This section evaluates XFi on commodity IoT and WiFi devices across various scenarios
for demonstrating the reliability, efficiency, and generality of XFi.
5.9.1 Evaluation Setup
We prototype XFi on the commercial off-the-shelf WiFi and IoT devices. The evaluation
settings are depicted in Fig.5.14. To demonstrate XFi’s compatibility, we evaluated it
on Ubuntu 16.04 PC with three representative WiFi chipsets from different brands:
57
CC2650
SX1280
RTL8812au
RTL8812auA6210 AR9380
ZigBee (COTS)
LoRa (COTS)
WiFi AP (COTS)
WiFi Device (COTS)
Figure 5.14: Experimental Setting for XFi.
Mediatek A6210, Realtek RTL8812au, and Atheros AR9380. WiFi devices operate on
channel 3 (2422 MHz). ZigBee performance is evaluated with CC2650 ZigBee SoC [43].
We develop ZigBee program using TI-RTOS SDK. Finally, LoRa is evaluated with
SX1280 SoC [44] running default PINGPONG example.
The evaluation starts with the overall performance of XFi. Then the detailed mea-
surements of physical layers (i.e., ZigBee chip error rate and symbol error rate) are
provided, followed by the link-layer experiments (i.e., frame reception ratio). To demon-
strate the generality of XFi, we also evaluate it on LoRa. Each experiment is repeated 10
times, while 10000 frames are received and the statistical results are obtained. Without
further explanation, the distance between WiFi transmitter and receiver is 5 meters and
the transmitter adopts 64 QAM modulation, 5/6 coding rate, and 15 dBm transmission
power. The distance between IoT devices and WiFi receiver varies from 2 meters to 15
meters, while the transmission power of IoT devices is 0 dBm.
Table 5.2: Summary of XFi Performance.
Commodity ZigBee LoRa
XFi Yes 285.7 Kbps 1.8 Mbps
Lego-Fi [24] No 213 Kbps Not Support
SymBee [23] No 31.25 Kbps Not Support
ZiFi [45] Yes 215.9 bps Not Support
5.9.2 Overall Performance
As we demonstrate in Table 5.2, XFi is the first IoT→WiFi communication design that
simultaneously features 1) compatibility with commodity WiFi hardware, 2) generality
to various IoT technologies, and 3) high throughput. Specifically, XFi obtains IoT data
58
entirely from decoded WiFi payload, whereas the state-of-the-art designs (e.g., Lego-
Fi [24]) require raw signal, which is incompatible with commodity devices. Additionally,
in contrast to previous works that are specific to ZigBee, XFi is first to be generally ap-
plicable to several distinct wireless techniques (e.g., LoRa), which is extremely beneficial
since IoT techniques are increasingly diversified.
With the capability of retrieving the legitimate payload data of multiple IoT frames
in parallel, XFi achieves a maximum throughput of 285.7 Kbps for ZigBee and 1.8 Mbps
for LoRa. The throughput of XFi significantly outperforms SymBee [23] and ZigFi [45]
which rely on coarse-grained information of signal (e.g., correlation and CSI). Note that
the latest WiFi standard (i.e., IEEE 802.11ax) provides 160 MHz bandwidth, which
allows XFi to supports 16 parallel ZigBee devices and potentially improves the overall
throughput by 8 times.
0 50 100 150 200 250 300
-2
0
2
Recovered By XFi
0 50 100 150 200 250 300
-2
0
2
Standard ZigBee
Figure 5.15: Reconstructed ZigBee vs. Standard ZigBee.
5.9.3 PHY Layer Performance
XFi introduces waveform reconstruction (Section section 5.5) to recover raw IoT wave-
forms from decoded WiFi payload. To evaluate the accuracy, we compare the recon-
structed ZigBee signal with the standard one. As Fig.5.15 illustrates, the narrowband
signal recovered by XFi approximates the standard one well for the most of the time
except those signal erased by the WiFi receiver amid CP removal and parity removal.
We quantify the accuracy of the reconstructed waveform by examining the demod-
ulated chips. In this experiment, two ZigBee devices transmit on parallel channels in
Fig.5.13, while the distance between ZigBee transmitters and WiFi receiver is 2 meters.
The distributions of chip errors are depicted in the Fig.5.16. Over 90% of symbols have
less than 3 chips errors, which can be tolerated by DSSS. In addition, these two streams
59
0 1 2 3 4 5 6 7 8 9 10
Hamming Distance
0
5
10
15
20
25
30
35
40
P
ro
b
a
b
il
it
y
(%
)
ZigBee#1
0 1 2 3 4 5 6 7 8 9 10
Hamming Distance
0
5
10
15
20
25
30
35
40
P
ro
b
a
b
il
it
y
(%
)
ZigBee#2
(a) CER: ZigBee Channel 1       (b) CER: ZigBee Channel 2
Figure 5.16: Chip Error Distribution in ZigBee Symbols.
of Zigbee signal demonstrate similar chip error distribution, showing that XFi can ob-
tain multiple ZigBee transmissions from WiFi payload and independently decode them
in parallel.
2 4 8 10 15
Distances(m)
0
5
10
15
20
25
30
S
E
R
(%
)
w/ backlist
w/o backlist
2 4 8 10 15
Distances(m)
0
5
10
15
20
25
30
S
E
R
(%
)
w/ backlist
w/o backlist
(a) SER: ZigBee Channel 1         (b) SER: ZigBee Channel 2
Figure 5.17: Symbol Error Ratio vs. Distances.
5.9.4 Symbol Error Rate
This section evaluates the symbol error rate (SER) of ZigBee. To demonstrate the
performance gain from our enhancements to the IoT decoder, we compare the symbol
error ratios to the ones without our blacklist design (Section (section 5.6.2). Fig.5.17
demonstrates that blacklisting undetermined chips can significantly improve the decod-
ing accuracy. For example, in the first channel, it reduces the SER from 12% to 0.61%
at 2 meters while it keeps the SER under 5% at 15 meters, which dramatically enhances
the robustness of the decoder.
5.9.5 Frame Reception Rate
We evaluate ZigBee frame reception ratios (FRR) in two sites: laboratory room and
corridor. Fig.5.18 plots the average FRR of ZigBee frames with 4 symbols in varying
distances. In the noisy lab environment, FRR drops slowly to 75% when increasing
60
2 4 6 8
Distance(m)
40
60
80
F
R
R
(%
)
2 4 6 8 10
Distance(m)
40
60
80
F
R
R
(%
)
D )55/DE5RRP E )55&RUULGRU
Figure 5.18: Frame Reception Ratio vs. Distances.
distances from 2 to 8 meters, while in the corridor XFi achieves more than 70% FRR
at a distance of 10 meters.
To further improve the reliability, we transmit ZigBee frames with 4/7 Reed-Solomon
(RS) Code. As demonstrated in Fig.5.19, XFi achieves ≥ 97% FRR in varying sites and
distances after the RS code is adopted, showing that XFi can reliably collect data from
heterogeneous IoT devices.
2 4 6 8
Distance(m)
90
95
100
F
R
R
(%
)
2 4 6 8 10
Distance(m)
90
95
100
F
R
R
(%
)
(a) FRR w/ Coding (Lab)      (b) FRR w/ Coding (Corridor)
Figure 5.19: Frame Reception Ratio with RS code.
5.9.6 XFi:LoRa
XFi also enables WiFi radio to receive 8 parallel LoRa frames. Note that LoRa uses
chirp spread spectrum (CSS) in the physical layer, which is dramatically different from
the physical layer of ZigBee, demonstrating that XFi is applicable to various types of
IoT techniques. In Fig.5.20, we depict the spectrum of reconstructed LoRa waveform
where LoRa chirps can be identified visibly, which shows the generality of waveform
reconstruction to diverse physical layers.
Preamble SFD Payload
Figure 5.20: Spectrum of Reconstructed LoRa Waveform.
61
Fig.5.21(a) shows symbol error ratios (SER) of LoRa in various settings. XFi
achieves low error ratio (< 0.5%) within 15 meters. We observe that LoRa signals
with a smaller bandwidth are most robust because a longer symbol duration provides
more resilience to signal erasure. When the range is further increased, the communica-
tions become less reliable. For example, at 25 meters, we receive a lot of WiFi frames
containing no errors from which we can reconstruct IoT signal. As we discussed in Sec-
tion 6.7, IoT radios are limited in signal strength and thus cannot corrupt WiFi frames
at a long range. The ranges of XFi are comparable to previous designs such as ZigFi (15
meters), Lego-Fi (20 meters), and SymBee (25 meters). Note that LegoFi and SymBee
are implemented on software-defined radios, whereas XFi completely uses commodity
WiFi radios. Finally, as Fig.5.21(b) plots, XFi offers similar reliability and throughput
for 8 parallel LoRa channels, significantly improving the spectrum efficiency when LoRa
devices are densely deployed.
3 6 9 12 15
Distance(m)
0
0.2
0.4
S
E
R
(%
)
1625K
812K
406K
203K
1 2 3 4 5 6 7 8 
LoRa Channel
0
200
400
D
a
ta
 R
a
te
(K
b
p
s) 1625K
812K
406K
203K
D 6(5YV'LVWDQFH E 7KURXJKSXWYV&KDQQHO
Figure 5.21: LoRa Performance (Spreading Factor = 5).
5.10 Discussion
In XFi, narrowband IoT devices can upload data to the WiFi AP when a WiFi device is
sending to the WiFi AP. So XFi requires two WiFi devices in presence. This is because
although WiFi device is receiving all the time, the WiFi decoder will start decode
frame decode only when it receive WiFi preamble, i.e., LTS, STS and SIGNAL field.
It is common to have two WiFi devices in one site since WiFi has been widely used.
For example, in home scenario, there are typically multiple WiFi devices: WiFi AP,
smartphone, laptop and smart personal assistant, e.g., Amazon echo. With XFi, WiFi
devices are able to upload data with in parallel ZigBee and BLE which significantly
improve the spectrum efficiency of WiFi devices. In addition, XFi works completely in
62
the application of both transmitter and receiver. Thus, neither hardware nor firmware
need to be modified in WiFi devices while XFi only needs the installation of an APP
that can receive XFi request and upload data with specific contents discussed in the
section 5.7.2.
5.11 Summary
This chapter proposes XFi, the first work that achieves cross-technology data collec-
tion using commodity WiFi hardware. The signal hitchhiking and recovery methods
introduced can be generically applicable for CTC from low-speed to high-speed radios.
APPENDIX
This section theoretically proves our observation in the section 5.5.2 that LDPC decoder
is ineffective when decoding hitchhiking IoT signal that incurs excessive bit errors.
Proof. The proof is based on sum-product algorithm [46], which is commonly used
in LDPC decoder for its high efficiency. Sum-product calculates the a posteriori log-
likelihood ratio (LLR) Li for each bit i as defined in Equation 5.1 where bit i is decided
to be one when Li ≤ 0 and zero when Li ≥ 0.
Li = log
p(xi = 0)
p(xi = 1)
= ri +
∑
j∈Ai
Ej,i (5.1)
Li is the sum of ri (the initial LLR from the input) and Ej,i (the extrinsic LLR from
the jth parity check to bit i). Since a bit is flipped when the sum of extrinsic LLRs is
large enough so that the initial LLR (ri) and a posteriori LLR (Li) take different signs,
the probability of flip (Pe) can be expressed as a conditional probability in Equation
5.2. The decoder is ineffective if Pe is extremely small for any bit.
Pe = P (Li ≤ 0|ri ≥ 0) = P (Li ≥ 1|ri ≤ 1) (5.2)
As Equation 5.3 shows, the initial LLR ri only depends on the received value of bit
i denoted as xˆi, where the crossover probability p is prior knowledge of the decoder.
63
ri = log
P (xi = 0)
P (xi = 1)
=
log
p
1−p xˆi = 1
log 1−pp xˆi = 0
(5.3)
Since ri ≥ 0 is equivalent to xˆi = 0 and vice versa, Pe in Equation 5.2 can be deduced
into Equation 5.4.
Pe = P (ri +
∑
j∈Ai
Ej,i ≤ 0|xˆi = 0)
= P (
∑
j∈Ai
Ej,i < log
p
1− p)
(5.4)
log p1−p is constant, so the calculation of Pe is reduced to find the distribution of∑
j∈Ai Ej,i. As Equation 5.5 shows, each extrinsic LLR Ej,i is computed from all bits
associated with jth parity check except for bit i (denoted as bit i′), where pi′ = P (xi′ =
1) is the probability that the true value of bit i′ is one.
Ej,i = log(
1
2 +
1
2
∏
i′∈Bj ,i′ 6=i(1− 2pi′)
1
2 − 12
∏
i′∈Bj ,i′ 6=i(1− 2pi′)
) (5.5)
Our key insight is that coded bits in severely corrupted WiFi payload are almost
uncorrelated from each other, meaning that p′is are i.i.d random variables that take value
either p or 1−p with 12 probability. Therefore, Ej,i is simply a discrete random variable
shown in Equation 5.6, where e is a constant calculated as e = log(
1
2
+ 1
2
∏
i′∈Bj,i′ 6=i(1−2p)
1
2
− 1
2
∏
i′∈Bj,i′ 6=i(1−2p)
).
f(Ej,i) =

1
2 Ej,i = e
1
2 Ej,i = −e
(5.6)
Importantly, e  log p1−p . Typically, p = 0.9 and log p1−p = 2.2, while e is less
than 0.001. Since corrupted coded bits are highly uncorrelated, Ej,is are approximately
independent of each other and can also be modeled as i.i.d. Thus, the sum of extrinsic
LLR is very unlikely to be large enough to flip the sign of LLR. When p = 0.9, Pe ≈ 0.1%.
Note that the experiment shows a slightly higher probability because Ej,is are not
completely independent. Our observation in Section section 5.5.2 is proved.
Chapter 6
Location Service via CTC
6.1 INTRODUCTION
Chapter 4 and 5 demonstrate the feasibility of cross-technology communication on com-
modity wireless radios. The open question is whether CTC is practical enough to
serve real-world applications at a large scale. To answer this question, we apply CTC
technique to address a challenging problem in the emergent IoT location services. Sep-
cifically, Bluetooth Low Energy (BLE) location-based services (LBS) have been widely
deployed in various Internet-of-things (IoT) scenarios (e.g., retail stores [47], sports
stadiums [48], and airports [49]). More recently, BLE LBS with million+ users have
been launched. To enable instant delivery (e.g., real-time courier tracking and order
scheduling), a city-wide BLE system was deployed at more than 10,000 restaurants in
Shanghai, while the future nationwide deployment is expected to involve 2.5 million
merchants [50]. Large-scale deployments of BLE location services, however, are ex-
tremely challenging. Conventionally, BLE infrastructures (i.e., BLE beacons [51]) need
to be massively installed and configured to broadcast BLE location identifiers. A large
number of dedicated beacon devices inevitably incur tremendous deployment costs and
long-term maintenance burdens. According to a recent report from Forrester Research,
each beacon costs around $300 per year [52].
In this chapter, we present WiBeacon, a CTC-inspired low-cost solution for these
emerging large-scale BLE LBS. Specifically, we propose to repurpose already deployed
WiFi infrastructures to be virtual BLE beacons. By software upgrades on existing
64
65
WiFi access points (AP), they can broadcast BLE location identifiers to mobile devices
using cross-technology commmunication, achieving several advantages. Firstly, benefit-
ing from ubiquitous installations of WiFi APs over the last 10 years, WiBeacon enables
rapid deployments of BLE location services without incurring additional hardware costs.
Secondly, built-in Internet connectivity of APs allows system administrators to moni-
tor, manage, and upgrade a large number of virtual beacons remotely, thus significantly
reducing long-term maintenance burdens of beacons that are geographically scattered.
Although the feasibility of CTC has been discussed in previous chapters, the designs
proposed only address the compatibility among heterogeneous wireless devices at the
physical layer (i.e., enable the communication from WiFi to BLE without hardware
modification of either side). In contrast, WiBeacon targets building a full-fledged loca-
tion service. Therefore, we have to move from previous physical-layer compatibility to
full compatibility at the service level of both sides. First, our BLE location service must
be strictly compatible with both hardware and software of mobile devices requiring zero
modification. Second, our software upgrades of the AP should also be compatible with
native WiFi services and transparent to WiFi clients. More specifically, we need to
address two critical issues:
How can we avoid modifying mobile devices? Existing CTC techniques require re-
ceivers (i.e., mobile devices) to make significant modifications, which renders the service
incompatible with billions of unmodified devices. This is because WiFi radios suffer from
hardware restrictions and thus are inhibited from perfectly generating standard wire-
less signals following the existing BLE LBS protocols (e.g., iBeacon [53]). To overcome
communication errors, previous designs add extra error correction contents into packets,
thus violating the standard packet structures of existing protocols. Therefore, mobile
devices must be modified in advance to interpret the message. However, it is impractical
to modify all potential devices on large-scale LBS.
How can we integrate BLE LBS with the native WiFi service? A WiFi AP nor-
mally serves clients on one single WiFi channel, whereas BLE LBS (e.g., iBeacon)
requires periodic frequency hopping to increase the detection probability. Without a
careful integration of two services, WiFi networks may suffer from severe performance
degradation (e.g., transmission loss or even unexpected disconnection). Since previous
designs mostly target at the physical-layer compatibility, it is still an open issue how to
66
accomplish the service-level integration without sacrificing WiFi networks.
To the best of our knowledge, WiBeacon is the first cross technology design that
achieves service-level compatibility with both mobile devices and the WiFi AP. A
WiBeacon-enabled AP provides BLE location services strictly following iBeacon pro-
tocol, thus requiring zero modification of mobile devices. Furthermore, WiBeacon ser-
vice is seamlessly integrated with the native WiFi service of the AP, thus being fully
transparent to WiFi clients. More specifically, our technical highlights are as follows:
iBeacon-compatible Service for Unmodified Mobile Devices: WiBeacon
manages to broadcast elaborately designed WiFi packets that can be identified by un-
modified mobile devices as standard iBeacon broadcasts with zero errors. To achieve
this, we address the most fundamental barrier for cross-technology designs to fulfill
compatibility with the existing protocol: signal imperfection. Our key technical insight
is that although the transmitted signal is inevitably imperfect due to hardware restric-
tions of a WiFi transmitter, we can elaborately exploit low-pass filter (LPF), a standard
component of BLE radios, to mitigate imperfections at the receiver side. Based on this
critical insight, we propose a novel approach to generate WiFi signals with unique
imperfection patterns, which can take advantage of LPF to effectively eliminate com-
munication errors without making any modifications to mobile devices.
WiFi-compatible Integration on Commodity APs: We meticulously integrate
WiBeacon into commodity WiFi APs while retaining compatibility with the existing
WiFi service. Specifically, we carefully reuse several features of 802.11 standards to
emulate the frequency hopping of iBeacon. By doing so, we ensure that our integration is
compliant with 802.11 standards, transparent to WiFi clients, and applicable to massive
numbers of APs with different WiFi chipsets. Besides, we present a dynamic scheduling
algorithm to minimize WiBeacon’s impact on WiFi network performances.
We implement WiBeacon on OpenWrt [54] and evaluate it across WiFi APs using
Qualcomm, Broadcom, and MediaTek chipsets. Extensive experiments show that it
achieves compatibility with both mobile devices and native WiFi services.
To further validate the practicality of WiBeacon in the complex real-world scenario,
we deploy it in a real commercial LBS application, i.e., meal courier tracking in intel-
ligent food delivery. Specifically, we cooperate with an instant delivery company and
67
upgrade the existing APs of restaurants to serve as BLE LBS infrastructures. We en-
vision that WiBeacon will dramatically cut down hardware costs and administrative
burdens. During our two-week pilot study, WiBeacon provides location services for
697 meal couriers and helps to track 1780 food orders. The results of this real-world
pilot study demonstrate that WiBeacon offers as reliable services as conventional BLE
beacons.
In summary, our intellectual contributions are as follows:
• We propose WiBeacon - a low-cost solution for large-scale BLE location services
by reusing existing WiFi infrastructure at the cost of zero additional hardware
and little remote configuration.
• WiBeacon addresses several technical challenges in cross-technology designs to
achieve strict service-level compatibility with unmodified mobile devices and seam-
less integration with WiFi services.
• We integrate WiBeacon into COTS WiFi APs. The software and detailed instruc-
tions for making WiFi iBeacon-compliant are provided in [55] for the community
to reproduce our experiments.
• We extensively validate it in the real commercial LBS application with 150 types
of smartphones.
6.2 MOTIVATION
This section presents the motivation of reusing ubiquitous WiFi APs for BLE location-
based services.
Why are Large-scale Deployments of BLE Beacon Challenging? Conven-
tionally, BLE location services require dedicated beacons that broadcast their identifiers
to nearby mobile devices to indicate the proximity. Although effective, these stand-
alone, battery-powered beacons suffer from high deployment and administrative costs
when they are deployed on a large scale. In the deployment stage, users need to exert
a lot of effort purchasing beacon devices, manually installing them in situ, and labeling
their locations in the maps, which may take a few months [56]. After the installation,
68
the management of beacons is even more labor-intensive. Even with one-year battery
life, a thousand beacons would lead to a large number of replacements every week due
to beacon loss in building renovations, battery drain, hardware errors, etc. [57]. What
makes it worse is that since beacons are typically stand-alone without Internet con-
nections, the failures of beacons are hard to detect, and thus extensive site visits are
required for maintenance. A Forrester Research report estimates that each beacon costs
around $300 per year [52], incurring non-trivial expenses on massive deployments.
These fundamental limitations of dedicated beacons motivate us to explore a cost-
effective alternative for BLE LBS.
Why cannot WiFi LBS Replace iBeacon? One may wonder if we can directly
use WiFi protocol for LBS. Despite being extensively studied in the literature, WiFi
LBS also has several practical limitations. First, contrary to the universal accessibility
of iBeacon data on all mobile platforms, the list of scanned WiFi APs are not accessible
to developers on some mobile OS (e.g., IOS [58]) due to security concerns. This inhibits
WiFi LBS from being adopted in commercial applications that must be compatible
with any potential mobile devices. Second, WiFi scans incur high power consumption
to mobile devices, which drains their battery fast. In specific, WiFi reception consumes
600mW [59], significantly higher than BLE (30mW). The measurement study [60] shows
that frequent WiFi scan reduces the battery life by up to 90%. As a result, mobile
devices typically restrict WiFi scan interval to 60 s with screen on and 300 s with screen
off [61], which introduces unacceptable latency to location services that commonly desire
real-time performance. Finally, there are a lot of low-cost smart devices and wearables
that are only equipped with BLE chipsets and do not work with WiFi. For instance,
BLE-enabled smart lock in shared bikes can only detect the entry to geo-fences via
receiving iBeacon broadcasts [62].
Benefits of BLE LBS via Ubiquitous WiFi APs: We propose to reuse de-
ployed WiFi APs to provide BLE LBS, which combines advantages of both BLE and
WiFi, i.e., the well-developed commercial iBeacon ecosystem and ubiquitous WiFi in-
frastructures. In specific, 432 million public WiFi access points deployed in the last
decade [39] enable the large-scale deployment of BLE infrastructures with little effort
and in a short time. Furthermore, since the access points are connected to the Internet
and power supply, they allow remote management and get rid of the need for battery
69
changes, which significantly reduce maintenance costs. In the meantime, all the valuable
features of iBeacon ecosystem are inherited, including universal compatibility across ev-
ery mobile platform, thousands of developed iBeacon applications, and ultra-low power
consumption of mobile devices in real-time location-based applications.
5HPRWH
0DQDJHPHQW
+LJKVSHHG
:L)L6HUYLFH
L%HDFRQ/RFDWLRQ
,GHQWLILHU
%/(/%6 :L)L8VHUV
D$UFKLWHFWXUHRI:L%HDFRQE1H[XV6QDSVKRW
Figure 6.1: WiBeacon Turns Ubiquitous WiFi APs into Virtual BLE beacons for
Location-based Services.
6.3 OVERVIEW
In a nutshell, WiBeacon turns WiFi APs into virtual BLE beacons, providing BLE
location services with ubiquitous WiFi infrastructure. As Fig.6.1(a) depicts, the sys-
tem administrator upgrades and configures WiBeacon software on a deployed WiFi
AP remotely via an Internet connection. The WiFi AP periodically broadcasts legiti-
mate WiFi frames with elaborately selected payloads (Section section 6.5). These WiFi
frames can be recognized by unmodified mobile devices in the same way of discovering
standard iBeacon location broadcasts. Fig.6.1(b) shows a snapshot of iBeacon scanner
in Nexus 5 with unique location identifiers (e.g., UUID) and the estimated proximity
of WiBeacon. WiBeacon is carefully integrated with WiFi services (Section section 6.6)
so that the AP maintains high-speed services (e.g., 802.11g/n/ac/ax) for WiFi clients.
6.4 BACKGROUND
This section provides the background of iBeacon protocol and analyzes the limitations
of previous cross-technology communication (CTC) designs.
70
6.4.1 iBeacon Preliminary
An iBeacon-compatible beacon emits BLE broadcasts with the format depicted in
Fig.6.2, which is modulated using BLE 4.x 1 Mbps Gaussian Frequency Shift Key
(GFSK) and transmitted at BLE advertising channels. Specifically, each data bit is
modulated to one BLE chip, which is either a positive or a negative phase shift of
1 us duration. Note that BLE 4.x does not provide any redundant chips for error
corrections. Consequently, an iBeacon-compatible service is fundamentally required to
broadcast with zero chip error.
A mobile device captures the broadcast signal at BLE advertising channels and
passes it through a 1 MHz low pass filter (LPF). The filtered signal is demodulated via
quadrature demodulation. In specific, the receiver first samples the waveform at 1 MHz
(T0, ..., Tn). The changes of phase, i.e., phase shifts between consecutive complex I/Q
samples are then calculated. Finally, the receiver interprets the sign of phase shifts into
bits: positive phase shifts are decoded as bit 1 while negative ones are decoded as bit 0.
Decoded frames without chip error are used by mobile devices for proximity estimation,
whereas a frame with any chip error is discarded.
,
4
7
,7
47 7
ė ė %/(5HFHLYHU
3UHDPEOH
[$$
$GGUHVV
[(%('
88,'PDMRUPLQRUW[SRZHU
HWF &5&
XV
 3KDVH6KLIWV/3) ELWV
 S  S
Figure 6.2: Frame Format, Modulation and Demodulation of an iBeacon Broadcast
Frame.
6.4.2 Limitation of Existing CTC
Cross-technology communications (CTC) [20, 21, 63, 64] enable WiFi radios to emulate
heterogeneous wireless signal. However, the emulated signal inherently suffers from
signal imperfections due to hardware restrictions of a WiFi radio [21]. Due to the
imperfections, existing designs cannot produce iBeacon broadcasts without chip error
and thus fails to be strictly compatible with unmodified mobile devices.
Specifically, existing designs exclusively use frequency division multiplexing (OFDM)
71
modulator in WiFi radios to produce heterogeneous signal (thus named “OFDM method”).
As the left part of Fig.6.3 depicts, each OFDM symbol has a cyclic prefix (CP), so the
first 0.8 µs signal of an 4 µs OFDM symbol has to be exactly the same as the signal at
the last 0.8 µs. In contrast, BLE signals (depicted in the right part of Fig.6.3) do not
have such repetition. Due to this hardware restriction, one out of every 4 BLE chips
is significantly distorted, which leads to severe chip errors. Although corrupted signals
might still be detected and decoded by a BLE radio (i.e., physical-layer compatible),
the result will be ignored by unmodified mobile devices and thus cannot be used for
location services.
&RS\	3DVWH
&\FOLF
3UHIL[
:L)L2)'06\PERO 'HVLUHG%/(&KLSV
XV
XVRQH%/(&KLSXV,QFXU&KLS(UURU
&RS\	3DVWH
&\FOLF
3UHIL[
:L)L2)'06\PERO 7DUJHW%/(&KLSV
XV
XVRQH%/(&KLSXV'LVWRUWLRQ
(PXODWH
Figure 6.3: Previous OFDM Method Suffers from Severe Chip Errors Due to the Cyclic
Prefix Restriction.
6.5 WIBEACON Broadcast
WiBeacon takes an approach different from previous designs. We observe that besides
OFDM, every WiFi AP also supports complementary code keying (CCK) modulation
specified in a legacy WiFi protocol1, which is mandatory for backward compatibility -
even the latest WiFi 6 APs [65–67] must be able to serve legacy WiFi clients.
In this section, we propose “CCK method”. Interestingly, our CCK method suffers
from a comparable amount of signal imperfections as previous OFDM method. Yet,
it manages to produce no chip errors and is fully compatible with unmodified mobile
devices. We first present its basic idea in Section section 6.5.1. Then we analyze and
tackle two critical hardware restrictions of CCK method in Section section 6.5.2 and
section 6.5.3.
1Note that WiFi APs support multiple 802.11 protocols simultaneously (e.g., transmitting control
frames such as beacons, probe requests in 802.11b for maximum reliability, while using 802.11g/n/ac
for high-rate data communications). Hence, WiBeacon does not prevent APs from serving WiFi clients
with high-rate 802.11 protocols.
72
6.5.1 WiBeacon Broadcast via CCK
CCK Preliminary
Fig.6.4(a) demonstrates the conceptual diagram of CCK modulator. Every 8 bits are
encoded into a codeword (denoted as Ci) containing 8 complex chips (i.e, Ci,0, ...Ci,7)
according to a codebook defined in [68]. The chips are modulated by Quadrature Phase
Shift Keying (QPSK). As Fig.6.4(b) depicts, each QPSK chip Ci,j takes one of the four
values (ej0, ej
pi
2 , ejpi, e−j
pi
2 ) which correspond to 4 quadrature phases (0◦,90◦,180◦,−90◦).
QPSK chips are transmitted sequentially in 11 MHz. Each QPSK chip takes 111µs and
it takes 811µs in total to transmit a CCK codeword of 8 chips.
Bits
d0...d7
CCK
Encoder Ci,0...Ci,7
Codeword Ci 
(8 Chips) DAC
11 MHz
0j
e
Q 2/pje
pj
e
2/p- j
e
I
(a) CCK Modulation          (b) QPSK Chips Ci,0...Ci,7
Figure 6.4: Complementary Code Key (CCK) Modulation Produces 11 MHz QPSK
Chips w/ Quadrature Phases and Transmit in Sequence.
CCK Method: Basic Idea
To demonstrate the basic idea, we temporarily assume that CCK modulator does not
have any hardware restrictions, i.e., it can generate arbitrary QPSK sequences (assump-
tion #1) at an arbitrary frequency (assumption #2). Note that both assumptions will
be relaxed in Section section 6.5.2 (assumption #1) and section 6.5.3 (assumption #2).
Recall that BLE chips are modulated by phase shifts (i.e., phase changes) between
samples, while each QPSK chip of CCK produces a quadrature phase at a specific
sample. Therefore, by manipulating QPSK chips (i.e., phases) over time, we can create
phase shifts that perfectly emulate BLE chips. In the upper and middle parts of Fig.6.5,
we demonstrate an example of emulating a positive phase shift via QPSK chips. A BLE
chip (denoted as T0 → T1) is of 1 us while a QPSK chip (denoted as #1, ...#22) is of
1
11 us duration. Thus, a positive BLE chip can be produced by a sequence of eleven
consecutive ej0 (#1−#11) followed by eleven consecutive ej pi2 (#12−#22). Vice versa
for negative BLE chips.
73
 T S 
,7
XV 3KDVH6KLIW
7DUJHW%/(&KLS
XV3KDVH6KLIW
47
'HVLUHG
436.&KLSV
XV3KDVHV 3
KDV
H
436.&KLSV
E\5HVWULFWHG
&&.&RGHZRUG 3
KDV
H
XV
XV7 7

6LJQDO,PSHUIHFWLRQV
 
T  
 T S'  
Figure 6.5: CCK Method: Target BLE Chip (top), Basic CCK Method (middle), and
Signal Imperfections Caused by Restricted CCK Codewords (bottom).
6.5.2 Tackle Signal Imperfection
Codebook Restrictions
Unfortunately, the straightforward method in Section section 6.5.1 cannot be directly
applied. Every type of modulator in commodity wireless radios comes with hardware
restrictions and CCK is not an exception. As discussed in Section section 6.5.1, QPSK
chips are created by CCK encoder in the form of codewords (i.e., a group of 8 QPSK
chips). However, CCK codebook contains only 256 valid CCK codewords, which is far
from our assumption of being able to produce arbitrary QPSK sequence (Since each
chip takes one of the four possible quadrature phases, the total number of possible
combination of 8 chips is as large as 48 = 65536).
In fact, the restriction of CCK codebook gives rise to even more severe signal im-
perfections than previous OFDM methods. Take the emulation of a positive phase shift
depicted in Fig. 6.5 for example. The first 8 QPSK chips are desired to be eight consec-
utive ej0 (i.e., [1 1 1 1 1 1 1 1]). However, eight consecutive ej0 is not a valid codeword
in the codebook according to [68], while a close approximation (depicted in the bottom
of Fig. 6.5) is [1 1 1 -1 1 1 -1 1], which differs from the desired one by 2 QPSK chips. In
general, at least 25% of signals (2 out of 8 QPSK chips) generated by CCK codewords
are imperfect, which is more severe than previous OFDM methods (Recall that 0.8 µs
cyclic prefix in 4 µs OFDM symbol only causes 0.8/4=20% imperfections).
74
        



3K
DVH
&&. 'HVLUHG (UURU5HJLRQV
        



3K
DVH
        
7LPHXV



3K
DVH
6K
LIW
        



3K
DVH
        



3K
DVH
        
7LPHXV
3K
DVH
6K
LIW
2)'0 'HVLUHG (UURU5HJLRQV
E &&.6SLN\(UURUV6HSDUDWHGLQWR(YHU\%/(&KLS     e2)'0&KXQN\(UURUV&RQFHQWUDWHRQ%/(&KLSV
c &&.6SLN\(UURUVDUH(OLPLQDWHGE\/3) f 2)'0&KXQN\(UURUVDUH5HWDLQHGDIWHU/3)


d) &&.3URGXFHV&RUUHFW3KDVH6KLIWVDIWHU/3) J 2)'06WLOO6XIIHUV)URP,QFRUUHFW3KDVH6KLIWV
0+] 6LJQDO
EHIRUH /3)
0+]6LJQDO
DIWHU/3)
3KDVH6KLIWV
DIWHU/3)
0+]
f
0+]
f
:L)L6LJQDO
EHIRUH/3)
6XUYLYLQJ6LJQDO
DIWHU/3)
D /RZ3DVV)LOWHULQJDW
%/(5)(QG
Figure 6.6: WiBeacon Exploits Low-Pass Filtering (a) of an BLE Receiver to Eliminate
Signal Imperfections. The BLE Signal Produced via Our CCK Method (b) has Spiky
and Separated Errors (Grey Regions in (b)). Spiky Errors are Smoothed out by Low-
pass filtering (c) and thus Incurs Zero Chip Errors (d). In Contrast, Previous OFDM
Method (e) produces Chunky and Concentrated Errors (Grey Regions in (e)) that are
Retained after Low-pass Filtering (f) and Causes Severe Chip Errors (g).
The Opportunity of Imperfection Elimination
To eliminate imperfections of CCK signal without modifying mobile devices, we exploit
a hidden opportunity - low-pass filtering (LPF), a standard procedure on BLE receivers.
As Fig.6.6(a) depicts, a BLE receiver employs a low-pass filter at its front end for noise
reduction. The filter cuts off 20 MHz WiFi signal to 1 MHz, which is equivalent to a
moving average of the input signal in the time domain. Our key observation is that by
elaborately choosing CCK codewords with unique error patterns, imperfections in CCK
codewords can be smoothed out by the low pass filter 2 and thus incur zero chip error.
Fig.6.6 (b) demonstrates the opportunity by comparing the desired BLE signal
(dashed line in red) with a CCK signal (solid line in blue). Although the total number
of imperfections (grey areas) is large, the duration of each instance of error (i.e., an
unmatched QPSK chip) is extremely short (i.e., 111us). Therefore, if we select CCK
codewords correctly (the method will be discussed in Section section 6.5.2), error re-
gions appear to be short spikes that are separated into every BLE chip. When the
2Note that a low-pass filter is pervasively implemented on commodity BLE radios for noise reduction.
Thus, we do need any modification of mobile devices, as proved by 150 different smartphone models in
Section section 6.9.5.
75
signal pass through a 1 MHz low pass filter, these spiky and separated imperfections
are dramatically smoothed out by the moving average of LPF, as depicted in Fig.6.6(c).
Consequently, the filtered CCK signal yields exactly the same signs of phase shifts as
the desired signal in Fig.6.6(d).
In contrast, previous OFDM method suffers from a different error pattern and thus
cannot benefit from low-pass filtering. As depicted in Fig.6.6(e), instances of errors
caused by 0.8us cyclic prefix are chunky rectangles and concentrated only one of four
BLE chips. These chunky and concentrated imperfections are too long to be smoothed
out by moving average, as Fig.6.6(f) depicts. Therefore, imperfections are retained after
LPF, which causes severe chip errors in Fig.6.6(g).
CCK Codeword Selection
The remaining question is how to find CCK codewords that can take advantage of
low-pass filtering and produce correct BLE chips. According to our previous analysis, a
good codeword can be obtained in two steps. First, as discussed in Section section 6.4.1,
BLE chips are modulated by phase shifts. Hence, a good CCK codeword is expected
to produce phases that are as similar to desired ones as possible. Therefore, we start
with computing the desired QPSK sequence (denoted as Cd) with basic CCK method
in Section section 6.5.1. Then, we iterate through the codebook to find the codeword
Ci that is closest to the desired sequence C
d in the phase domain (Equation 6.1). The
distance in the phase domain is the summation of phase differences between Ci and C
d
at 8 chips (i,e., Ci,j and C
d
j , j = 0...7).
arg max
i
7∑
j=0
|tan−1Ci,j − tan−1Cdj | (6.1)
The first step commonly yields several codewords with the same closest distance. To
figure out the optimal one from the subset, we use our insight in Section section 6.5.2
that separated imperfections can be smoothed out by low-pass filtering. Thus, for a
codeword, the more separated unmatched QPSK chips are, the higher chances they can
be eliminated by low-pass filtering. As Equation 6.2 illustrates, we pick the codeword
in the subset, such that the minimum interval between consecutive unmatched chips is
maximized. Ii,k is the position of k
th mismatched chip of Ci compared to the desire C
d.
76
arg max
i
min Ii,k+1 − Ii,k
s.t.Ci,Ii,k 6= CdIi,k
(6.2)
6.5.3 Misalignment Compensation
So far, we assume that the center frequencies of WiFi and BLE are perfectly aligned.
However, restricted by the limited number of WiFi channels, they have to be misaligned.
For example, an 8 MHz misalignment exists between BLE channel 39 (2480 MHz) and
its nearest WiFi channel (2472 MHz).
Digital Carrier
wf
Original CCK codebook Codebook in BLE’s eyes
2 ( )w b sj f f nTe
p -
´ =
wf bf
id Codeword
1
2
… …
256 …
0 0 0 0
, , , , , ....
j j j j je e e e ep
2 2 2 2, , , , ....
j j j j
e e e e
p p p p
-
id Codeword
1
2
… …
256 …
2 4 17 8
0 11 11 11 11, , , , , ....
j j j j
je e e e e
p p p p
15 19 8
2 22 22 22 11, , , , , ....
j j j j j
e e e e e
p p p p p
Figure 6.7: Codebook Adjustment Compensates Misalignments (∆f = fw−fb = 1 MHz
in the example).
To address this issue, we propose codebook adjustment, a novel design to effectively
compensate for up to 9 MHz misalignments. Our technical insight is that when emulat-
ing a BLE waveform with a misaligned center frequency, the WiFi transmitter essentially
performs the emulation with an adjusted codebook from the BLE receiver’s viewpoint.
In specific, as the left part of Fig.6.7 depicts, the codebook in WiFi standards can be
viewed as the codebook from WiFi’s perspective where the receiver observes the WiFi
signal in the same center frequency as WiFi transmitter (i,e., fw). In contrast, the
BLE receiver in the right part of the figure observes the WiFi signal from a different
frequency point (i.e., fb), leading to a different observation of each WiFi codeword.
Based on the key insight, WiBeacon adjusts the codebook to BLE’s viewpoint before
conducting CCK method. As Fig.6.7 demonstrates, if WiFi and BLE are operating in
fw and fb respectively, we shift each codeword of the standard codebook in the frequency
77
domain by ∆f = fw − fb, which is done by the dot-product of each codeword with a
digital carrier as Equation 6.3 illustrates, where Ts is the sample rate.
Cadjustedi = Ci · e2pi(fw−fb)nTs (6.3)
With the adjusted CCK codebook, we perform CCK method in Section section 6.5.2
for each desired signal segment. Finally, calculated codewords are reverse engineered
into data bits, i.e., WiFi payload. Note that this process is done entirely in the software,
requiring no modification of WiFi hardware.
6.6 Integration with WiFi Services
WiBeacon is integrated with WiFi services with a simple but effective method that is
transparent to WiFi clients and applicable across AP devices of various vendors (Section
section 6.6.1). We also develop a dynamic WiBeacon scheduling algorithm to guarantee
the reliability of iBeacon service while minimizing its impact on WiFi performance
(Section section 6.6.2).
6.6.1 Compatible Integration
The most critical task of the integration is to emulate frequency hopping function of
iBeacon, while being transparent to WiFi clients. To achieve this, we propose a method
that entirely uses standard features of 802.11 AP. As a result, it doesn’t require any
cooperation with WiFi clients. Neither does it cause stability issues (e.g., disconnec-
tions and packet loss). Note that we intentionally avoid using any hardware-specific
features, so that our method can work across APs of different vendors (as proved by
our implementation in Section section 6.8). The method takes three steps:
Frequency hopping preparation: Before switching WiFi radio off the operating chan-
nel, we make several preparations to avoid packet loss. First, we disable the outgoing
gate of data queue and buffer incoming data to prevent downlink WiFi packets from
being erroneously transmitted. Second, to prevent uplink traffic from clients when the
AP has switched away, we transmit cts-to-self - an 802.11 control frame that can silent
the clients for a specific short period of time (¡ 33 ms) [69]. Upon receiving the frame,
78
the clients set their NAV (network allocation vector) accordingly and would not attempt
to send uplink traffic until NAV expires.
Frequency hopping: To switch WiFi radio to a different channel without disconnect-
ing clients, we reuse offchannel function [70] of WiFi APs, which is an 802.11 standard
feature design originally for APs to detect sources of interference or unauthorized ad-
hoc networks. Offchannel function can switches the radio to another WiFi channel for
a small amount of time (10-15 ms), while preserving entire states of the AP. Therefore,
it avoids reset of the network and disconnecting clients. We use this opportunity to
broadcast emulated iBeacon frames.
Frequency hopping completion: When the timer expires, we immediately switch WiFi
radio back to the operating channel, so it starts to deliver buffered data to clients. At
this time, WiFi clients can resume uplink data transmissions.
6.6.2 Dynamic WiBeacon Scheduling
WiBeacon is expected to guarantee the reliability of LBS, while minimizing its impact
on the performance of WiFi service. To meet both goals, we carefully design a WiBeacon
scheduler (depicted in Fig.6.9) based on two key observations. First, iBeacon broadcast
is the connection-less, so it doesn’t need to be strictly periodic and thus can be delayed
to avoid interference with WiFi traffic. Second, the Internet data traffic through WiFi
is bursty in nature, leaving plenty of temporal whitespace for WiBeacon.
250 500 1000
Advertising Interval (ms)
0
500
1000
1500
L
a
te
n
cy
 (
m
s)
Staggered
Strict
10080 60 50 40 30 20 15 10 5
WiFi Whitespace Length (ms)
0
10
20
30
40
50
60
70
80
90
100
C
D
F
 (
%
)
Coffee Shop
(10.1Mbps)
Study Area
(8.3Mbps)
(a) Average Detection Latencies  (b) WiFi Whitespace Distributions
Figure 6.8: Opportunities for Dynamic Scheduling.
To verify our observation, we conduct an empirical study where we compare the
average time it takes for COTS smartphone to detect BLE beacon when the advertising
frames are strictly periodic and staggered (delay by a random time between 0 and the
advertising interval). Fig.6.8(a) depicts that in various advertising intervals the average
79
detection latencies are not increased by the random delay. In addition, we analyze real-
world wireless data traces of public APs in a coffee shop and study area during the peak
hour. Both APs serve over 10 clients with 10.1 Mbps and 8.3 Mbps throughput. The
distribution of lengths of contiguous whitespace in each 100 ms are plotted in Fig.6.8(b).
Over 97.3% of the 100 ms periods have 15 ms or longer whitespace, which is sufficient
for offchannel activity, which typically takes 10-15 ms.
Based on the observations, WiBeacon is scheduled to maintain a constant broad-
cast frequency while minimizing the delay of WiFi traffic. Specifically, we dynamically
schedule WiBeacon broadcast as a periodic real-time task with a dynamic priority. As
Fig.6.9 depicts, the period and deadline are assigned to be the iBeacon advertising inter-
val, which is a parameter that users configure. To avoid interference with WiFi traffic,
WiBeacon task has the lowest priority if not approaching the deadline. The scheduler
monitors the data queue and opportunistically executes WiBeacon when the queue is
empty. In this way, WiBeacon effectively utilizes the whitespace between bursty WiFi
traffic.
BLE Advertising Interval (Period) 
Release
beacon task
Task
Deadline
Schedule 
beacon task
whitespace
WiFi bursts
...
Figure 6.9: Explore WiFi Temporal Whitespaces
When WiBeacon task approaches the deadline, the scheduler increases its priority
and starts the transmission of iBeacon broadcast frame. This introduces bounded delay
(typically less than 15 ms) for WiFi data while preventing the starvation of BLE LBS.
Note that such a situation is extremely rare in the real-world WiFi network. We analyze
captured traces at multiple places with more than 10 users (e.g., coffee shop in Fig.6.8).
When the advertising interval is set to 500 ms, the possibility is less than 0.01%.
80
(a) Hallway (c) Outdoor Bridge
WiBeacon BLE beacon
WiBeacon
BLE beacon
CC2650
BLE sniffer
WiBeaconBLE beacon
(b) Office
Nexus 5
Figure 6.10: Evaluation Scenarios (Commodity WiFi AP and BLE Beacon at a Hallway,
a Lab, and a Bridge).
6.7 LIMITATION and DISCUSSION
6.7.1 Limitation
Applicable vs. Inapplicable Scenarios: WiFi APs are originally deployed for pro-
viding high-speed Internet access to mobile devices, which is a very different purpose
from location services through BLE beacons. Thus, reusing existing WiFi APs for BLE
LBS suffers from potential limitations. First, WiFi APs are normally deployed at a
coarse granularity, e.g., one AP per room or point of interest. Hence, WiBeacon might
not be suitable for indoor localization with high precision requirements (e.g., precisely
tracking visitors in galleries). However, in these scenarios, WiBeacon could still offer
location information with low maintenance cost through existing WiFi APs, while ad-
ditional BLE beacons are required to further improve localization accuracy. Secondly,
WiFi APs are commonly placed at places where Internet coverage is needed, while some
applications might desire BLE beacons to be installed at different points of interest
(e.g., the entry/exit to stores or certain aisles). This mismatch also requires additional
deployments of BLE beacons to meet the demands of specific scenarios.
WiBeacon is most suitable to the emerging BLE beacon systems that are large-scale
and geographically scattered. A concrete use case is the on-going city-wide location
infrastructure deployments by Alibaba local service [50], in which every restaurant will
install exactly one beacon while 2.5 million beacons are expected to be deployed na-
tionwide. Since merchants have already installed at least one WiFi AP for providing
free Internet service to customers, upgrading WiFi APs with WiBeacon is sufficient to
support this use case. It can significantly reduce the deployment costs in such scenarios
81
because the total number of beacons are extremely large, as well as the management
costs because deployed beacons are scattered, and traditional beacon require exten-
sive site visits for maintenance. Another killer application of WiBeacon is automatic
check-in for mobile devices that provides accurate contract tracing with rapid deploy-
ment during the pandemic (e.g., COVID-19). Other applications of WiBeacon include
location-aware to-do lists reminders and coupon delivery at retail stores [47].
Broadcast Channel Coverage: BLE standard defines three broadcast channels (i.e.,
Chb37, Ch
b
38, and Ch
b
39). With codeword adjustment WiBeacon can effectively cover
Chb38 and Ch
b
39, while Ch
b
37 is too far away from any WiFi channel. As we will demon-
strate in Section section 6.9.4, the coverage of two broadcast channels is sufficient to
provide reliable location-based services in real-world scenarios.
6.7.2 Discussion
Availability of Legacy WiFi: Every commodity WiFi AP must support 802.11b CCK
modulation for backward compatibility (i.e., serving legacy clients). Thus, WiBeacon
applies to both deployed and future APs. For example, CCK is available in the latest
WiFi 6 APs [65–67]. Additionally, an AP can simultaneously operate with different
802.11 protocols, so WiBeacon does not force AP to work in 802.11b. Regular WiFi
traffic can still use high-rate protocols, i.e., 802.11g/n/ac/ax, while we exclusively use
CCK for WiBeacon.
Proximity Estimation Accuracy: By default, an AP has higher transmission power
and hence a broader signal coverage. Note that a broader coverage does not mean
less proximity estimation accuracy because proximity is not determined by whether the
signal of a beacon is received but how much signal is attenuated. Thus, even if devices
receive WiBeacon signal at a farther distance, the larger value of signal attenuation
measurements suggests it is still far away. Furthermore, as we will discuss in Section
section 6.9.2, we can tune down the power of WiBeacon while retaining LBS reliability.
WiBeacon Deployment: Installations of WiBeacon in deployed WiFi APs can be
done in several ways. Retail stores, restaurant chains, universities, etc. often have
remote administrative control of their private APs. These organizations have the incen-
tives to upgrade their APs to serve their own mobile APPs. Additionally, public WiFi
hotspots owned by Internet service providers (ISP) can also be upgraded remotely. For
82
example, Xfinity runs over 18 million free public WiFi APs [71], so we can cooperate
with them to deploy a high amount of WiBeacon for public or private usage.
The Generality of WiBeacon: In this chapter, we only discuss WiFi to BLE com-
munication. However, our key technical insight could be generalized and improve cross-
technology communication from WiFi to other narrowband wireless techniques. Specif-
ically, our critical observation that low-pass filter at narrowband front end can be ex-
ploited to eliminate communication errors is generally applicable to other CTC designs.
For example, our experiment shows that CCK method also significantly increases the
reliability of WiFi to ZigBee CTC from 50% to 99.9% compared to the previous OFDM
method proposed in WEBee [20]. However, we gloss over the results in the dissertation
because they are out of scope.
Security and Privacy: WiBeacon has also considered network security and public
privacy on large-scale deployment. First, WiBeacon is protected by the sophisticated
WiFi authentication mechanism, which is much stronger than Bluetooth beacons. In
addition, WiBeacon will not harm public privacy because it only broadcasts identifiers
without the ability to collect or listen to the Bluetooth packets in the air.
6.7.3 Future Works
In our future work, we will improve the practicality of WiBeacon from the following
aspects. First, we plan to design a more efficient WiBeacon scheduler to further re-
duce the interference between WiBeacon and WiFi traffic. For example, we could apply
data-driven WiFi traffic prediction for estimating future WiFi traffic and dynamically
adjusting BLE beacon injection. Second, we will cooperate with WiFi device vendors
and open-source communities to customize the firmware for WiBeacon. This allows us
to reduce the overhead of switching WiFi channels in our frequency hopping implemen-
tation.
6.8 SYSTEM IMPLEMENTATION
Implementation for Large-scale Deployments: We implement WiBeacon on Open-
Wrt [54], the most popular open-source operating system for the commodity WiFi APs.
Note that WiBeacon is not hardware-specific - it works with any WiFi drivers and
83
chipsets since it only uses 802.11 standard features. To demonstrate this, we exert a
lot of effort to adapt WiBeacon to commodity APs using WiFi radios from highly di-
versified chipset vendors. Table 6.1 lists part of the representative AP models we have
tested.
Table 6.1: Representative WiFi Devices Tested.
Device Chipset Vendor Driver
GL-AR750 QCA9531 Qualcomm ath9k
Linksys-E2000 BCM4328 Broadcom b43
Netgear-A6210 MT7612E MediaTek mt76
To facilitate future deployments on a large scale, we develop WiBeacon as OpenWrt
.ipk packages, which can be downloaded and installed on APs in the same way as in-
stalling Android apps on smartphones. In addition to basic LBS functions, the package
provides two features for better usability: a remote configuration interface for updat-
ing the beacon information (e.g., UUID) and a heartbeat service interface for remote
monitoring.
6.9 PERFORMANCE EVALUATION
6.9.1 Evaluation Settings
WiBeacon is extensively evaluated in both lab environments and real-world commercial
applications. As Fig.6.10 demonstrates, we test WiBeacon in several representative
scenarios, including a hallway of the campus building, a lab office, and a 400-meter long
bridge. In addition, we cooperate with a food delivery platform and conduct a pilot
study at 20 restaurants in Shanghai over two weeks.
The performance of WiBeacon is evaluated with commodity WiFi APs (e.g., GL-
AR750 [72]). We measure the low-level communication quality with CC2650 BLE snif-
fer [43], while compatibility with mobile devices and overall service performances are
evaluated with 150 COTS smartphones of different models. The results are compared
with a dedicated BLE beacon (Minew i8 [73] with nRF51822 chipset).
84
We start with detailed evaluations of two critical designs for service-level compatibil-
ity, i.e., the reliability of WiBeacon location broadcasts (section 6.9.2) and the integra-
tion with WiFi service (section 6.9.3). Then overall LBS performances (section 6.9.4)
are examined. Finally, we discuss our pilot study in the commercial LBS applications
(section 6.9.5). Without further explanations, both WiBeacon and BLE iBeacon trans-
mit standard iBeacon frames with 36 bytes, with default transmission powers of 15 dBm
and 4 dBm, respectively. In each experiment, 10000 frames are sent, and the statistical
results are reported.
-90° -45° 0° 45° 90°
Phase Shifts
0
1
2
In
d
ic
e
s 
(×
10
3
)
1 0
0
20
40
60
P
r
o
b
. 
(%
)
1 0
-90° -45° 0° 45° 90°
Phase Shifts
0
1
2
1 0
0
10
20
1 0
(a) Our CCK Method               (b) Previous OFDM Method 
Figure 6.11: Chip Errors: CCK vs. OFDM.
6.9.2 WiBeacon Broadcast Reliability
Chip Accuracy: CCK vs. OFDM
Each bit of iBeacon broadcast is modulated into one chip (± phase shift). Due to the
lack of redundancy, a single chip error causes frame corruption and incompatibility with
mobile devices. To achieve service-level compatibility, we propose CCK method, which
exploits low-pass filtering of a BLE receiver to eliminate chip errors. To demonstrate its
effectiveness, we adopt CCK method and OFDM method proposed in [20] to generate
the same iBeacon broadcast. Phase shifts after LPF are compared with the ground truth
in Fig.6.11, where chip 1 is denoted as ◦ and chip 0 is plot as +. Chip errors occur when
phase shifts cross the decision boundary depicted as the dotted line. As Fig.6.11(a)
shows, CCK method is always able to produce correct phase shifts. In contrast, OFDM
method in Fig.6.11(b) incurs around 19.25% chip errors. The result clearly shows that
CCK method effectively overcomes hardware restrictions of WiFi transmitters.
85
-53-57-61-65-69-73-77-81-85
RSSI (dBm)
40
60
80
100
F
R
R
 (
%
)
WiBeacon #38
WiBeacon #39
BLE beacon
-20 -10 0 10 20
Frequency (MHz)
-20
0
20
40
60
d
B
m
(a) FRR vs. RSSI      (b) WiFi Spectrum
#38 #39
Figure 6.12: Frame Reception Ratio vs. RSSI.
Frame Reception Ratio: WiBeacon vs. BLE
We measure the frame reception ratio (FRR) of WiBeacon over varying received sig-
nal strengths and compare the results with the FRR of standard BLE beacons. The
noise floor during our experiments is -95 dBm. The performances of WiBeacon on two
BLE broadcast channels (Chb38 and Ch
b
39) are reported in the Fig.6.12 (a). The frame
reception ratios of WiBeacon on both channels approximate standard BLE communi-
cation closely. It achieves > 95% FRR when the RSSI is above -65 dBm and manages
to maintain 50% packet reception even when the signal is very weak (-85 dBm). This
result demonstrates the accuracy of our CCK method, which is critical for reliable BLE
location services. In addition, we observe that WiBeacon performs marginally better
for Chb38 than Ch
b
39. This is because the two BLE channels are located at different po-
sitions of the WiFi spectrum as shown in Fig.6.12(b), which leads to a slightly different
amount of emulation errors. However, as Fig.6.12 shows, the overall performances of
the two channels are close to each other.
3 6 9 12 15 18
0
50
100
F
R
R
 (
%
)
WiBeacon
BLE beacon
3 6 9 12 15 18
Distances (m)
-80
-60
-40
R
S
S
I 
(d
B
m
)
WiBeacon
BLE beacon
Distances (m)
D Frame Reception Ratio       (b) Received Signal Strength
Figure 6.13: Indoor Performance: WiBeacon vs. BLE.
86
The Impact of Distances
To evaluate the communication distance of WiBeacon, we measure the frame reception
ratio (FRR) of WiBeacon in both indoor and outdoor scenarios. In the experiment, GL-
AR750 WiFi AP broadcasts at Chw4 (2427MHz) using the default 15 dBm Tx power
while the CC2650 BLE sniffer captures frames at BLE Chb38 (2426MHz). Fig.6.13(a)
compares the FRR of WiBeacon with BLE beacon in the hallway. WiBeacon achieves
higher accuracy (99.9% at 3 meters and > 97% within 18 meters) than BLE beacon
because the stronger Tx power of WiFi transmitter provides a higher signal-to-noise
ratio (SNR) at the BLE receiver. As demonstrated in Fig.6.13(b), the received signal
strength of WiBeacon is 6 dB higher on average, which is smaller than the gap of
transmission power (11 dB). This observation proves that BLE front end performs low-
pass filtering that only passes through 1 MHz signal, making the effective bandwidth of
WiBeacon 1 MHz. Consequently, we observe that WiBeacon and BLE beacon experience
similar small scale fading due to multi-path effect (e.g., a sharp RSSI drop at 6 meters
for both WiBeacon and BLE beacon in Fig.6.13(b)).
0 20 40 60 80 100
Distance (m)
0
20
40
60
80
100
F
F
R
 (
%
)
WiBeacon
BLE beacon
Figure 6.14: Outdoor FRR: WiBeacon vs. BLE.
In the outdoor scenario, the reception ratio of WiBeacon is even higher due to fewer
wireless interferences. Fig.6.14 shows the FRR of WiBeacon and BLE beacon in varying
distances on the bridge. WiBeacon can deliver 99% frames at 20m and 90% at 40m.
When the distance increases from 40 to 100 meters, the FRR slowly drops to 50%.
The outdoor FRR of WiBeacon again outperforms BLE beacon due to the stronger
transmission power of WiFi, which is extremely beneficial when WiBeaon needs to
cover a very large outdoor area.
87
3 6 9 12 15 18
Distances (m)
0
50
100
F
R
R
 (
%
)
15dBm(WiFi)
8dBm(WiFi)
4dBm(BLE)
3 6 9 12 15 18
Distances (m)
-80
-60
-40
R
S
S
I 
(d
B
m
)
15dBm(WiFi)
8dBm(WiFi)
4dBm(BLE)
D566,YV7;3RZHUE)UDPH5HFHSWLRQ5DWLR
Figure 6.15: Impact of WiFi Transmission Power.
Impact of Tx Power
By default, WiFi device transmits with significantly higher transmission power than
BLE devices. For a fair comparison, we also evaluate the performance of WiBeacon
when the power is intentionally tuned low. Fig.6.15(a) shows that when the power is
reduced to 8 dBm, RSSI of WiBeacon becomes comparable with standard BLE beacon.
With lower power, WiBeacon is still reliable. As Fig.6.15(b) depicts, WiBeacon correctly
delivers 90% BLE frames at 18 meters. Since a WiFi AP can adjust the transmission
power for each frame, we can reduce the power of WiBeacon frames to produce fewer
wireless interferences.
3 6 9 12 15 18 21 24
0
20
40
60
80
100
F
R
R
(%
)
Distances (m)
1MHz 4MHz 6MHz 8MHz 9MHz
Figure 6.16: Frame Reception vs. Misalignments.
Impact of Center Frequency Misalignments
To overcome the restriction of WiFi channels, codebook adjustment is proposed for
WiFi to produce iBeacon broadcast while having extremely large center frequency mis-
alignments. Fig.6.16 shows that with an 8 MHz misalignment, WiBeacon achieves 90%
FRR at 12 meters while up to 9 MHz can be tolerated. The capability allows WiBeacon
to cover two BLE advertising channels, i.e., Chb38 (2426MHz) with Ch
w
5 (2427MHz) and
Chb39 (2480 MHz) with Ch
w
13 (2472 MHz).
88
1 2 4 8
#Streams
0
20
40
60
T
h
ro
u
g
h
p
u
t 
(M
b
p
s)
500ms
200ms
w/o
0 50 100 150
TX Rate (Mbps)
0
50
100
150
T
h
ro
u
g
h
p
u
t 
(M
b
p
s)
w/o
500ms
D S9LGHRStreams E 6DWXUDWHG7KURXJKSXW
90ESV
Figure 6.17: Transparency to WiFi Traffic.
6.9.3 Integration with WiFi Services
Transparency to WiFi Service
To evaluate the transparency of WiBeacon to WiFi clients, we conduct experiments with
one AP and eight clients and compare WiFi performance with and without WiBeacon.
For the experiments to be repeatable, we capture packets of a 1080p YouTube video
and replay them with Tcprelay [74]. Fig.6.17(a) presents the aggregated throughput
under different advertising intervals and with a varying number of clients. In all cases,
WiBeacon does not introduce noticeable throughput degradation.
Saturated Throughput
We also examine the overhead when WiFi traffic is further pushed to the extreme. As
Fig. 6.17(b) depicts, WiBeacon does not affect the throughput when the traffic is within
88%(110/125) of the saturated throughput for GL-AR750. When WiFi traffic is fully
saturated, WiBeacon introduces a bounded overhead of 9 Mbps. This result coincides
with our theoretical analysis. Since each frequency hopping takes 15 ms and WiBeacon
performs two frequency hopping in one advertising interval (500 ms), the theoretical
overhead is (15 × 2ms/500ms) × 125 = 7.5Mbps. Note that a WiFi AP is rarely fully
saturated. For example, the utilization ratio under 8 YouTube streams is around 40%.
Transparency to Ambient BLE Devices
To examine the coexistence of WiBeacon with ambient BLE devices, we conduct an
experiment as depicted in Fig.6.18(a). In the experiment, a various number of WiBeacon
enabled AP broadcasts at Chw4 (2427 MHz) with a 500 ms beacon internal. We measure
89
2426 2424 2422 2420 2418
BLE channel (MHz)
0
50
100
F
R
R
 (
%
)
1 WiBeacon
5 WiBeacon
10 WiBeacon
15 WiBeacon
%/(5;
%/(7;
:L)L$3V
D 6HWWLQJV E )55YV%/(FKDQQHOV
Figure 6.18: Transparency to Ambient BLE Devices.
the frame reception ratios (FRR) of BLE communications at five BLE channels (from
2418 MHz to 2426 MHz). The transmission power of BLE transmitter is -15 dBm and
the received signal strength is -55 dBm. As Fig.6.18(b) shows, the FRR is 99.99% with
one AP while the reception ratio is above 97% when the number of APs are increased
to fifteen. The result demonstrates that WiBeacon introduces moderate interference to
BLE devices, thanks to listen-before-talk conducted by APs to effectively avoid collision
with other wireless devices. In addition, the BLE channel that is further away from the
center frequency of WiFi APs suffers less frame reception errors. For example, the
impact of WiBeacon to 2418 MHz channel is almost negligible.
0 2 4 6
Detection Time (s)
0
10
20
30
40
50
60
70
80
90
100
C
D
F
(%
)
WiBeacon
(500ms)
BLE beacon
(500ms)
0 2 4 6 8 10
Detection Time (s)
0
10
20
30
40
50
60
70
80
90
100
C
D
F
(%
)
800ms
500ms
200ms
D WiBeacon vs. BLE Beacon  (b) Varying Advertising Intervals
Figure 6.19: Distribution of Detection Interval.
6.9.4 Overall Service Performance
Beacon Detection
This section evaluates the detection latency of WiBeacon versus BLE beacon on com-
modity smartphones. It is noteworthy that to demonstrate the overall performance,
WiBeacon only broadcasts at 2 BLE channels that WiFi signal covers (i.e., Chb38, Ch
b
39),
while a BLE beacon uses 3 BLE channels. Timestamps of detections are recorded on
90
smartphones. Fig.6.19 depicts the distribution of the intervals between successive bea-
con detections of Nexus 5 at the distance of 10 meters, which are indicators of the
latency. As Fig.6.19(a) depicts, when the advertising interval is 500ms, the latency
of WiBeacon approximates BLE beacon tightly with a maximum of 6.5 seconds. The
small margin exists because the extra Chb37 used by the BLE beacon slightly increases
the detection probability. Furthermore, we evaluate the impact of advertising intervals.
As the Fig.6.19(b) shows, more aggressive broadcasts (i.e., 200ms) further reduce the
average latency while 500ms can achieve the best tradeoff between performance and
overhead. Overall, the performance of WiBeacon is sufficient to serve popular LBS
applications (e.g., check-ins and coupon delivery).
1 2 3 4 5 6 7 8 9 10
Distance (m)
0
1
2
3
A
v
er
a
g
e 
E
rr
o
r 
(m
)
WiBeacon
BLE beacon
im
m
ed
ia
te
ne
ar fa
r
immediate
near
far
0
0
0
9.756
0
6.667
100
93.33
90.24
(a) Accuracy vs. Distance            (b) Proximity Levels
Figure 6.20: Proximity Estimation Accuracy.
Proximity Estimation Accuracy
We use Android Beacon Library [75] to measure the proximity estimation accuracy of
WiBeacon. The library estimates the distance by calculating signal attenuations (i.e.,
the ratio between the transmission power of a beacon and the received signal strength
(RSSI) of smartphones). As Fig.6.20(a) depicts, WiBeacon demonstrates comparable
accuracy with BLE beacon. The average error is within 1 meter when the distance is
less than 5 meters. Both errors increase dramatically when the distance is large than 6
meters due to the uncertainty of RSSI. Apple categorizes the proximity into three coarse-
grained ranges, i.e., immediate (< 0.5 meter), near (0.5-3 meters) and far (> 3 meters).
We evaluate WiBeacon with the criteria. Fig.6.20(b) shows it distinguishes “immediate”
from “near” with 100% accuracy and “near” from “far” with > 90% accuracy.
In summary, overall performances of WiBeacon are comparable to dedicated bea-
cons, while it is superior to the dedicated beacon in deployment costs and management
burdens.
91
%/(EHDFRQ
:L%HDFRQ
(a)
$SSOH
+XDZHL
6DPVXQJ
;LDRPL
2SSR
9LYR
2WKHUV


 

36

(b)
BLE beacon (B)
WiBeacon (W)
B W B W B W B W B W B W B W B W
1 2 3 4 5 6 7 8
-125
-100
-75
-50
-25
0
R
S
S
I
(d
B
m
)
Restaurant Indices
(c)
0 20 40 60 80 100
-1
0
1
2
3
4
5
6
7
8
#
C
o
u
r
ie
r
s
Time (minute)
WiBeacon
BLE beacon
(d)
Figure 6.21: Pilot Study. (a) WiBeacon Deployments in 20 Restaurants. (b) 150
Smartphone Models Served by WiBeacon. (c) RSSI: WiBeacon vs. BLE Beacon. (d)
WiBeacon is as Accurate as BLE Beacon in Courier Detections.
6.9.5 Pilot Study
Real-world LBS Application
To demonstrate practicality of WiBeacon, we are cooperating with one of the largest
Chinese food delivery companies and testing it in a real food delivery application. Specif-
ically, this company recruits 100000+ meal couriers in Shanghai to deliver food from
restaurants to customers. They need to deploy BLE beacons at 50000+ restaurants and
use locations of couriers for automatic check-ins and new order dispatches. Since al-
most every restaurant has installed WiFi APs to provide customers free Internet service,
WiBeacon can significantly cut down the deployment and maintenance cost.
Note that although couriers’ smartphones have WiFi radios, extending WiFi APs
for BLE LBS is still necessary due to two practical issues. First, the smartphone is
required to continuously scan for reliable check-ins and real-time dispatches. A contin-
uous WiFi scan quickly drains the battery, whereas BLE only consumes less than 2%
extra power according to our measurement. Second, the service must be compatible
with any potential smartphone of couriers. However, WiFi LBS does not work with any
IOS smartphones because the check-in App on IOS cannot access scanned WiFi lists.
Pilot Study Settings
We remotely upgrade the APs in 20 restaurants near JinTie mall in Shanghai (depicted
in Fig.6.21(a)), which then broadcast beacon identifiers to the meal couriers’ smart-
phones. During this two-week pilot study, our WiBeacon system provides location-based
services for 697 couriers, while helping 1780 orders in total. Note that the restaurants’
environment can be highly complex with moving humans and obstacles, as demonstrated
92
in Fig.6.21(a). During this deployment, the pre-built Openwrt packages are downloaded
and installed on the APs. Then the system administrator configures the beacon identi-
fiers via the remote access. This quick deployment demonstrates our unique benefits of
zero additional hardware as well as the possibility of remote configuration/management.
After the quick deployment, these WiFi APs broadcast BLE identifiers at BLE
channel 38 and 39 with 15 dBm transmission power, following an interval of 500ms.
Upon receiving the packets from WiBeacon, the couriers’ smartphones record the UUID,
reception time, RSSI, the model of their smartphones, etc. To test our system, we
compare it against a pre-installed BLE beacon (marked in Fig.6.21(a)) that is placed
at the same spots with the 4 dBm Tx power. We evaluate the following aspects: device
compatibility, signal strength, and LBS accuracy. Our observations are as follows.
•Device Compatibility: The diversified smartphone models used by the meal couriers
provide us a comprehensive validation of WiBeacon in different smartphone models. As
Fig.6.21(b) depicts, 150 types of smartphone models from 11 manufacturers (e.g., Apple,
Huawei, and Samsung) have been proved compatible with WiBeacon, demonstrating
that WiBeacon’s design is generally applicable.
• Signal Strength: We analyze RSSI records of both WiBeacon and BLE beacons col-
lected from couriers’ smartphones. The results of 8 restaurants are demonstrated in Fig.
6.21(c). We observe that different from the results in the lab (Fig.6.13 (b)), WiBeacon
does not always have a better signal strength than BLE beacon. In fact, both RSSI
vary significantly across different restaurants. This is because in complex real-world
deployment, signal strengths are affected by many factors (e.g., the installation location
of APs and beacons, the moving trajectory of the couriers, and smartphone models).
Despite the huge RSSI fluctuation, the RSSI of WiBeacon and BLE beacons have sim-
ilar trends (e.g., a similar median value and distribution pattern), demonstrating that
WiBeacon is as reliable as dedicated BLE beacons.
•LBS Accuracy: We evaluate the location-based service performance of WiBeacon
by measuring detections of couriers’ arrival. The traces of BLE beacon in the same
restaurant and order information from the food delivery platform are used as ground
truth. During the two-week pilot study, WiBeacon detected every arrival events that
are recorded by BLE beacons. Our interesting observation is during peak hours of the
first weekend, WiBeacon detected two more arrival events than BLE beacons. A close
93
look at traces reveals a unique benefit that was not observed in the lab - WiBeacon is
more robust against WiFi interferences than BLE beacon because other WiFi devices
naturally back off. Figure 6.21(d) visualizes the number of detected meal couriers by
WiBeacon and BLE beacons in the same restaurant during peak hours (from 11 am to
1 pm). It is clear that the number of couriers that hear WiBeacon and BLE beacon is
approximately the same throughout the time, suggesting WiBeacon’s accuracy.
This two-week large-scale pilot study across 697 couriers and 150 smartphones proves
that WiBeacon can provide reliable location services to real LBS application while
significantly reducing the hardware cost and maintenance complexity. Based on this
success, we are planning to deploy WiBeacon on a large scale for the further stress test.
6.9.6 Summary
We propose WiBeacon, a cost-effective solution for large-scale BLE LBS. Our evalua-
tion in the real-world application demonstrates that WiBeacon provides reliable BLE
location services while incurring zero hardware cost and low management complexity.
Chapter 7
Future Works
The dissertation demonstrates the feasibility of cross-technology communication and
an example of adopting CTC in real-world applications. In my future work, I plan to
work on a broader spectrum of research topics that are related to and inspired by CTC.
Specifically, in the short term, I will investigate more applications that can be enabled
by CTC as well as the more generic CTC approach using machine learning. In the long
term, I am going to extend my study on heterogeneous IoT beyond the communication.
There are three specific topics I am interested to dive in.
7.1 CTC Application
Many interesting applications can be built on top of the capability of communication
among heterogeneous wireless protocols. First, Chapter 5 shows CTC provides coarse-
grained proximity detection for Bluetooth IoT devices. Yet, there are a lot of IoT
applications that require fine-grained positioning. CTC can potentially serve this pur-
pose as well. For example, using the signal hitchhiking and reconstruction technique
discussed in Chapter 5, high-speed radios can obtain the raw I/Q signal transmitted
by a heterogeneous IoT device. Therefore, it is possible to the large bandwidth, high
sample rate and multi-antenna capability to achieve cross-technology ranging and angle
of arrival estimation. However, how to mitigate the impact of the quantization error
needs to be investigated. Second, the proposed CTC design mainly focuses on the point-
to-point scenarios. With the capability of point-to-point communication, heterogeneous
94
95
IoT devices can form a mesh network, enabling several applications such as collaborative
routing and data dissemination. Last but not least, the current designs mainly target
wireless techniques in 2.4GHz or 5 GHz ISM bands. There are an increasingly number
of shared spectrums (e.g., Sub-GHz, CBRS, and mmWave). Applying the idea of CTC
to these emergent shared spectra might open the door for even more application cases,
e.g., collaborative spectrum sharing, long-distance CTC, etc.
7.2 CTC with Machine Learning
The CTC techniques discussed in the dissertation are designed largely based on our do-
main knowledge of modulation and coding schemes of the existing wireless techniques.
We figure out the hand-crafted features of the specific waveform (e.g., phase shift of
ZigBee OQPSK) and use them to establish the cross-technology modulation and de-
modulation. Therefore, building CTC for new wireless protocols using this methodology
will always require extensive expert participation. Yet, the performance might be sub-
optimal due to the increasingly complicated wireless system and the inherent limitation
of hand-crafted features. One possible solution for a generic CTC is to use data-driven
method. For example, we can exploit machine learning to obtain the features from var-
ious wireless signal and use neural networks to approximate cross-technology emulation
or demodulation procedures. Hence, end-to-end neural network design for communica-
tion among heterogeneous protocol might be a promising new direction.
7.3 Cross-technology Sensing
IoT devices are not only equipped with different wireless radios but also highly diversified
sensors. For example, smartphones are embedded with the camera, IMU, and GPS,
while ambient IoT devices can provide radar, infrared, pressure sensing data, etc. Using
CTC, various IoT devices now can share these heterogeneous IoT data directly with
each other. Incorporating the data from multiple IoT devices can improve the accuracy,
robustness, and coverage. This inspires me to extend my research from cross-technology
communication to cross-modal sensor fusion and collaboration.
Chapter 8
Conclusion
This dissertation presents cross-technology communication, a new IoT networking paradigm.
Two critical technical methods (i.e., signal emulation and signal hitchhiking) are intro-
duced to address the physical-layer incompatibility among heterogeneous wireless tech-
niques. Then, we report the application of CTC in the real-world study. We envision
that CTC will inspire a wide spectrum of innovation and provide a new direction for
research on wireless coexistence, coordination, and cooperation.
96
Bibliography
[1] Statista.com. Internet of Things (IoT) connected devices installed base world-
wide from 2015 to 2025. https://www.statista.com/statistics/471264/
iot-number-of-connected-devices-worldwide/, 2021.
[2] Statista.com. Number of wireless local area network (WLAN) connected devices
worldwide from 2016 to 2021. https://www.statista.com/statistics/802706/
world-wlan-connected-device/, 2021.
[3] Statista.com. Bluetooth enabled connected device shipments worldwide
from 2015 to 2024. https://www.statista.com/statistics/1221008/
global-bluetooth-connected-device-shipment-forecast/, 2021.
[4] Chieh-Jan Mike Liang, Nissanka Bodhi Priyantha, Jie Liu, and Andreas Terzis.
Surviving wi-fi interference in low power zigbee networks. In Proceedings of the 8th
ACM conference on embedded networked sensor systems, pages 309–322, 2010.
[5] Wan Du, Zhenjiang Li, Jansen Christian Liando, and Mo Li. From rateless to dis-
tanceless: Enabling sparse sensor network deployment in large areas. IEEE/ACM
Transactions on Networking, 24(4):2498–2511, 2015.
[6] Christos Gkantsidis, Wenjun Hu, Peter Key, Bozidar Radunovic, Pablo Rodriguez,
and Steluta Gheorghiu. Multipath code casting for wireless mesh networks. In
Proceedings of the 2007 ACM CoNEXT conference, pages 1–12, 2007.
[7] Dimitrios Koutsonikolas, Y Charlie Hu, and Chih-Chun Wang. High-throughput,
reliable multicast without” crying babies” in wireless mesh networks. In Proceedings
of the 2008 ACM CoNEXT Conference, pages 1–2, 2008.
97
98
[8] David A Eckhardt and Peter Steenkiste. A trace-based evaluation of adaptive error
correction for a wireless local area network. Mobile Networks and Applications,
4(4):273–287, 1999.
[9] M Rajesh and JM Gnanasekar. Gccover heterogeneous wireless ad hoc networks.
Journal of Chemical and Pharmaceutical Sciences, 8(2):195–200, 2015.
[10] Zhiwei Zhao, Wei Dong, Gonglong Chen, Geyong Min, Tao Gu, and Jiajun Bu.
Embracing corruption burstiness: Fast error recovery for zigbee under wi-fi inter-
ference. IEEE Transactions on Mobile Computing, 16(9):2518–2530, 2016.
[11] Bo Han, Aaron Schulman, Francesco Gringoli, Neil Spring, Bobby Bhattachar-
jee, Lorenzo Nava, Lusheng Ji, Seungjoon Lee, and Robert R Miller. Maranello:
Practical partial packet recovery for 802.11. In NSDI, pages 205–218, 2010.
[12] Kyle Jamieson and Hari Balakrishnan. Ppr: Partial packet recovery for wireless net-
works. ACM SIGCOMM Computer Communication Review, 37(4):409–420, 2007.
[13] Tao Jin, Guevara Noubir, and Bo Sheng. Wizi-cloud: Application-transparent dual
zigbee-wifi radios for low power internet access. In INFOCOM, 2011 Proceedings
IEEE, pages 1593–1601. IEEE, 2011.
[14] Kameswari Chebrolu and Ashutosh Dhekne. Esense: Communication through en-
ergy sensing. In Proceedings of the 15th Annual International Conference on Mobile
Computing and Networking, MobiCom ’09, pages 85–96, 2009.
[15] Qun Li Yifan Zhang. Howies: A holistic approach to zigbee assisted wifi energy sav-
ings in mobile devices. In Proceedings of the 32nd IEEE International Conference
on Computer Communications (INFOCOM 2013), 2013.
[16] Xiuzhen Guo, Xiaolong Zheng, and Yuan He. Wizig: Cross-technology energy
communication over a noisy channel. In Proceedings of IEEE INFOCOM 2017.
[17] Zicheng Chi, Zhichuan Huang, Yao Yao, Tiantian Xie, Hongyu Sun, and Ting Zhu.
Emf: Embedding multiple flows of information in existing traffic for concurrent
communication among heterogeneous iot devices. In Proceedings of IEEE INFO-
COM 2017.
99
[18] Song Min Kim and Tian He. Freebee: Cross-technology communication via free
side-channel. In The 21st Annual International Conference on Mobile Computing
and Networking (MobiCom), 2015.
[19] Zicheng Chi, Yan Li, Hongyu Sun, Yao Yao, Zheng Lu, and Ting Zhu. B2w2: N-
way concurrent communication for iot devices. In Sensys. ACM, November 14-16,
Stanford, CA, USA 2016.
[20] Zhijun Li and Tian He. Webee: Physical-layer cross-technology communication via
emulation. In MobiCom ’17. ACM, 2017.
[21] Xiuzhen Guo, Yuan He, Jia Zhang, and Haotian Jiang. Wide: Physical-level ctc
via digital emulation. In Proceedings of the 18th International Conference on In-
formation Processing in Sensor Networks, IPSN ’19, pages 49–60, New York, NY,
USA, 2019. ACM.
[22] Eugene Chai, Karthik Sundaresan, Mohammad A Khojastepour, and Sampath
Rangarajan. Lte in unlicensed spectrum: are we there yet? In Proceedings of
the 22nd Annual International Conference on Mobile Computing and Networking,
pages 135–148. ACM, 2016.
[23] S. Wang, S. M. Kim, and T. He. Symbol-level cross-technology communication
via payload encoding. In 2018 IEEE 38th International Conference on Distributed
Computing Systems (ICDCS), pages 500–510, July 2018.
[24] Xiuzhen Guo, Yuan He, Xiaolong Zheng, Zihao Yu, and Yunhao Liu. Lego-fi:
Transmitter-transparent ctc with cross-demapping. In IEEE INFOCOM 2019-
IEEE Conference on Computer Communications, pages 2125–2133. IEEE, 2019.
[25] multefire.org. MutleFire whitepapers. https://www.multefire.org/
white-papers/, 2019.
[26] MulteFire Alliance. Multefire release 1.0 technical paper: A new way to wireless.
white paper, Jan, 2017.
100
[27] Kaishun Wu, Haoyu Tan, Yunhuai Liu, Jin Zhang, Qian Zhang, and Lionel M Ni.
Side channel: Bits over interference. IEEE Transactions on Mobile Computing,
11(8):1317–1330, 2012.
[28] LTE2B supplementary material. Available at
https://github.com/liux4189/LTE2B.
[29] Evolved Universal Terrestrial Radio Access. Multiplexing and channel coding (re-
lease 8), 3gpp ts 36.212 v8. 7.0, 2009.
[30] Tom Richardson and Ruediger Urbanke. Modern Coding Theory. Cambridge Uni-
versity Press, New York, NY, USA, 2008.
[31] Evolved Universal Terrestrial Radio Access. 3gpp ts 36.322 v10. 0.0, dec. 2012.
LTE Advanced.
[32] Navid Nikaein, Mahesh K. Marina, Saravana Manickam, Alex Dawson, Raymond
Knopp, and Christian Bonnet. Openairinterface: A flexible platform for 5g re-
search. SIGCOMM Comput. Commun. Rev., 44(5):33–38, October 2014.
[33] ”MATLAB”. Matlab lte system toolbox., 2018.
https://www.mathworks.com/help/lte.
[34] cisco.com. Cisco Global Cloud Index: Forecast and Methodology.
https://www.cisco.com/c/en/us/solutions/collateral/service-provider/
global-cloud-index-gci/white-paper-c11-738085.html, 2019.
[35] Sears. 2.4GHz wireless digital video baby monitor. https://www.sears.com/
xcsource-2.4-ghz-wireless-digital-video-baby/p-A026482260, 2020.
[36] Sarah Clark. TazTag unveils first Android phone with NFC
and ZigBee. https://www.nfcw.com/2012/02/26/313800/
taztag-unveils-first-android-phone-with-nfc-and-zigbee/, 2012.
[37] advantech.com. advantech IoT Gateway. http://select.advantech.com/
iotgateway/, 2019.
101
[38] Pew Research Center. Internet/Broadband Fact Sheet. https://www.
pewresearch.org/internet/fact-sheet/internet-broadband/, 2019.
[39] iPass. The Rise of Wi-Fi First. https://www.ipass.com/wp-content/uploads/
2017/03/iPass-White-Paper-WiFi-First.pdf, 2017.
[40] eMarketer. US Adult Wearable Users and Penetration. https://www.emarketer.
com/content/wearables-2019, 2018.
[41] Matthias Schulz, Daniel Wegemer, and Matthias Hollick. Nexmon: The c-based
firmware patching framework, 2017.
[42] Semtech. Using the SX1280/SX1281 in Low Power Applications. https://www.
semtech.com/products/wireless-rf/24-ghz-transceivers/sx1280, 2019.
[43] Texas Instruments. CC2650 SimpleLink™ Multistandard Wireless MCU. http:
//www.ti.com/lit/ds/symlink/cc2650.pdf.
[44] Semtech. Semtech SX1280. https://www.semtech.com/products/wireless-rf/
24-ghz-transceivers/sx1280, 2020.
[45] Xiuzhen Guo, Yuan He, Xiaolong Zheng, Liangcheng Yu, and Omprakash Gnawali.
Zigfi: Harnessing channel state information for cross-technology communication. In
Proceedings of IEEE INFOCOM 2018, 2018.
[46] Sarah J Johnson. Introducing low-density parity-check codes. University of New-
castle, Australia, page V1, 2006.
[47] L. Johnson. Walgreens launches iBeacon pilot to bolster coupon per-
sonalization. https://www.retaildive.com/ex/mobilecommercedaily/
walgreens-tests-ibeacon-to-bolster-mobile-coupon-personalization-awareness/,
2017.
[48] M. Owen. NFL, NBA to tap into iPhone to boost fan ex-
perience in stadiums. https://www.businessinsider.com/
nfl-ibeacons-in-new-york-for-super-bowl-2014-2, 2019.
102
[49] SPEC INDIA. Beacons At Airport: The Next Big Thing
In The Airlines Industry. https://www.spec-india.com/blog/
beacons-at-airport-the-next-big-thing-in-the-airlines-industry,
2019.
[50] Yi Ding, Liu Ling, Yang Yu, Liu Yunhuai, He Tian, and Zhang Desheng. From
conception to retirement: a lifetime story of a 3-year-old operational wireless beacon
system in the wild. In 18th USENIX Symposium on Networked Systems Design and
Implementation (NSDI 21).
[51] Gimbal Proximity Beacons. https://gimbal.com/beacons/.
[52] Forrester. Pick The Right Location Technologies To Support Customer Experi-
ence And Operational Initiatives. https://www.forrester.com/report/Pick+
The+Right+Location+Technologies+To+Support+Customer+Experience+And+
Operational+Initiatives/-/E-RES120001, 2016.
[53] Apple. iBeacon. https://developer.apple.com/ibeacon/.
[54] OpenWrt Project. https://openwrt.org/, 2019.
[55] WiBeacon Github Repository. https://github.com/liux4189/WiBeacon.git.
[56] S. Bernstein. The realities of installing iBeacon to scale. https:
//www.brooklynmuseum.org/community/blogosphere/2015/02/04/
the-realities-of-installing-ibeacon-to-scale/, 2015.
[57] G. Bentinck. The benefits of integrated access point bea-
con technology. https://meraki.cisco.com/blog/2015/01/
the-benefits-of-integrated-access-point-beacon-technology/, 2015.
[58] Apple Developer Forums. Is there any API available for iOS to scan WiFi networks.
https://forums.developer.apple.com/thread/39204.
[59] Justin Manweiler and Romit Roy Choudhury. Avoiding the rush hours: Wifi energy
management via traffic isolation. In Proceedings of the 9th international conference
on Mobile systems, applications, and services, pages 253–266. ACM, 2011.
103
[60] Tianxing Li, Chuankai An, Ranveer Chandra, Andrew T Campbell, and Xia Zhou.
Low-power pervasive wi-fi connectivity using wiscan. In Proceedings of the 2015
ACM International Joint Conference on Pervasive and Ubiquitous Computing,
pages 409–420, 2015.
[61] Meraki. WLAN Location Analytics. https://documentation.meraki.com/MR/
Monitoring_and_Reporting/Location_Analytics.
[62] H. Jiang and H. Jamba. To Solve China’s Bike-Sharing Woes, Hangzhou and
Shanghai Turn to Bluetooth and Geofencing. https://thecityfix.com/blog/
solve-chinas-bike-sharing-woes-hangzhou-shanghai-turn-bluetooth-geofencing-hui-jiang-harshita-jamba/,
2019.
[63] Yongrui Chen, Zhijun Li, and Tian He. Twinbee: Reliable physical-layer cross-
technology communication with symbol-level coding. In Proceedings of IEEE IN-
FOCOM 2018, 2018.
[64] Zhijun Li and Tian He. Longbee: Enabling long-range cross-technology communi-
cation. In Proceedings of IEEE INFOCOM 2018, 2018.
[65] ASUS GT-AX11000. http://en.techinfodepot.shoutwiki.com/wiki/ASUS_
GT-AX11000.
[66] Netgear RAX200. http://en.techinfodepot.shoutwiki.com/wiki/Netgear_
RAX200_(Nighthawk_Tri-Band_AX12).
[67] Buffalo WXR-5950AX12. http://en.techinfodepot.shoutwiki.com/wiki/
Buffalo_WXR-5950AX12).
[68] IEEE Computer Society LAN/MAN Standards Committee et al. Ieee standard
for information technology-telecommunications and information exchange between
systems-local and metropolitan area networks-specific requirements part 11: Wire-
less lan medium access control (mac) and physical layer (phy) specifications. IEEE
Std 802.11ˆ, 2007.
104
[69] Kyoung-Hak Jung, Yuepeng Qi, Chansu Yu, and Young-Joo Suh. Energy efficient
wifi tethering on a smartphone. In IEEE INFOCOM 2014-IEEE Conference on
Computer Communications, pages 1357–1365. IEEE, 2014.
[70] WiFi Alliance. What is off-channel scanning for Wi-Fi access
points (APs)? https://www.wi-fi.org/knowledge-center/faq/
what-is-off-channel-scanning-for-wi-fi-access-points-aps, 2019.
[71] Xfinity. What are Xfinity WiFi Hotspots and how do I connect? https://
www.xfinity.com/mobile/support/article/xfinity-mobile-wifi-hotspots,
2019.
[72] GL-AR750. https://www.gl-inet.com/products/gl-ar750/.
[73] i8 Beacon. https://www.minew.com/bluetooth-beacons/i8-diamond-beacon.
html.
[74] Tcpreplay. https://tcpreplay.appneta.com/, 2019.
[75] Android Beacon Library. https://altbeacon.github.io/
android-beacon-library/).