How to Construct an RFFI System

Last updated:

This tutorial explains how to construct a radio-frequency fingerprint identification (RFFI) system, from obtaining signals to evaluating a trained classifier. The implementation depends on the wireless technology and the selected transmitter and receiver platforms. For further background, see [1].

For an end-to-end starting point, follow the LoRa RFFI example below. It provides a dataset and source code, so you can try the classification workflow before building a signal-collection testbed.

As shown below, an RFFI testbed consists of several devices under test (DUTs) and a receiver. The system identifies the transmitting device by analysing hardware-related characteristics in the physical-layer signals captured by the receiver.

Deep-learning-based RFFI system workflow
Deep-learning-based RFFI system workflow.

General Procedures

Developing a deep learning-based RFFI system involves obtaining a dataset, preparing the signals, training a classifier, and evaluating its performance. You can collect your own signals or use a public dataset. For a detailed discussion of deep learning-based RFFI design, see Section V of [2].

The data used to develop a deep learning-based RFFI system are divided into three sets with distinct roles:

  • Training set: used to fit the classifier.
  • Validation set: used to select preprocessing choices and model settings, and to decide when to stop training.
  • Test set: held out until the final evaluation to assess the selected model’s performance.

This tutorial focuses on closed-set identification: every device to be identified during testing is represented during training. Plan the dataset split when collecting or selecting data, and include each device class in all three sets. For example, if the aim is to identify devices in future recording sessions, reserve separate sessions for validation and testing rather than randomly mixing packets from every session. Keep overlapping signal windows and augmented versions of the same packet in the same set.

Whether you collect your own data or use a public dataset, the workflow is as follows:

  • 1A. Build your own testbed to collect signals, or 1B. use a public dataset.
  • 2 Preprocess the signals, optionally augment the time-domain training signals, and choose a signal representation.
  • 3 Train a classifier using the prepared training data.
  • 4 Evaluate the classifier on held-out test data using accuracy and a confusion matrix.

1A. Building Your Own Testbed

If you are using public datasets, this section can be skipped.

1A.1 Transmitter Selection and Packet Transmission

Many wireless devices can be used as DUTs. Although a custom device can be built, commercial off-the-shelf (COTS) development boards and kits usually reduce implementation time.

Some DUTs allow direct control over packet transmission through firmware, while others require traffic to be generated through ordinary applications. Examples of vendors and platforms that support programmable transmission are listed below. Available wireless technologies depend on the selected board or chip.

The table below summarises LoRa boards and development platforms used in RFFI research. The Pycom boards are legacy options; check hardware availability and toolchain support before choosing a platform for a new testbed.

Board or Platform Development Environment Documentation
Pycom LoPy4 (legacy) MicroPython (Python) LoRa API
Pycom FiPy (legacy) MicroPython (Python) LoRa API
Dragino LoRa Shield Arduino (C/C++) Code examples
Semtech SX1276MB1xAS evaluation board Mbed (C/C++; legacy example) Board and library documentation

Consumer devices such as smartphones can also serve as DUTs using their Wi-Fi or Bluetooth radios.

Different development boards use different programming languages and development platforms. For programmable DUTs, configure the firmware to send wireless packets, often by adapting examples from the manufacturer’s documentation. Vendors usually provide the required development software and software development kit (SDK).

When firmware control is unavailable, traffic can be generated through ordinary applications. For example, video streaming creates sustained Wi-Fi traffic on a smartphone, while a laptop connected over Wi-Fi can generate traffic using the ping command.

1A.2 Verify Wireless Transmissions Using Wireshark (Optional)

Before developing the signal-collection software, confirm that the required wireless traffic is present. Wireshark is useful for monitoring and verification, although it may require a separate receiver.

1A.3 Receiver Selection and Signal Collection

Most COTS gateways, access points, and receivers do not provide access to physical-layer signals. Software-defined radios (SDRs) are therefore commonly used as receivers. An SDR uses a flexible analogue front end to convert the desired radio signal to baseband or an intermediate frequency. An analogue-to-digital converter then samples the signal to produce digital in-phase and quadrature (IQ) samples. Subsequent communication functions, such as packet detection and decoding, are implemented in software, giving researchers access to the physical-layer samples.

The table below summarises several SDRs available in our laboratory. The receiver should be selected according to the target communication technology, such as Wi-Fi, Zigbee, or LoRa. For example, RTL-SDR is unsuitable for Wi-Fi research because of its frequency-range and bandwidth limitations.

SDR Platform Nominal Receive Frequency Range Nominal RF Bandwidth Development Tools
USRP N210 with UBX-40 daughterboard 10 MHz–6 GHz 40 MHz MATLAB, UHD (C/C++ and Python APIs), GNU Radio, LabVIEW
Zynq-based platform with AD9361 70 MHz–6 GHz (transceiver specification) Up to 56 MHz MATLAB, libiio (C and Python APIs), GNU Radio
ADALM-PLUTO 325 MHz–3.8 GHz Up to 20 MHz MATLAB, libiio (C and Python APIs), GNU Radio
RTL-SDR 22 MHz~2.2 GHz 3.2 MHz MATLAB, pyrtlsdr (Python API), GNU Radio

These RF bandwidths do not necessarily equal the bandwidth that can be continuously captured on a host PC. The interface, sample format, sample rate, and storage speed also constrain capture. For example, the N210 supports streaming up to 25 MS/s with 16-bit complex samples or 50 MS/s with 8-bit complex samples; its UBX-40 daughterboard has a nominal RF bandwidth of 40 MHz. See the Ettus device-selection guide and UBX-40 specifications. For the Analog Devices platforms, see the AD9361 specifications and ADALM-PLUTO hardware documentation; the carrier board and host interface determine the sustained capture rate.

For an introduction to SDR and digital signal processing, see PySDR.

The laboratory setups described here typically use a host PC to configure the SDR, receive samples, and store recordings. Some SDR platforms include embedded processors and can support standalone applications, depending on their software and hardware configuration. For RFFI research, a signal-reception program is required to capture valid wireless packets. The figure below shows the flow chart of a basic signal-collection program.

Flow chart of an SDR signal-collection program
Basic processing flow for an SDR signal-collection program.

Packet detection, synchronisation, and carrier-frequency-offset (CFO) compensation can be implemented in MATLAB, Python, or C, depending on the real-time and data-rate requirements. These operations may run during collection or offline as part of signal preparation. To establish device labels, capture one DUT at a time or decode packet identifiers, such as MAC addresses where applicable. Use these identifiers to label the data, and exclude them from classifier inputs intended to measure RF fingerprints. Signals can be stored in formats such as CSV, HDF5, MAT, or text, provided that the complex IQ values and associated metadata can be recovered correctly.

MATLAB provides examples of SDR reception and waveform processing. Select the documentation for the target communication protocol and study how each processing stage is implemented:

1B. Public Datasets

Several public datasets are available for RFFI research; see the RFFI datasets page for details. Using a public dataset removes the need for signal-acquisition hardware, although a suitable computer is still required for processing and model training.

Before processing a dataset, check its IQ format, sample rate, device labels, recording conditions, and any preprocessing already applied. Use the published training, validation, and test splits when reproducing a benchmark; otherwise, define and document a split suited to the intended evaluation.

2. Signal Preparation

2.1 Preprocessing

If the recordings have not already been segmented, detect packets and extract a consistent region, such as the preamble. Use the same segmentation rule and input length for every DUT so that inputs can be compared consistently. Preserve device labels and recording metadata, including the session, receiver, channel, sample rate, and gain settings where available.

Depending on the waveform and model, preprocessing may include timing synchronisation, amplitude normalisation, and carrier-frequency-offset (CFO) compensation. These steps are optional design choices: normalisation can reduce sensitivity to received power, while CFO compensation can also remove information that a classifier might otherwise use as a fingerprint. Document the selected steps and apply them consistently during training and evaluation.

Fit any data-dependent preprocessing parameters, such as normalisation statistics, using the training set alone, then apply those parameters to the validation and test sets.

2.2 Data Augmentation (Training Only)

Apply data augmentation to the time-domain IQ samples in the training set before converting them to another signal representation. This can increase signal diversity by simulating different channel conditions and noise levels. For example, a channel model can use a time-varying impulse response $h(\tau, t)$, where $\tau$ denotes propagation delay and $t$ denotes time, to simulate multipath effects.

Augmentation is optional and may be less useful when the training dataset already covers the expected operating conditions. Choose transformations that preserve the device label and relevant hardware characteristics, and assess their benefit on the validation set. Apply augmentation only to the training data after splitting the dataset; retain validation and test data for evaluation under clearly specified conditions.

Read Section V.A of [3] and Section V.C of [2] for more information.

2.3 Signal Representation

The neural network can take time-domain IQ samples directly or use representations derived through signal processing. For example, a fast Fourier transform (FFT) produces a frequency-domain representation, while a short-time Fourier transform (STFT) produces a time–frequency representation such as a spectrogram. Choose the representation according to the waveform and model, and record its parameters so the same transformation can be reproduced at inference time.

Read Section V.D of [2] for more information.

3. Classifier Training

A deep learning classifier can be trained using an architecture such as a convolutional neural network (CNN), long short-term memory (LSTM) network, gated recurrent unit (GRU) network, or transformer. Suitable frameworks include PyTorch, TensorFlow, and MATLAB Deep Learning Toolbox.

Train the model using the training set and monitor its performance on the validation set to select model settings and decide when to stop training. Record the architecture, optimiser, learning rate, batch size, random seed, and preprocessing settings so the experiment can be reproduced.

If you are new to deep learning, the following introductory resources may be useful:

4. Evaluation

Evaluate the selected model on the held-out test set. Report the number of devices and packets per device, the dataset split, and the recording conditions so readers can interpret the result.

  • Overall accuracy: the fraction of test packets assigned to the correct device. If the class sizes differ substantially, also report per-device recall or balanced accuracy so that larger classes do not dominate the result.
  • Confusion matrix: show which devices are confused with one another. Label both axes clearly; if rows represent true devices, row-normalised values show the prediction distribution for each device.
  • Generalisation: state whether test recordings use different sessions, channels, locations, or receivers from training. Results from randomly split packets within a recording do not establish performance under these changes. Where relevant, evaluate each change separately.

Keep the test set separate from model selection. For repeated runs, report the mean and variability across random seeds or predefined splits. If extending the system to recognise previously unseen devices, use a separate evaluation protocol that measures unknown-device rejection as well as identification of known devices.

Working Examples

The following examples provide implementations for RFFI.

LoRa RFFI

Please visit our datasets and code page for the RFFI datasets and source code shared by our group.

A good starting point is Towards Scalable and Channel-Robust Radio Frequency Fingerprint Identification for LoRa. Both the dataset and source code are available. Start with the Closed_set_RFFI example. Technical descriptions of the algorithms can be found in [4] and [3].

MATLAB Example

MATLAB, Detect WLAN Router Impersonation

References

  1. 2023
    J. Zhang, G. Shen, W. Saad, and K. Chowdhury, “Radio frequency fingerprint identification for device authentication in the internet of things,” IEEE Communications Magazine, vol. 61, no. 10, pp. 110–115, 2023, doi: 10.1109/mcom.003.2200974.
    DOI 
    @article{zhang2023radio,
  title = {Radio frequency fingerprint identification for device authentication in the internet of things},
  author = {Zhang, Junqing and Shen, Guanxiong and Saad, Walid and Chowdhury, Kaushik},
  journal = {IEEE Communications Magazine},
  volume = {61},
  number = {10},
  pages = {110 - 115},
  year = {2023},
  doi = {10.1109/mcom.003.2200974},
  keywords = {rffi,survey}
}
  2. 2025
    J. Zhang, F. Ardizzon, M. Piana, G. Shen, and S. Tomasin, “Physical Layer-Based Device Fingerprinting For Wireless Security: From Theory To Practice,” IEEE Transactions on Information Forensics and Security, vol. 20, pp. 5296–5325, 2025, doi: 10.1109/tifs.2025.3570118.
    DOI arXiv 
    @article{zhang2025physical,
  title = {Physical Layer-Based Device Fingerprinting For Wireless Security: From Theory To Practice},
  author = {Zhang, Junqing and Ardizzon, Francesco and Piana, Mattia and Shen, Guanxiong and Tomasin, Stefano},
  journal = {IEEE Transactions on Information Forensics and Security},
  volume = {20},
  pages = {5296 - 5325},
  year = {2025},
  doi = {10.1109/tifs.2025.3570118},
  arxiv = {2506.09807},
  keywords = {rffi,phy-auth,survey}
}
  3. 2022
    G. Shen, J. Zhang, A. Marshall, and J. R. Cavallaro, “Towards scalable and channel-robust radio frequency fingerprint identification for LoRa,” IEEE Transactions on Information Forensics and Security, vol. 17, pp. 774–787, 2022, doi: 10.1109/tifs.2022.3152404.
    DOI arXiv Code Data 
    @article{shen2022scalable,
  title = {Towards scalable and channel-robust radio frequency fingerprint identification for {LoRa}},
  author = {Shen, Guanxiong and Zhang, Junqing and Marshall, Alan and Cavallaro, Joseph R},
  journal = {IEEE Transactions on Information Forensics and Security},
  volume = {17},
  pages = {774--787},
  year = {2022},
  doi = {10.1109/tifs.2022.3152404},
  arxiv = {2107.02867},
  keywords = {rffi,lora,data_code}
}
  4. 2023
    G. Shen, J. Zhang, and A. Marshall, “Deep learning-powered radio frequency fingerprint identification: Methodology and case study,” IEEE Communications Magazine, vol. 61, no. 9, pp. 170–176, 2023, doi: 10.1109/mcom.001.2200695.
    DOI 
    @article{shen2023deep,
  title = {Deep learning-powered radio frequency fingerprint identification: Methodology and case study},
  author = {Shen, Guanxiong and Zhang, Junqing and Marshall, Alan},
  journal = {IEEE Communications Magazine},
  volume = {61},
  number = {9},
  pages = {170 - 176},
  year = {2023},
  doi = {10.1109/mcom.001.2200695},
  keywords = {rffi,survey}
}