1. Introduction
IoT technology has facilitated the use of portable devices by warehouse administrators for connecting goods and various sensors for data communication and remote management. In the service industry, to improve efficiency and control products, there is a high demand for informatization in supply chain management [
1]. The supply chain system must be readily available and machinery downtime kept to a minimum [
2]. The economic losses caused by replacing aging power sources will be very serious. Moreover, the monitoring and communication devices employed in the supply chain pose a significant power-consumption challenge. According to a survey on wireless communication [
3], the bulk of energy consumed by communication systems is attributable to energy-intensive active radio frequency (RF) devices such power amplifiers. Consequently, enterprises that prioritize the deployment of low-energy-consumption technology in supply chain management will reap higher profits.
To reduce energy consumption and enable long-term communication in passive conditions, backscatter communication systems have been proposed as a novel, low-cost, and energy-efficient solution that can reduce power consumption to a microwatt level. These advantages make backscattering a promising technology for large-scale applications in smart homes [
4,
5,
6,
7,
8], smart agriculture [
9,
10,
11,
12,
13], sensors [
14,
15,
16,
17,
18], and other fields. Backscatter has been implemented in various technologies, including WiFi [
19,
20,
21,
22,
23,
24], ZigBee [
25,
26], LoRa [
27], and Bluetooth [
28,
29,
30,
31]. However, traditional backscatter systems require specialized hardware to achieve backscatter communication. For instance, WiFi backscatter [
32] requires a power supply to connect to the network, and BackFi [
33] uses customized full-duplex hardware. Passive WiFi [
34] needs a dedicated continuous wave signal generator as the excitation signal source. These hardware requirements limit the application scenarios of backscatter systems. HitchHike [
35] achieves backscatter communication by commodity devices and introduces the idea of codeword translation, which allows a backscatter tag to embed its information on standard 802.11b packets. Codeword translation has been extended to Bluetooth, ZigBee, and LoRa by FreeRider [
36] and LoRa Backscatter [
37]. In HitchHike, one more access point is deployed to demodulate excitation signals, enabling the system to decode tag data via a simple and efficient XOR decoder. In addition, ambient backscatter communication and antenna selection methods are also used to improve the technology [
38,
39,
40].
We can categorize backscatter systems into two modes, as shown in
Figure 1. In mode A, the backscatter communication system uses a controlled excitation source for backscattering and decoding. This mode has additional requirements on the excitation source. The pre-defined excitation packet does not carry valid information, and the excitation signal may cause interference with other devices on the same communication channel. In mode B, the system employs an additional AP to receive excitation signals, and it decodes tag data through backscatter data and original data. Compared to active communication infrastructure, both modes of backscatter systems require additional hardware at the transmitter or receiver, which leads to extra costs and may present challenges in large-scale deployment on the current WiFi infrastructure.
Inspired by these observations, this paper focuses on single-AP decoding with ambient WiFi signals. The main contributions in this work are summarized as follows.
The current study proposes a CRC reverse-algorithm-based single-AP backscatter system with ambient WiFi signals called CRCScatter. The system uses a CRC reverse decoder to solve the problem of decoding original excitation data from a backscatter packet.
The current research present simulation results to verify the effectiveness of CRCScatter and analyze the performance. The CRCScatter system achieves a decoding tag data bit error rate of at SNR = −7.5 dB.
The simulation results verify that the CRC reverse algorithm is better than the brute-force search method in decoding efficiency and the average decoding time of CRCScatter is independent of the tag data length. An improved method for adding redundant bits to the tag data is proposed to improve the decoding accuracy in the presence of noise interference.
3. CRCScatter Decoder Design
3.1. CRCScatter Decoder Overview
The overview of decoding employed by CRCScatter at the receiver is illustrated in
Figure 4. The procedure of decoding tag data can be divided into two steps.
The first step involves reversing the backscatter packet into the original packet. The received backscatter MAC frame consists of the MAC header, the frame body, and the FCS, but the tag only modulates the frame body. The MAC header and the FCS in the original packet are the same as those in the backscatter packet. However, the original data cannot be obtained directly because the frame body has been modified. The IEEE 802.11b protocol specifies the correlation between FCS and the transmitted data in WiFi packets. The CRC reverse decoder utilizes this intrinsic correlation as a constraint in calculation and uses two CRC algorithms to reverse original data from the backscatter packets.
The second step is to calculate tag data based on backscatter data and original data obtained through the CRC reverse decoder. In 802.11b data transmission, DBPSK modulation is used, whereas BPSK modulation is adopted by the tag. Due to this difference in modulation, the original XOR decoder in HitchHike cannot obtain the correct tag data. To overcome this, CRCScatter employs a decoder that combines XOR operation and differential decoding to accurately calculate tag data.
In summary, the CRCScatter system utilizes two decoders to compute the original packet and tag data in steps. While the function of the CRC reverse decoder is to retrieve original data from the backscatter packet, the XOR and the differential decoder can obtain correct tag data from original data and backscatter data.
3.2. CRC Reverse Decoder
3.2.1. The Algorithms of CRC in the CRC Reverse Decoder
To detect unpredictable bit errors in received packets, the CRC sequence is transmitted with the data. In particular, FCS uses CRC32 to protect the MAC header and frame body. The CRC32 value can be computed by performing bit shifts and XOR operations on a 32-bit CRC register. The bit-oriented calculation algorithm of the CRC value is given by IEEE 802.11b protocol, as shown in Algorithm 1. The CRC algorithm contains three constants, namely, CRCPOLY, INITXOR, and FINALXOR. For CRC32, the value of these constants is given by CRCPOLY = 0x04C11DB7, INITXOR = FINALXOR = 0xFFFFFFFF. In addition, when focusing on the calculation of the CRC register, we can replace INITXOR and FINALXOR with the initial and final states of the CRC register. In each loop of Algorithm 1, bit shift and XOR operations are carried out on the CRC register based on the comparison of the input data bit and the shifted-out bit. The number of bits calculated for a single shift and XOR operation depends on the register length, while the number of cycles corresponds to the length of the input data. When the input data length and CRC type are given, the average run time of Algorithm 1 is stable.
Algorithm 1 Calculation of the CRC |
Input: data bits a Output: CRC register value INITXOR while
do LEFTSHIFT() if then CRCPOLY end if end while FINALXOR
|
Assuming that the initial CRC register value
and the data bits
a are known, the CRC algorithm can calculate the final value
r. Conversely, if the final CRC register value
r and the calculated data
a are given, we can reverse the procedure of the CRC algorithm to obtain the initial value
. The CRC reverse algorithm [
41] is presented in Algorithm 2 because Algorithm 2 is the inverse process of Algorithm 1. Similarly, we can also conclude that the average run time is stable when the input bit length is fixed.
Algorithm 2 CRC32 reverse algorithm |
Input: final CRC register value r, reversed data bits a Output: initial CRC register value while do if then CRCPOLY RIGHTSHIFT() else RIGHTSHIFT() end if end while
|
Both the CRC algorithm and the CRC reverse algorithm can be represented as functions, where
and
r represent the initial and final value of the CRC register, respectively, while
a represents the calculated data bits. When a set of CRC register values and data bits are given, the two algorithms are opposite computational processes, and the two functions hold simultaneously.
3.2.2. How to Reverse the Unknown Data from CRC32 Value?
The algorithms of CRC utilize forward or reverse methods to compute the value of the CRC register from the input data bits
a. A highly relevant problem is knowing how to reversing the unknown data bits from the initial and final state values of CRC32. Assuming the unknown data length
l is known, we can employ brute-force search to find the possible original data from all
data sequences. When the data length
l is greater than 32 bits, the number of solutions is
. If the data length does not exceed 32 bits, the unknown data sequence is unique. The relationship between the number of solutions
and the data length
l can be expressed as follows:
To ensure result uniqueness, we consider the case of unknown data bits with a length of 32 bits. In CRC algorithms, the data sequence
a is an independent variable in functions. To calculate the unknown data bits, we need to establish a new relationship between
a and CRC register values. Assuming the length of data bits is the same as the length of CRC32, the CRC algorithm has certain properties [
41], which can be expressed as:
Through the equivalence relation of (6) and the Equation (
3), we can derive a new Equation (7) to calculate the data bits
a, as shown in
Figure 5.
3.2.3. How to Reverse the Original Data?
The MAC frame can be divided into three parts: the MAC header K, the CRC32 sequence R, and the original data a. The transmitter calculates the CRC32 sequence based on the MAC header and the original data. There is a constraint relationship between these parts. The MAC header and CRC32 sequence are known at the receiver because they have not been modified by the tag. The primary challenge is calculating the unknown original data based on known data and constraints. As previously discussed, the tag length should not exceed 32 bits to ensure uniqueness. Therefore, the modified bits by the tag do not exceed 32 bits. We assume that the length of the frame body is 32 bits, indicating the original data length is 32 bits.
Since the unknown original data are limited, we can list all of the possible original data sequences. For each possible sequence, we calculate the CRC value using the MAC header and the possible sequence and compare the value with the CRC32 sequence from the received packet. We continue this process until we find the original data sequence that matches the CRC32 sequence. This brute-force search for the unknown original data is impractical due to the exponential growth of the average number of enumerations with the length of unknown original data. Therefore, a brute-force search cannot satisfy the requirements of immediate communication and the high tag data transmission rate simultaneously.
Fortunately, the original data can be obtained by reversing the unknown data bits based on CRC algorithms. To accomplish this, the initial and final values of the CRC register
and
r are computed using CRC algorithms, respectively. The IEEE 802.11b protocol specifies that the initial value
for forwarding calculation is INITXOR, while the final value
r can be obtained from the FCS field. Then, the original data can be calculated using the method of reversing unknown data bits. Finally, the original packet can be obtained by replacing backscatter data in the backscatter packet with calculated original data. Algorithm 3 presents the procedure for reversing the original data from the backscatter MAC frame.
Algorithm 3 Calculation in CRC reverse decoder |
Input: MAC header K, CRC32 sequence R Output: original data a FINALXOR INITXOR
|
The CRC reverse decoder offers an efficient method for decoding transmission tag data up to 32 bits in length. Functionally, the CRC reverse decoder serves as a receiver for a traditional backscatter system that receives the original packet. The CRCScatter system reduces hardware requirements through the use of the CRC reverse decoding method. This design for decoding relies on the presence of a bit sequence within the packet that constrains the transmitted data. Because the CRC reverse decoder only utilizes the constraints of the FCS field, the maximum length of tag data is limited to 32 bits. If the tag data exceed this limit, the reversed original data at the decoder will not satisfy the uniqueness of the solutions. The length can be extended if more constraints are applied to the packets.
In terms of time complexity, the original data-decoding method based on CRC algorithms requires two CRC algorithms to traverse the entire MAC frame. Even when the tag data is less than 32 bits, the algorithm still needs to calculate the entire original data, while the tag only modifies some of the data bits. Therefore, given the length of frame body, the time for calculating the original data is related to the packet length rather than the tag data length.
3.3. XOR and Differential Decoder
The IEEE 802.11 protocol specifies that the DSSS system uses the baseband modulation of DBPSK to provide the 1 Mbit/s data rate and solve the problem of phase ambiguity in BPSK. In DBPSK modulation, the input data
a is calculated by differential encoding to obtain differential data
e; then, the differential data
e is modulated by the conventional BPSK modulator. In other words, we can assume that the 802.11b signal in our system transmits the differential data
e rather than the original data
a. Since the CRCScatter tag can modify the transmitted data by codeword translation, we set the differential data modified by the tag to
and the backscatter data to
. According to the decoding Formula (1) and the process shown in
Figure 6, the tag data
t can be represented using differential data
e and
.
In differential encoding, the transmitted data
a and the differential data
e should satisfy the encoding formula written as:
We can use the original data
a and backscatter data
to calculate tag data
t by differential encoding formula. The tag data calculation needs to be discussed separately. The first tag data bit
is calculated differently from the other tag data bits.
Algorithm 4 presents the procedure for obtaining correct tag data
t from backscatter data
and original data
a, as described in this section. From a time complexity standpoint, the number of XOR operations in Algorithm 4 is related to the length of tag data. When the tag data are 32 bits long, we can calculate that the number of bits requiring XOR calculation does not exceed 64. Since a single register operation in CRC algorithms requires a 32-bit operation and the number of cycles is related to the packet length, the time required for differential encoding is significantly shorter than that required for solving the original data. Furthermore, tag data with a length of less than 32 bits can be expanded to 32-bit tag data by adding zeros to the end. When processing backscatter packets from various tags, maintaining a unified tag data length can facilitate the decoder’s work and prevent the loss of vital information. Thus, we believe that for the CRCScatter system, the decoding time complexity is related to the packet length, and the tag data length will not affect the average decoding time of the system.
Algorithm 4 Calculation in XOR and differential decoder |
Input: backscatter data , original data a Output: tag data t while do if then else end if end while
|
In data communication, noise can cause bit errors in received backscatter packets, leading to errors in decoding tag data. To address this issue, similar to the CRC32 sequence in the MAC frame, the tag can add redundancy check bits and piggyback them along with the real tag data. The tag data containing real tag data and redundant bits can be decoded together by the CRCScatter decoder. Subsequently, the CRCScatter decoder is required to check the decoded tag data. The system can detect incorrect results, and any erroneous tag data that fails to pass verification will be discarded. After error detection steps, the correct decoding data can be preserved, thereby improving decoding accuracy. The verification method and complexity are determined by the type of redundant bits. This work employs a simple parity check code as a redundant error-detecting code, and the decoder needs to count the number of bit “1" in the tag data to verify the results. Due to the limited length of the tag data and the simplicity of the parity check step, the time of parity check will not affect the decoding efficiency of the system. In practical applications, the system can select the suitable redundant bit length and type based on the requirements to balance the tradeoff between the bit error rate (BER) and the verification complexity.
4. Simulation Results
In this section, the simulation results are presented to evaluate the performance of CRCScatter. We use DBPSK modulation in 802.11b transmission and set the length of frame body to 32 bits. The tag data length N and the SNR are varied to calibrate the results.
First, we verify the effectiveness of the CRCScatter system. In the simulation, the SNR can be set to different values through its relationship with
.
Figure 7 shows the results of the decoding bit error rate of tag data versus the SNR for different tag data lengths
N. The SNR varies from −15 dB to −5 dB, and the tag data length
N is fixed as 8, 16, 24, and 32 bits. In
Figure 7, we observe that the decoding the BER of the tag data can be reduced by increasing the SNR. Nevertheless, decoding the BER is similar in terms of the tag data length
N. From the figure, the system can achieve a BER level of
at −7.5 dB, which proves the effectiveness of the CRC reverse-algorithm-based decoding method in the low SNR regime. Moreover, the SNR does not affect the BER performance when the SNR is less than −13 dB. In this case, the system cannot decode correctly due to excessive noise interference.
Next, we test the decoding time of tag data using the brute-force search and the CRC reverse algorithm.
Table 2 exhibits the results of the average decoding time versus different tag data lengths for the algorithms. We observe that the decoding time of brute-force search increases sharply when tag data length
N increases from 4 bits to 18 bits. Due to the excessive decoding time, the brute-force method is not able to meet the requirements of the real-time communication system. Nevertheless, the tag data length
N does not affect the average decoding time of the CRC reverse algorithm, which is close to
s. Overall, the CRC reverse algorithm is superior to the brute-force search when the tag data length is long. With the average decoding time of the CRC reverse algorithm and the maximum tag data length, we can estimate that the maximum tag data rate of the system is 3.2 kbps, which is sufficient for intelligent meter reading systems, intelligent bracelets, and other micro IoT devices.
Finally, we test the performance of using redundant bits in tag data to reduce the decoding BER. In the simulations, this study uses four duplicate parity bits as redundant bits for tag data. As shown in
Figure 8a, the additional redundant bits can reduce the decoding BER when SNR is greater than −12 dB. In addition, when the SNR is higher than −7 dB, the improved method can achieve accurate decoding with tag data length
bits. With the same SNR
dB,
Figure 8b shows that the decoding BER of tag data with redundant bits is 9% to 15% of the BER without redundant bits. These results suggest that adding redundant bits can significantly reduce the BER in the presence of noise interference. Additionally, because the average decoding time of tag data is stable and the parity check algorithm is simple, adding redundant parity check bits will not affect the efficiency of the decoding.
In summary, we validate the feasibility of CRCScatter through simulation results. In practical scenarios, such as product identification and quality control in fruit supply chain management, the CRCScatter system has the potential to be deployed on mobile devices. Tags containing key information are affixed to the surface of the fruit. By receiving and decoding the backscatter signal of the tag, managers can simultaneously obtain crucial information such as the location and type of multiple different products. Due to low hardware requirements and low energy consumption, we believe this communication scheme will facilitate product quality inspection, cargo classification, and other operations in supply chain management. With the improvement of throughput, low-power video communication will also be available.
5. Discussions and Conclusions
In this paper, we propose a novel backscatter communication system, named CRCScatter, which enables ambient WiFi backscatter communications with a single-AP receiver. Unlike existing backscatter systems, CRCScatter does not require an additional access point at the receiver, nor does it impose restrictions on the excitation source. The CRCScatter decoder performs a reverse CRC, XOR decoding, and a differential decoding procedure to decode the original packet and tag data from the received backscatter packet. The simulation results demonstrate the effectiveness of the proposed system. To reduce the BER, this work adds redundant parity bits to the tag data for simple error detection. In future work, we aim to implement and test CRCScatter in real-world environments.
We outline some directions for improving upon this work. First, a possible research direction for further exploration is to expand the types and functions of parity bits. More complex error-detecting codes such as CRC can be applied to this work for lower BER. Error-correcting codes could be applied to improve decoding accuracy when the SNR is high and the number of error bits is small. Second, the CRCScatter tag continuously modulates multiple bits based on the length and content of the tag data. Future work could use more modulation methods, such as segmented modulation or sliding window. The decoding algorithm also needs to be redesigned based on the new modulation method. Lastly, while the current design focuses on DBPSK, future work could explore decoding on DQPSK or other excitation signals such as Bluetooth and ZigBee.