2018 IEEE 26th International Conference on Network Protocols
Networking Support For Physical-Layer
Cross-Technology Communication
Shuai Wang† , Zhimeng Yin† , Zhijun Li‡ , and Tian He†
† Department of Computer Science and Engineering, University of Minnesota, U.S.
‡ School of Computer Science and Technology, Harbin Institute of Technology, China.
{wang3367, yinxx283, tianhe}@umn.edu, lizhijun.hit@gmail.com
Abstract—Recent research on physical layer cross technology
communication (PHY-CTC) brings a timely answer for escalated
wireless coexistence and open spectrum movement. PHY-CTC
achieves direct communication among heterogeneous wireless
technologies (e.g.,WiFi, Bluetooth, and ZigBee) in physical layer
and thus brings communication support for coexistence service
such as spectrum management and IoT device control. To put
PHY-CTC into service, however, there still exists a gap due to
its transmission failure and asymmetric link (i.e., one-way PHY-
CTC) issues. In this paper, we propose NetCTC – the first net-
working support design for PHY-CTC to establish feedbacks (e.g.,
ACKs) and thus meet the upper layer networking requirements
in heterogeneous unicast, multicast and broadcast. The core
design of NetCTC is a real-time interaction mechanism which
achieves reliable, transmission efficient and parallel interactive
communication among heterogeneous devices. We implement and
evaluate NetCTC on commodity devices (Laptops with Atheros
AR2425 WiFi NIC, smart phones with Broadcom BCM4330 WiFi
chip and MicaZ CC2420) and the USRP-N210 platform. Our
extensive evaluation demonstrates that NetCTC achieves reliable
bidirectional cross technology communication under a full range
of wireless configurations including stationary, mobile and duty-
cycled settings.
I. I NTRODUCTION
Wireless technologies have been widely used in applications
such as personal communication, mobile internet surfing,
and smart home automation. To accommodate requirements
from these different applications (e.g., range, throughput, and
energy), multiple heterogeneous technologies including WiFi,
BlueTooth and ZigBee have been proposed and achieved great
success in their respective applications. With the continuous
growth of wireless devices, however, these technologies now
increasingly become victims of their own success since they
are largely ignorant of each other. This leads to operations
that are non-cooperative, or even disruptive to each other. For
example, coexisting wireless technologies compete with each
other to preempt channels and they destroy packets of others
with their own, causing significant spectrum inefficiency.
To address the coexistence issue among heterogeneous tech-
nologies, researchers propose Physical-layer Cross Technology
Communication (PHY-CTC), which builds direct communi-
cation among heterogeneous technologies via signal emula-
tion, despite their incompatible physical-layer modulation [1],
[2]. The PHY-CTC technique requires neither hardware nor
firmware changes in commodity devices, which eliminates ton-
s of multi-radio gateways and promises zero-cost fast deploy-
978-1-5386-6043-0/18/$31.00 ©2018 IEEE
DOI 10.1109/ICNP.2018.00042
ment on existing infrastructure. Most importantly, PHY-CTC
provides the communication support for explicit message (e.g.,
channel, device and sensing information) exchange among
heterogeneous technologies and thus brings great benefits to
upper layer applications including, but not limited to channel
coordination and IoT device management/control.
To obtain these benefits for upper layer applications, we
have to address several unique challenges introduced by PHY-
CTC. First, PHY-CTC is facing asymmetric link problem due
to emulation capability. For example, the WiFi commercial
device is able to emulate ZigBee signals but not vice ver-
sa [1]. Second, the signal emulation technique in PHY-CTC
inevitably introduces emulation errors which further leads to
transmission failures. Note that an ACK/ARQ between hetero-
geneous devices is challenging because of the heterogeneity
as well as the asymmetric link problem. The upper layer
applications may not even know which packet is lost.
In this paper, we aim to conquer the above challenges and
propose NetCTC – a networking support design for PHY-
CTC to meet the requirements of upper layer protocols (e.g.,
unicast, multicast, and broadcast). In a nutshell, NetCTC is
an interaction mechanism between heterogeneous technologies
which consists of three components. First, NetCTC introduces
randomness in PHY-CTC packets to eliminate packet se-
quence. It encodes PHY-CTC packets with Fountain codes [3],
[4] and continuously transmits the rateless stream of encoded
packets to receivers, and thus reducing the number of ACKs
from one ACK for each packet to one ACK for a batch of
packets. Second, since acknowledgements are necessary in
cross technology communication scenarios, a one-bit CTC-
ACK is designed to notify heterogeneous sender whether
the receiver receives enough packets for successful decoding.
Finally, a dynamic CTC link model is proposed based on
the feedback of one-bit CTC-ACK. This link model helps
heterogeneous senders decide the optimal stop condition to
eliminate both unnecessary (re)transmissions and ACKs.In
summary, our technical contributions are as follows:
• Leveraging upon physical layer CTC, we propose
NetCTC, the first networking support for heterogeneous
networks. NetCTC addresses the transmission failure and
one-way communication issue of PHY-CTC and makes
PHY-CTC meet the requirements of upper layer proto-
cols including transmission efficiency and reliability in
259
 unicast, multicast and broadcast, which is an important
step towards real-world applications.
• We address a few unique challenges in networking sup-
port of CTC for upper layer applications, which include
(i) packet sequence elimination using Fountain codes,
(ii) closed-loop feedback with one-bit CTC-ACK, (iii)
transmission control with CTC link modeling, (iv) one-
to-many CTC covering multiple receivers, and (v) con-
current feedbacks from multiple receivers. These tech-
niques provide sufficient support to meet the networking
requirement from upper layers.
• We implement and evaluate NetCTC on commodity de-
vices (Atheros AR2425 WiFi NIC and MicaZ CC2420)
and the USRP-N210 platform. Our comprehensive eval-
uation reveals that NetCTC achieves a reliable, trans-
mission efficient and parallel cross technology commu-
nication under a full range of wireless configurations,
etc.), despite their incompatible physical-layer modulation.
The core technique of PHY-CTC is software-based signal
emulation, which utilizes one wireless technology’s signal
(e.g., WiFi signal) to emulate another’s (e.g., ZigBee signal)
without hardware or firmware changes. The pioneer research
WEBee [1] demonstrates that emulated signals from WiFi
can be successfully detected and decoded by ZigBee. As
shown in Figure 1, WEBee constructs the payload of a WiFi
frame elaborately so that the RF waveform of the payload
resembles that of ZigBee signals. When such a WiFi frame
is received by ZigBee devices, the WiFi header, preamble,
and trailer are ignored by ZigBee as noise, while the payload
will successfully pass the ZigBee preamble detection and
the emulated ZigBee frame will be then demodulated at the
ZigBee receiver.
^ŵĂƌƚ,ŽŵĞ
^ĞƌǀŝĐĞƐ ^ĞƌǀŝĐĞƐ ^ĞƌǀŝĐĞƐ
^ŵĂƌƚ,ŽŵĞ
^ĞƌǀŝĐĞƐ ^ĞƌǀŝĐĞƐ ^ĞƌǀŝĐĞƐ

tŝƚŚ'ĂƚĞǁĂLJƐ WWϭ WWϮ WWϯ tŝƚŚW,zͲd WWϭ WWϮ WWϯ

including stationary, mobile, and duty-cycled settings.
• To examine the networking support for upper layer ser-
vice, we evaluate NetCTC on one-to-one IoT device con- /ŶƚĞƌŶĞƚ
/ŶƚĞƌŶĞƚ
W,z W,z
trol and one-to-many neighbor discovery applications. In d 灅 灅 d
the one-to-one NetCTC application, we embed NetCTC DƵůƚŝͲǀĞŶĚŽƌ'ĂƚĞǁĂLJƐ
灅 灅 tŝ&ŝ W
/ŶƚĞƌŶĞƚ,Ƶď
into Nexus 5 smart phones with Broadcom BCM4330 ŝŐĞĞĞǀŝĐĞƐ W,z W,z
ŝŐĞĞĞǀŝĐĞƐ

d d ůƵĞdŽŽƚŚ ĞǀŝĐĞƐ

WiFi chip to control ZigBee Smart bulb directly. The ůƵĞdŽŽƚŚ ĞǀŝĐĞƐ

experiment results show that NetCTC achieves a reliable (a) Smart home w/ gateway (b) Smart home w/ CTC
control with 62% fewer transmissions. In the one-to-many
Fig. 2. An application of CTC in smart home
application, we use WiFi to help ZigBee devices discover
their neighbors. Compared with traditional approaches,
NetCTC saves 94% of the neighbor discovery time. B. The Benefits of CTC
The paper is organized as follows. Section II presents
Given the trends of escalated wireless coexistence, PHY-
preliminaries. The design overview is presented in Section III,
CTC provides a timely communication paradigm by sup-
followed by basic and advanced designs in Sections IV and V.
porting direct message/data exchange among heterogeneous
Section VI evaluates the performance. We summarize related
wireless technologies. PHY-CTC has several unique features
work in Section VII. Section VIII concludes the paper.
including (i) transparency to today’s networks and will not

 disturb existing traffic, (ii) compatibility to existing infras-

 tructure and can be implemented directly on off-the-shelf
heterogeneous devices, and (iii) capability to achieve the
 

communication requirements (e.g., maximum communication

 
rate) defined in existing standards. With these features, PHY-

 CTC has great potential to improve existing coexistent wire-

 

 less networks in areas including, but not limited to channel


coordination, IoT device management and cyber physical
  control, by providing explicit message (e.g., channel, device
and sensing information) exchange. For example, in the smart
Fig. 1. PHY-CTC with signal emulation [1] home scenario in Figure 2, PHY-CTC enables to leverage
upon the deployed WiFi AP to connect smart ZigBee and
II. P RELIMINARIES Bluetooth devices without deploying gateways. The connec-
In this section, we first introduce some preliminaries about tivity among heterogeneous devices further enables us to
the PHY-CTC paradigm. Then, we summarize the benefits as remotely manage/control IoT devices, such as smart bulbs,
well as limitations of PHY-CTC. temperature/humidity controller, and audio equipment, through
our phone.
A. What’s CTC
Cross technology communication (CTC) is defined as direct C. The Limitations of PHY-CTC
communication (i.e., message/data exchange) among hetero- PHY-CTC’s significant benefits and great potential oppor-
geneous wireless devices (e.g., WiFi, BlueTooth, ZigBee and tunities come with some limitations including (i) transmission

260
failures due to signal emulation errors and (ii) asymmetric
links due to signal emulation infeasibility.
Transmission Failures: in the signal emulation process of
PHY-CTC, due to the restrictions of technology standards
(e.g., 802.11g and 802.15.4), not all positions in the payload is
allowed to freely change (e.g., due to cyclic prefix in 802.11)
and not all signals can be freely generated (e.g., due to QAM
quantization in 802.11). Therefore, the emulated signal may
not be perfectly match with the target signal, which further
leads to transmission failures.
Asymmetric Links: PHY-CTC adopts software based signal
emulation under hardware restrictions, which may lead to
the asymmetric link problem due to emulation infeasibility.
Existing research demonstrates that PHY-CTC from WiFi
and BlueTooth to ZigBee is available on commodity devices
without any hardware change but not vice versa [1].
Due to these limitations, there still exists a gap between
PHY-CTC and real-world service. For example, in the smart
home scenario in Figure 2, without the reverse feedbacks
from ZigBee/BlueTooth, it is unknown whether PHY-CTC
has successfully finished the control task. In this paper, we
aim to address the transmission failure and asymmetric link
issues of PHY-CTC [1] and provide networking support to
achieve efficient bidirectional cross technology communica-
tion. Compared with state of the art, the technical advantages
of NetCTC is summarized in Table I. NetCTC achieves high-
throughput two-way communication between heterogeneous
devices without extra hardware costs (e.g., gateways).
Spectrum
Expense Throuput Bidirectionality
Efficiency
√ ACKs). With the help of Fountain codes, the number of ACKs
Gateway Medium Medium High
ESense [5] Low Low Low ×
√
FreeBee [6] Low Medium Low
WEBee [7] Low High High ×
√ introduce randomness to each packet and eliminate packet
NetCTC Low High High
TABLE I
C OMPARISON OF N ET CTC AND EXISTING CTC SOLUTIONS
III. D ESIGN OVERVIEW
This section presents the design objective and challenges,
followed by the architecture of NetCTC.
A. Design Objective and Challenges
Despite the encouraging capability of cross technology
communication in physical layer, there still exist a gap be-
tween PHY-CTC and upper layer applications. We aim to fill
this gap by providing networking support for PHY-CTC to
meet the networking requirement from upper layers. We note
that the heterogeneity leads to some fundamentally different
challenges compared with networking designs in homogeneous
networks, calling for unique designs in NetCTC. Specifically,
the phenomenon that transmission failure and asymmetric link
issues appear at the same time is prominent in heterogeneous s-
cenarios. This phenomenon leads to the dilemma that receivers
can not (efficiently) send back the transmission failure (i.e.,
261
lost packets) information. In addition, due to the difference of
wireless standards at sender and receiver (e.g., MAC and chan-
nel access precision), the timing of the interaction should be
designed carefully to make sure that packets are successfully
transmitted/received. Such an interaction mechanism becomes
more challenging when multiple heterogeneous devices require
networking support at the same time.
澷濈澷澡濄澿濈濓澥
澷濈澷澡濄澿濈濓澦
灅
澷濈澷澡濄澿濈濓 煋
澷濈澷澡澵澷澿澔濆澹濅
濋濝澺濝 濃濢濙澡澶濝濨澔澷濈澷澡澵澷澿 濎濝濛澶濙濙
澸濙濪濝濗濙 澸濙濪濝濗濙
Fig. 3. The architecture of NetCTC between WiFI and ZigBee devices
B. NetCTC Architecture
Figure 3 shows the architecture of NetCTC. Specifically,
NetCTC provides a networking support of two-way interaction
mechanism between WiFi and ZigBee devices. As shown
in Figure 3, at the sender side (i.e., the WiFi device), we
apply Fountain codes to each cross technology communication
(CTC) transmission. The introduction of Fountain codes is
used to address the issue that heterogeneous receivers can not
efficiently send back the transmission failure information (e.g.,
are reduced from one ACK for each packet to one ACK for a
batch of encoded packets. Furthermore, since Fountain codes
sequence, it is not necessary for receivers to notify the exact
lost packet. Instead, receivers only have to notify the sender
whether they have received enough packets for successful
decoding, which requires only one bit information.
In our NetCTC design, when the sender sends out enough
encoded transmissions, it will send out a “CTC-ACK REQ”
message which is designed to (i) notify receivers to send
back ACKs and (ii) clear the channel for cross technology
transmissions from low-power devices such as ZigBee. When
receivers get the request, it will send back a “One-Bit CTC-
ACK” message to let the sender know whether they have
received enough packets for successful decoding. The sender
will utilize the one bit information to (i) decide whether it
should starts a new batch of packets or not, and (ii) update
the timing of sending out “CTC-ACK REQ” messages for
future transmissions.
Up to now, we have briefly introduced the general process
of the interaction mechanism in NetCTC as well as the rational
behind it. In the following, we will introduce design details
including (i) how to apply Fountain codes to CTC packets,
(ii) how to achieve One-Bit CTC-ACK, and (iii) how to
decide the timing for the sender to stop deluging encoded
packets and send out the “CTC-ACK REQ” message, in WiFi preamble and header until it detects the emulated ZigBee
Section IV-A, IV-B, and IV-C respectively. preamble and considers it as a normal ZigBee packet. Our
design is thus compatible to current ZigBee standard.
IV. BASIC N ET CTC For a transmitted CTC packet, if it passes the cyclic redun-
Our NetCTC design provides networking support for both dancy check (CRC) at the ZigBee receiver, ZigBee buffers this
one-to-one (i.e., unicast) and one-to-many (i.e., multicast and packet for the later decoding. Otherwise, the ZigBee receiver
broadcast) cross technology communication. For sake of clar- throws this packet and marks it as a lost packet. By doing
ity, in the basic design, we focus on introducing one-to-one this, the ZigBee receiver has collected a subset of successfully
NetCTC. We will introduce how to achieve (i) networking transmitted CTC packets, whose number is denoted as N  .
support for one-to-many cross technology communication and Since the coding matrix is known in advance, it is able to
(ii) parallel acknowledgements, on advanced designs in Sec- compute the source packets, if N  > K. As for the probability

tion V-A and V-B respectively. of decoding failure, it is bounded by δ(E) < 2−(N −K) , which
drops significantly with the increase of correctly received
tŝ&ŝ tŝ&ŝ packets; for example, the error probability is less than 0.1%
tŝ&ŝWĂLJůŽĂĚ
WƌĞĂŵďůĞ ,ĞĂĚĞƌ when N  = K + 10. As a result, Fountain code is able
to increase the decoding reliability by sending out a larger
ŝŐĞĞ ŝŐĞĞ & ŽĚĞĚŝŐĞĞ number of coded packets, although some of them can be lost
WƌĞĂŵďůĞ ,ĞĂĚĞƌ ,ĞĂĚĞƌ WĂLJůŽĂĚ due to the unreliability of CTC.

ŵƵůĂƚĞĚŝŐĞĞWĂĐŬĞƚ LJtŝ&ŝ  
 

Fig. 4. The structure of cross technology communication (CTC) packets




 







with Fountain code
A. CTC-PKT with Fountain Code
As introduced in previous sections, PHY-CTC has inherent
error in signal emulation, and is prone to packet error. For
example, in the state-of-the-art WEBee [1], the first PHY-CTC,
the success decoding rate is about 50%∼60%. To address this
transmission failure issue, we adopt Fountain code [3], [4] in
our design to improve the overall reliability.
Fountain code ensures the successful decoding of the re-
ceived data, if the overall length of the received data is larger
than the input data length. With Fountain code, the sender
(e.g., the WiFi device) generates the N encoded packets as the
linear combinations of K source packets. To offer reliability,
N > K, meaning that Fountain code generates more coded
packets than source packets.
The structure of a cross technology communication (CTC)
packet with Fountain code is shown in Figure 4. From the
figure, we can see that the WiFi device transmits a normal
WiFi packet including preamble, header, and payload while
its payload is used to emulate a standard ZigBee packet.
Specifically, the emulated ZigBee packet has a ZigBee header
as well as a Fountain code (FC) header which includes
encoding vector and batch information. Such a CTC trans-
mission is transparent to legacy networks, in the sense that
CTC packets with Fountain code is recognized by commodity
ZigBee devices transparently as a legitimate ZigBee frame.
The packet structure makes our design compatible to exist-
ing standards. ZigBee devices can not differentiate emulated
packets (sent by WiFi) from regular ZigBee devices. When
a WiFi device transmits regular WiFi packets, these packets
will be considered as noise by ZigBee devices since they
cannot pass ZigBees preamble detection. When a WiFi device
transmits a NetCTC packet, the ZigBee device will ignore
262
 
   

Fig. 5. Data recovery via Fountain Code
Figure 5 depicts an example of utilizing Fountain code in
PHY-CTC scenarios. In this example, there are five source
packets, while Fountain encoder generates 12 coded packets.
Although the receiver only receives 7 packets due to the packet
loss, it has received more packet than the source packets, thus
able to successfully demodulate.
B. One-Bit CTC-ACK
When Fountain codes are applied to PHY-CTC packets, only
one ACK is required for a batch of packets which significantly
reduces the requests of sending back ACKs. In addition, we
only need to include one bit information in the ACK to tell
the heterogeneous sender whether the receiver has successfully
received enough packets for decoding.
Due to the heterogeneous PHY layers of ZigBee and WiFi
as well as ZigBee devices’ capability on signal emulation,
the WiFi device can not decode the ZigBee packets directly.
However, it can sample the RSSI, which is a mandatory
process for the CSMA purpose. By sampling the RSSI, the
WiFi is able to detect the start and the end of the ZigBee
packet for calculating the transmission duration, and thus
detect ACKs from ZigBee. In addition, since the ZigBee
utilizes the OQPSK modulation, the amplitude remains almost
the same during the transmission. In the CTC-ACK design, we
utilize this feature for reliably detecting transmitted ZigBee
packets at the WiFi side.
 6KRUW=LJ%HH3DFNHW /RQJ =LJ%HH3DFNHW
qd be the decoding failure rate introduced by PHY-CTC.
Then the probability that a transmission is considered to
7LPH 7LPH
be failed is given by (qt + (1 − qt )qd ). Here the second
term (1 − qt )qd corresponds to the event that the packet is
 
566,G%P

566,G%P

XV

    
(a) ACK with ‘0’
Fig. 6. One-bit ACK with information ‘0’ and ‘1’
Figure 6 depicts the key idea of sending ACK ‘0’ and
ACK ‘1’. The ZigBee device sends ‘0’ (as demonstrated in
the upper part of Figure 6(a)) with one short ZigBee packet
to represent that it has received enough packets. In the same
way, it sends out one long ZigBee packet to represent ACK ‘1’
(as demonstrated in the upper part of Figure 6(b)), meaning
that it still needs more packets for successful decoding. In the
CTC-ACK design, we choose packet sizes which are rarely
introduced by normal ZigBee traffic for distinguishing the
ACK from background ZigBee communication.
Note that the WiFi AP waits 10ms to detect the one-bit
CTC-ACK. This is because that the ZigBee device needs to
perform CSMA before accessing the channel, which takes
about 10ms at the worst case for one transmission. Since the
packet rate of ZigBee is very low, the probability that a regular
ZigBee transmission appears at the same time when a one-
bit CTC-ACK is transmitting within the specified 10ms time
period is low.
We now introduce how to achieve the key idea in Figure 6 in
implementation. The lower parts of Figure 6(a) and 6(b) depict
the RSSI samples of ZigBee packets received at WiFi devices.
These RSSI samples are used to construct one-bit CTC-ACKs.
Specifically, to send CTC-ACK with ‘0’, the ZigBee device
sends a designed short packet, whose duration is about 300us.
Since the RSSI value of noise is less than -90dbm which are
much lower than that of packets. The WiFi device is thus
able to obtain the CTC-ACK information ‘0’ by detecting the
amplitude of RSSI. In Figure 6(b), a long ZigBee packet is
transmitted, leading to a long duration (i.e., 500us) of high
RSSI samples at the WiFi side. The WiFi device recognizes
the CTC-ACK with ‘1’.
C. NetCTC Link Model
We now introduce the link model of cross technology
communication when Fountain codes and one-bit CTC-ACK
are applied. Let P r{τ = t} be the probability that the hetero-
geneous sender (e.g., WiFi) needs t transmissions to deliver a
PHY-CTC packet encoded with Fountain codes to the receiver
(e.g., ZigBee). Here, τ is the expected number of transmissions
required to successfully deliver K linearly independent coded
packets to the receiver. In the CTC scenario, a sender has to
resend packets due to two reasons. First, transmitted packets
are physically lost in the air. Second, although the packets
are received, the receiver can not decode the packet due to
emulation errors. Let qt be the transmission loss rate and

 XV successfully received with probability (1 − qt ) but failed to
 decode with probability qd .
    
In the cross technology communication with Fountain
(b) ACK with ‘1’ codes, the probability that the receiver can successfully obtain
a batch of K encoded packets with K transmissions is given
by P r{τ = K} = (1−(qt +(1−qt )qd ))K . Now, if K+1 trans-
missions are required to successfully obtain K original packets
at receivers, one of the first K coded packets must have
failed due to either transmission failure or decoding failure.
No matter which packet has failed, a new coded packet must
be retransmitted successfully in the (K + 1)th transmission.
The probability of this event is P r{τ = K + 1} = (K 1 )(qt +
(1 − qt )qd )(1 − (qt + (1 − qt )qd ))K−1 (1 − (qt + (1 − qt )qd )). In
general, the probability that K + i transmissions are required
to let a receiver successfully decode all K coded packets is
given by
P r{τ = K + i}
= (K+i−1 )(qt + (1 − qt )qd )i (1 − (qt + (1 − qt )qd ))K .
i
In our NetCTC design, the maximum number of retransmis-
sions for one packet is limited to R (e.g., R = 7). The expected
number of transmissions to let a receiver successfully obtain
a batch of K packets is given by

R(K−1)
E{τ } = (K + i)P r{τ = K + i}. (1)
i=0
Up to now, we obtain E{τ } – the expected number of
transmissions in the interaction mechanism in Figure 3. Note
that in Eq. (1), the decoding failure rate – qd is caused by
emulation error which is uniquely decided by the PHY-CTC
mechanism. For example, the value of qd is ranged from
0.4 to 0.5 in WEBee-type PHY-CTC [1]. Eq. (1) is used to
compute the initial value of expected transmissions E{τ }ini
as well as the minimal expected number of transmissions
E{τ }min . In our NetCTC design, the values of E{τ }ini and
E{τ }min is given by E{τ }ini = E{τ }{qt =0.5,qd =0.45} and
E{τ }min = E{τ }{qt =0,qd =0.4} respectively. When the sender
receives one-bit CTC-ACK from the receiver, it updates its
current value of τ with the following rules:
1
τ ← τ +  τ , ACK = 1;
2 (2)
τ ← max{E{τ }min , τ − 1}, ACK = 0;
The physical meaning of Eq.(2) is that (i) the sender
will transmit another  12 τ  packets when the receiver fails
to decode the K original packets (i.e., one-bit CTC-ACK
equals one), and (ii) the sender will reduce the number of
transmissions by one when the receiver successfully obtain
the K original packets (i.e., one-bit CTC-ACK equals zero).
263

Fig. 7. Statistics of receiving probability: the receiver with a smaller τ
receives about 98% of the batches earlier or at the same time than the receiver
with a higher τ .
V. N ET CTC W ITH E NHANCED F EATURES
In basic NetCTC, we achieve the interaction mechanism
between one WiFi device and one ZigBee device. In this
section, we aim to enhance the basic NetCTC by providing
extra features including one-to-many CTC and parallel ACKs.
A. One-To-Many CTC
To support CTC from one sender (e.g., WiFi device) to
multiple receivers (e.g., ZigBee devices), a direct solution is




for further improving the performance of one-to-many CTC.
In the basic design, when the ZigBee receivers have received
enough packets for successful decoding, they send out one bit
CTC-ACK (i.e., ‘0’) to notify the WiFi sender to transmit
a new batch of packets. When there are multiple ZigBee
receivers, these devices may compete with each other for the
channel access to send back one-bit CTC-ACK, which leads
to the ACK broadcast storm problem.
To alleviate this problem, we develop the parallel ACK
technique, where ZigBee receivers send back the CTC-ACKs
on different channels simultaneously for improving the ACK
efficiency. This is based on the observation that (i) one WiFi
channel has the bandwidth of 20MHz while one ZigBee
channel has the bandwidth of 2MHz, and (ii) one WiFi channel
(e.g., WiFi channel 6) is completely overlapped with three
ZigBee channels (e.g., ZigBee channel 17, 18, and 19). As
a result, the WiFi sender is able to capture concurrent CTC-
ACKs (i.e., RSSI) sent from different ZigBee channels for
detecting multiple CTC-ACKs at the same time. To differenti-
ate CTC-ACKs from parallel ZigBee devices, the WiFi device
sends messages to ZigBee devices to allow them to send back
CTC-ACKs with specified transmission durations.
to assign multiple one-to-one CTC (i.e., basic NetCTC) in 


different time slots. This direct solution becomes inefficient
when the number of receiver increases. The interaction latency
increases since the receiver sends back ACKs one by one after
random backoff and the sender will not start a new session
until all the ACKs are received.
We noted that in the one-to-many CTC with Fountain codes,
receivers with smaller value of τ almost always obtain the K
original packets before those with larger value of τ . In other
words, when the receiver with the maximum τ obtain the K
original packets, it is highly possible that all the other receivers
have successfully obtained the K packets.
To further confirm this observation, we deploy 16 ZigBee
nodes near a WiFi sender, which broadcasts a CTC packet
(i.e., ZigBee packet) every 10ms. The total number of packet
broadcasts is 1000. The receivers keep the packet sequence
number and time stamp. The detail setting of this experiment
can be found in Section VI. After collecting the packet
reception trace, for each packet, we compare the reception
between each link pair.
Figure 7 shows that the ZigBee node with smaller value of
τ receives about 98% of the batches (i.e., K=10 packets in
the experiment) earlier or at the same time than the node with
larger value of τ . Based on this observation, the sender updates
the τ value in the initial stage using the direct solution. After
obtaining all receivers’ τ value, the sender selects the receiver
with maximum τ as the delegate to send back ACK, and thus
achieve one-to-many interaction without causing ACK storm
problem.
B. Parallel ACK
In this section, we introduce the parallel ACK technique,
which allows multiple receivers to send back ACKs in parallel
264
 


 


Fig. 8. WiFi detects parallel ACKs
Figure 8 depicts an example of using parallel ACKs on two
different ZigBee channels, i.e., ZigBee channel 17 and 19, for
two ZigBee receivers. Since the bandwidth of overlapped WiFi
channel 6 is much wider than that of ZigBee, it senses the con-
current transmission of two ZigBee CTC-ACKs transmitted at
different channels, thus recognizing parallel CTC-ACKs.
VI. E VALUATION
In this section, we evaluate the performance of NetCTC
across various domains, including (i) CTC performance com-
parison on throughput, latency, and the number of transmis-
sions, (ii) communication reliability, (iii) support in stationary,
mobile, duty-cycled, and parallel cross technology communi-
cation scenarios, and (iv) the example application of NetCTC
on unicast (i.e., IoT device management/control) and broadcast
(i.e., neighbor discovery).
A. Experiment Setting
Figure 9 shows the evaluation setting of NetCTC. We have
implemented NetCTC as a sender on the USRP-N210 platform
with 802.11 b/g PHY and a commodity WiFi card Atheros
AR2425. At the receiver side, we have tested the NetCTC
on 16 commodity ZigBee receivers (i.e., MICAz). We note
that NetCTC supports direct communication between hetero-
geneous commodity devices while USRP-N210 devices are

  


 

 濂濙濨澷濈澷澮澔濋濝澺濝 濇濙濢濘濙濦澔









 澜澵濨濜濙濦濣濧澔澵濆澦澨澦澩澝

濂濙濨澷濈澷澮澔濎濝濛澶濙濙澔
濆濙濗濙濝濪濙濦澔澜濁澽澷澵濮澝
濂濙濨澷濈澷澮澔濋濝澺濝
濇濙濢濘濙濦澔澜濉濇濆濄澝

  






 濂濙濨澷濈澷澮澔濎濝濛澶濙濙澔

濆濙濗濙濝濪濙濦澔澜濁澽澷澵濮澝

Fig. 9. The experiment setting of NetCTC. Fig. 10. Lab Fig. 11. Hallway







濂濙濨澷濈澷澮澔濎濝濛澶濙濙澔 




濆濙濗濙濝濪濙濦澔澜濁澽澷澵濮澝

濂濙濨澷濈澷澮澔濋濝澺濝
濇濙濢濘濙濦澔澜濉濇濆濄澝 


  
Fig. 12. Outdoor
used only for evaluation purpose to obtain low-level physical
layer information, such as the decoding failure rate (i.e., qd ),
which are inaccessible by commodity devices.
In the experiment, the Atheros AR2425 WiFi card (or
USRP-N210) transmits 1,000 NetCTC packets to the 16
MICAz nodes. The time interval between transmissions is
10ms. The transmit power of WiFi and ZigBee devices is set
to 20dBm and 0dBm respectively. The default transmission
distance is 4m. The maximum transmission unit of each
transmitted packet is adjust as follows: each NetCTC packet
consists of a 32-bit preamble, and a default frame payload of
25 bytes, resulting in about a 1ms duration, which is the typical
length of payload for ZigBee communications. The batch size
(i.e., K) is set to 16 in the experiment.
To accommodate the dynamics caused by wireless environ-
ment, we conduct the above experiment on stationary/mobile,
indoor/hallway/outdoor, and duty-cycled scenarios, as shown
in Figure 10, 11, and 12. To ensure statistical validity, the
experimental results of each scenario are the average values
of 10 rounds.
B. Compared Schemes and Metrics
We compare NetCTC with the following state of the art.
1) ESense [5] by K. Chebrolu et al, 2009.
2) FreeBee [6] by S. Kim et al, 2015.
3) WEBee [1] by Z. Li et al, 2017.
Among them, ESense [5] and FreeBee [6] are Packet-Level
cross-technology communication techniques while WEBee [1]
is a physical-layer cross-technology communication technique.
We use two metrics for the following performance evaluation.
1) Throughput – the total received bits of packets divided
by the time duration of each round of experiment.
2) Reliability – the number of successfully received and
decoded packets at receivers over the total number of
transmitted packets.
   
Fig. 13. Performance In Bit Rate Fig. 14. Reliability
C. Main Performance
The main experiment results is summarized in Figure 13
and 14.
1) Comparison with Packet-Level CTC: In Figure 13, we
compare the bit rate of NetCTC with the state-of-the-arts in-
cluding (i) packet level CTC, i.e., ESense [5] and FreeBee [6]
and (ii) physical layer CTC, i.e., WEBee [1] with different
number of transmissions. The bit rate of packet level CTC,
i.e., ESense and FreeBee, is about 9bps and 17bps with a
single CTC transmitter, while the bit rate of NetCTC is about
180kbps, 10, 000× the bit rate of FreeBee. In the following
evaluation, we focus on compare the performance of NetCTC
with physical layer CTC.
2) Comparison with Physical Layer CTC: The bit rate of
WEBee with one transmission is as high as 226kbps, which
is higher than that of NetCTC (i.e., 180kbps). The interaction
mechanism in NetCTC introduces some latencies (about 5ms
on average), which lowers the bit rate. WEBee does not have
the interaction mechanism and the reliability of WEBee with
one transmission is as low as 0.4, as shown in Figure 14.
The reliability of WEBee with six (re)transmission increases
to 0.92 while its bit rate drops to 37kbps. With the interaction
mechanism, NetCTC achieves almost 100% reliability.
In real-world applications, due to the lack of interaction
mechanisms, the only way for WEBee to achieve reliable
communication is sending packets with the maximum allowed
number of transmissions no matter packets are delivered or
not, which can not guarantee either efficiency or reliability.
In the following, we focus on investigating the achievable
throughput of NetCTC in reliable communication (i.e., ACKs
are required), where throughput is defined as the bits of
successfully delivered packets confirmed by receivers during
the experiment. Specifically, we study the impact of (i) net-
work size, (ii) transmission distance, (iii) payload length, (iv)
265
 Fig. 15. Impact of Network Size Fig. 16.
Fig. 18. Impact of Mobility Fig. 19.
mobility, (v) duty cycle and (vi) parallel communication on
NetCTC. We also evaluate the performance of NetCTC on
one-to-one (i.e., IoT device control) and one-to-many (i.e.,
neighbor discovery) applications.
D. Impact of Network Size
In this experiment, we explore the impact of network size
on our design. We evaluate the performance of NetCTC with
different number of receivers, ranging from 1 to 16. Figure 15
shows the throughput with different number of receivers. From
the figure, we can see that NetCTC’s throughput is 7.14kbps
when there are only one ZigBee receiver. The throughput
decreases to 2.83kbps when there are 16 receivers. It’s because
that NetCTC tries to reliably deliver a packet to all receivers
and the failure on some receivers causes more transmissions.
The total throughput of NetCTC increases gradually with the
increase of the number of receivers, indicating that NetCTC
works well in one-to-many scenarios.
E. Impact of Transmission Distance
We evaluate the performance of NetCTC with different
transmission distances in indoor (Figure 10), hallway (Fig-
ure 11), and outdoor (Figure 12) scenarios. Figure 16 shows
the throughput of NetCTC between the WiFi sender and
the ZigBee receiver under varying distances. With increasing
distances from 1 to 10 meters, the throughput drops slowly
from 6.58kbps to 6.07kbps in the indoor scenario. Similar
results are observed in the hallway/outdoor scenario as well,
where the throughput changes from 6.53kbps/6.56kbps to
6.15kbps/5.96kbps, indicating that signal attenuation will not
significantly degrade NetCTC’s performance.
Impact of Trans. Distance Fig. 17. Impact of Payload Length
Impact of Duty Cycle Fig. 20. Parallel Communication
F. Impact of Payload Length
Figure 17 plots the throughput of NetCTC with different
lengths of payload. As we can see in the figure, the throughput
of NetCTC is 7.27kbps, 6.9ykbps, 6.07kbps, 5.87kbps, and
5.096kbps respectively when the length of payload is 15, 20,
25, 30, and 35 bytes. The throughput drops since the decoding
failure rate (i.e., qd ) increases along with the increase of the
payload length. The experiment results suggest using small
packets in the applications of physical layer cross technology
communication.
G. Impact of Mobility
We also evaluate NetCTC with a mobile ZigBee receiver in
the three different scenarios (i.e., lab, hallway, and outdoor). In
this experiment, the moving speed varies from 1m/s to 8m/s.
Figure 18 shows that the throughput of NetCTC drops from
4.60kbps to 3.37kbps, from 4.60kbps to 3.36kbps, and from
5.21kbps to 3.72kbps in lab, hallway, and outdoor scenarios.
The average throughput of NetCTC is 3.64kbps, 3.82kbps,
and 4.29kbps in these three scenarios, indicating that NetCTC
works well under different wireless environments and different
levels of mobilities.
H. Impact of Duty Cycle
NetCTC is also evaluated using low-duty-cycle ZigBee re-
ceivers, which sleep most of the time and wake up periodically
to check for radioactivity. In this case, a sender needs to
transmit a train of repeated packets to wake up the receiver.
In our experiments, the duty-cycle ratios are set as 30%, 15%,
6%, 3%, and 2%. NetCTC keeps on sending out packets
from the WiFi sender until that the ZigBee receiver’s ACK
266
is received, which means that a ZigBee device is successfully WEBee transmits every control packet 7 times (due to lack
woken up by the WiFi device. We then measure the throughput of interaction mechanism) and achieves a 97% reliability. Our
during this process. The results are shown in Figure 19 where NetCTC design dynamically adjusts the number of retransmis-
we can see that NetCTC works well under a wide range of sions based on the feedback ACK and achieves reliable control
duty-cycle settings. with fewer transmissions.
I. Parallel Communication
Here we show that NetCTC can support two parallel com-
munications between WiFi and ZigBee. In the experiment, two
ZigBee receivers are working on channel 17 and 19, as shown
in Figure 8. One WiFi sender transmits NetCTC packets with
two different subcarrier regions (11 data subcarriers each).
The ZigBee receivers send back one bit CTC-ACK once they
receive CTC-ACK REQ.
Figure 20 compares the throughput of NetCTC on ZigBee
channel 17 and 19. From the figure, we can see that the
throughput of NetCTC on channel is about 5.94kbps. At
Fig. 22. Performance in IoT Device Control: WEBee vs. NetCTC
the same time, the throughput on channel 19 is slightly
lower than that on channel 17, which is about 5.73kbps. The
K. Application II: Neighbor Discovery
reason for this phenomenon is the diversity of channel quality
under different channels. With two parallel channels, the total This section demonstrates the advantage of using one-to-
throughput of NetCTC is doubled. many NetCTC by introducing the application of neighbor
discovery. To reduce the energy consumption, ZigBee devices
SmartPhone adopt low duty cycles, where they turn off wireless radios.
(WiFi BCM4339) Although the low duty cycle strategy saves energy, it leads to
long discovery time since ZigBee devices may miss discovery
packets. With the help of one-to-many NetCTC, the WiFi
device broadcasts ZigBee neighbor information directly to
ZigBee devices. Note that WiFi is always in active state and
thus discover all nearby ZigBee devices’ information, leading
to quick neighbor discovery.
Bulb (ZigBee)
 

     
  

Fig. 21. Application I: IoT Device Control
      
  

J. Application I: IoT Device Control 
      

  


      
  
Our NetCTC design is transparent to legacy networks and
compatible to existing standards (e.g., 802.15.4). It calculates
the WiFi payload bits for emulating ZigBee transmissions
#$
 #" #$
 #" " $!%
without modification on WiFi PHY and MAC layers. As a
result, NetCTC’s packets are transmitted in the same way as
normal WiFi packets, while applications decide WiFi payload
bits respectively, and then send the payload to the WiFi driver
for WiFi transmissions.
This section shows a real-world application of one-to-one
NetCTC on IoT device control. We implement both WEBee
and NetCTC on a Nexus 5X smartphone equipped with
a Broadcom BCM4330 WiFi chip to control ZigBee light
bulbs, as shown in Figure 21. The available control includes
the on/off status, light color and intensity. NetCTC achieves
reliable control of ZigBee devices from a WiFi radio without
WiFi-ZigBee gateways and without hardware modification on
smartphone and smart light bulbs.
Figure 22 plots the average number of transmissions and the
corresponding reliability of WEBee and NetCTC in the IoT
device control application. From the figure, we can see that
267

         
Fig. 23. Application II: Accelerating Neighbor Discovery
For example, in Figure 23, there are three ZigBee nodes,
with the duty cycle ratio of 1/3, 1/5 and 1/7 respectively. To
speed up the neighbor discovery, WiFi advertises ZigBee’s
neighbor information all the time to the ZigBee nodes using
the NetCTC technique. When ZigBee nodes wake up, they can
get the global nearby devices’ information, thus significantly
saving the neighbor discovery time.
Figure 24 depicts the comparison of the time with and
without NetCTC with the number of ZigBee devices increas-
ing from 3 to 7. Following Disco [8], ZigBee nodes adopt
co-prime numbers, i.e. 3, 5, 7, 11, 13, 17, 19, 23, and 29,
as their duty cycle periods. It is clear that Disco requires
significant amount of time with an increasing number of nodes.
As shown in Figure 24, Disco takes 323 slots for finding all
the 7 ZigBee devices, since it discovers neighbors in a pair-
wise fashion. NetCTC broadcasts the global information, thus
ensuring that the discovery time is maintained for providing
efficient neighbor discovery. For the discovery of 7 nodes,
NetCTC only takes 19 slots, which is 5.8% of Disco.
Fig. 24. Performance in Neighbor Discovery: Disco vs. NetCTC
VII. R ELATED W ORK
This section first introduces approaches for addressing het-
erogeneity to present the context of our work. Then we review
existing studies on (i) cross technology communication and (ii)
interaction mechanism which are closely related to our design.
A. Approaches for Addressing Heterogeneity
Many of today’s wireless technologies (e.g., WiFi, Blue-
tooth and ZigBee) are sharing unlicensed/open spectrum (e.g.,
ISM bands). To address the coexistence issue among hetero-
geneous technologies, many techniques have been proposed,
such as (i) CSMA and RTS/CTS in IEEE 802.11, DSSS in
IEEE 802.15.4, FHSS in Bluetooth, (ii) cognitive radio [9],
(iii) interference cancellation [10]–[14], (iv) spectrum underlay
and overlay [15]–[19], and (v) white space networking [20]–
[23]. All these techniques address heterogeneity based on im-
plicit information since heterogeneous devices are assumed to
be unable to exchange their message (e.g., spectrum utilization
information) directly.
In this paper, we focus on addressing heterogeneity with
cross-technology communication which allows explicit real-
time information exchange among heterogeneous devices. The
capability of direct communication brings great opportunity to
either support/improve existing approaches or establish new
approaches for addressing heterogeneity.
B. Cross Technology Communication
Existing cross technology communication (CTC) technolo-
gies can be divided into two categories. One is indirect
approach via gateways. The other is direct approach which
includes packet-level CTC and physical-layer CTC.
Gateway Based CTC: In the indirect approach, multi-radio
gateways are deployed as translators to bridge the communi-
cation gap between heterogeneous devices [24]. The gateway-
based approach has several limitations. Gateways incur not
only extra hardware costs but also extra traffic overhead and
time delay due to protocol conversions. In addition, gateways
have to be deployed in advance whenever the communication
among heterogeneities is required, making it difficult to sup-
port mobile and ad hoc scenarios.
268
Packet Level CTC: Realizing the limitation of gateway-
based approaches, wireless community invested early efforts to
establish direct connectivity for heterogeneous devices through
packet-level CTC. Chebrolu et al. and Zhang et al. propose
Esense [5] and Howies [25] which enable direct communi-
cation from commodity WiFi devices to commodity ZigBee
devices by sending out dedicated WiFi packets. Researchers
also establish direct cross technology communication mech-
anisms [6], [26], [27] via existing traffic. For example, Kim
et al. builds direct communication from WiFi to ZigBee via
shifting the timings of the mandatory beacons [6]. Chi et al.
propose B 2 W 2 which builds a direct communication link from
WiFi to Bluetooth via WiFi data traffic [7].
In all these packet-level CTC approaches, packets are u-
tilized as minimal units to construct special energy pattern
(i.e., delivered information) on the shared spectrum which
can be detected by other technologies through carrier sensing.
Since the duration of a wireless packet is in the range of
milliseconds, embedding communication symbols with sparse
packet-level information limits the transmission rate.
Physical Layer CTC: To eliminate the limitation of packet-
level CTC, researchers propose physical layer CTC [1], [2]
which establish direct physical layer communication from
WiFi and Bluetooth to ZigBee via software based signal
emulation. These physical layer CTC techniques achieve the
maximum transmission rate defined by the standard (e.g.,
250kbps for ZigBee), which is thousands of times of the state-
of-the-art packet-level CTC (e.g., 7.5bps@99% for ZigBee).
The PHY-CTC approach faces transmission failure (due to
emulation error) and asymmetric link (due to emulation infea-
sibility) issues. In this paper, we propose networking support
for PHY-CTC to address these issues to meet the requirement
(e.g., efficiency and reliability) from upper layer protocols.
C. Interactive Models
Extensive interactive models have been proposed to provide
networking support in homogeneous networks [28], [29].
The interactive models, which are designed with Fountain
codes [3], [4] or network coding [29]–[31], are the closest
to our design. Chieochan et al. develop interactive models for
delay-sensitive media streaming by modifying the traditional
802.11e block acknowledgment scheme to work with fountain
coding [28]. Hagedorn et al. propose interactive mechanisms
for rateless Deluge and ACKless Deluge using random linear
network coding.
Different from these traditional interactive models, our
design establish interactivity between heterogeneous devices.
In heterogeneous networks, due to the difference of wireless
standards at sender and receiver (e.g., MAC and channel access
precision), the receiver may not have chance to access the
channel when the sender is sending packets. In addition, ACKs
may not be available simply because that the communication
from the receiver to the sender is not supported. In this paper,
we address these issues with a new interactive model which
provides efficient and reliable cross technology communica-
tion for heterogeneous devices.
 VIII. C ONCLUSION
In this work we present NetCTC, a new interactive mech-
anism between heterogeneous devices. This interactive mech-
anism provides networking support for PHY-CTC to address
the transmission failure and asymmetric link issues, thus pro-
viding efficient and reliable cross technology communication
to upper layer protocols. We evaluate NetCTC on both USRP
and commodity WiFi/ZigBee devices. The experiment results
show that NetCTC achieves bidirectional cross technology
communication, while providing reliability under stationary,
mobile and duty cycled scenarios.
ACKNOWLEDGEMENT
This work was supported in part by the NSF CNS-1444021,
NSF CNS-1525235, NSF CNS-1718456, and NSF China
61672196. We sincerely thank our shepherd Vijay Gopalakr-
ishnan and the anonymous reviewers for their valuable com-
ments and suggestions.
R EFERENCES
[1] Zhijun Li and Tian He. Webee: Physical-layer cross-technology commu-
nication via emulation. In Proceedings of the 23rd Annual International
Conference on Mobile Computing and Networking (MobiCom), 2017.
[2] Wenchao Jiang, Zhimeng Yin, Ruofeng Liu, Zhijun Li, Song Min Kim,
and Tian He. Bluebee: a 10,000x faster cross-technology communication
via phy emulation. In SenSys, 2017.
[3] D. J. MacKay. Fountain codes. In IEE Proceedings-Communications,
2005.
[4] Wan Du, Jansen Christian Liando, Huanle Zhang, and Mo Li. When
pipelines meet fountain: Fast data dissemination in wireless sensor
networks. In Proceedings of the 13th ACM Conference on Embedded
Networked Sensor Systems (SenSys), 2015.
[5] Kameswari Chebrolu and Ashutosh Dhekne. Esense: Communication
through energy sensing. In Proceedings of the 15th Annual International
Conference on Mobile Computing and Networking (MobiCom), 2009.
[6] 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.
[7] Zicheng Chi, Yan Li, Hongyu Sun, Yao Yao, Zheng Lu, and Ting Zhu.
B2w2: N-way concurrent communication for iot devices. In Proceedings
of ACM Conference on Embedded Network Sensor Systems (SenSys),
2016.
[8] Prabal Dutta and David Culler. Practical asynchronous neighbor discov-
ery and rendezvous for mobile sensing applications. In Proceedings of
the 6th ACM conference on Embedded network sensor systems, pages
71–84. ACM, 2008.
[9] Carl R Stevenson, Gerald Chouinard, Zhongding Lei, Wendong Hu,
Stephen J Shellhammer, and Winston Caldwell. Ieee 802.22: The
first cognitive radio wireless regional area network standard. IEEE
communications magazine, 47(1):130–138, 2009.
[10] Shyamnath Gollakota, Fadel Adib, Dina Katabi, and Srinivasan Seshan.
Clearing the rf smog: Making 802.11n robust to cross-technology
interference. In Proceedings of ACM SIGCOMM, 2011.
[11] Daniel Halperin, Thomas E. Anderson, and David Wetherall. Taking
the sting out of carrier sense: interference cancellation for wireless
lans. In Proceedings of the 14th Annual International Conference on
Mobile Computing and Networking, MOBICOM 2008, San Francisco,
California, USA, September 14-19, 2008, pages 339–350, 2008.
[12] Yubo Yan, Panlong Yang, Xiang-Yang Li, Yafei Zhang, Jianjiang Lu,
Lizhao You, Jiliang Wang, Jinsong Han, and Yan Xiong. Wizbee: Wise
zigbee coexistence via interference cancellation with single antenna.
IEEE Trans. Mob. Comput., 2015.
269
[13] S. Gollakota and D. Katabi. Zigzag decoding: combating hidden
terminals in wireless networks. In ACM SIGCOMM, 2008.
[14] Yan Yubo, Yang Panlong, Li Xiangyang, Tao Yue, Zhang Lan, and You
Lizhao. Zimo: Building cross-technology mimo to harmonize zigbee
smog with wifi flash without intervention. In Proceedings of the 19th
Annual International Conference on Mobile Computing (MobiCom),
2013.
[15] TQ Duong, Vo Nguyen Quoc Bao, and H-J Zepernick. Exact outage
probability of cognitive af relaying with underlay spectrum sharing.
Electronics letters, 47(17):1001–1002, 2011.
[16] Steven Hong, Jeffrey Mehlman, and Sachin Katti. Picasso: flexible rf
and spectrum slicing. In SIGCOMM, 2012.
[17] Liping Luo, Ping Zhang, Guangchi Zhang, and Jiayin Qin. Outage per-
formance for cognitive relay networks with underlay spectrum sharing.
IEEE Communications Letters, 15(7):710–712, 2011.
[18] Shravan Rayanchu, Vivek Shrivastava, Suman Banerjee, and Ranveer
Chandra. Fluid: Improving throughputs in enterprise wireless lans
through flexible channelization. IEEE Transactions on Mobile Com-
puting, 11(9):1455–1469, 2012.
[19] Lei Yang, Wei Hou, Lili Cao, Ben Y. Zhao, and Haitao Zheng.
Supporting demanding wireless applications with frequency-agile radios.
In NSDI, 2010.
[20] Jun Huang, Guoliang Xing, Gang Zhou, and Ruogu Zhou. Beyond co-
existence: Exploiting wifi white space for zigbee performance assurance.
In Proceedings of the 18th IEEE International Conference on Network
Protocols (ICNP), 2010.
[21] Min Li Huang and Sin-Chong Park. A wlan and zigbee coexistence
mechanism for wearable health monitoring system. In Proceedings of
the 9th international conference on Communications and information
technologies (ISCIT), 2009.
[22] Byoung Hoon Jung, Jo Woon Chong, Chang Yong Jung, Su Min
Kim, and Dan Keun Sung. Interference mediation for coexistence of
wlan and zigbee networks. In Personal, Indoor and Mobile Radio
Communications (PIMRC), 2008.
[23] Yufei Wang, Qixin Wang, Zheng Zeng, Guanbo Zheng, and Rong Zheng.
Wicop: Engineering wifi temporal white-spaces for safe operations of
wireless body area networks in medical applications. In Real-Time
Systems Symposium (RTSS), 2011.
[24] Tao Jin, Guevara Noubir, and Bo Sheng. Wizi-cloud: Application-
transparent dual zigbee-wifi radios for low power internet access. In
Proceedings of IEEE International Conference on Computer Communi-
cations (INFOCOM), 2011.
[25] Yifan Zhang and Qun Li. Howies: A holistic approach to zigbee
assisted wifi energy savings in mobile devices. In Proceedings of IEEE
International Conference on Computer Communications (INFOCOM),
2013.
[26] Zhimeng Yen, Wenchao Jiang, Song Min Kim, and Tian He. C-morse:
Cross-technology communication with transparent morse coding. In
Proceedings of IEEE International Conference on Computer Commu-
nications (INFOCOM), 2017.
[27] Wenchao Jiang, Zhimeng Yen, Song Min Kim, and Tian He. Transparent
cross-technology communication over data traffic. In Proceedings of
IEEE International Conference on Computer Communications (INFO-
COM), 2017.
[28] Surachai Chieochan and Ekram Hossain. Wireless fountain coding
with ieee 802.11e block ack for media streaming in wireline-cum-
wifi networks: A performance study. IEEE Transacrion on Mobile
Computing (TMC), 2011.
[29] Andrew Hagedorn, David Starobinski, and Ari Trachtenberg. Rateless
deluge: Over-the-air programming of wireless sensor networks using
random linear codes. In IPSN, 2008.
[30] R. Ahlswede, Ning Cai, S.-Y.R. Li, and R.W. Yeung. Network informa-
tion flow. IEEE Transactions on Information Theory, 2000.
[31] T. Ho, M. Medard, R. Koetter, D. R. Karger, M. Effros, J. Shi, and
B. Leong. A random linear network coding approach to multicast. IEEE
Transactions on Information Theory, 2006.