Skip to content

Challenge 4: Receiver-Invariant Device Identification Under Single Receiver Replacement

Abstract

Radio Frequency Fingerprinting Identification (RFFI) is a physical-layer authentication technique that identifies wireless transmitters by learning unique hardware-induced signal impairments [1]. While RFFI has shown strong performance under controlled conditions, practical long-term deployments introduce a critical challenge: receiver hardware may need to be replaced due to failures, maintenance, or upgrades [2]. When this happens, the new receiver introduces its own hardware-specific distortions, causing a domain shift that degrades the performance of a previously trained RFFI model. This problem is particularly relevant for Internet of Things (IoT) deployments in 6G networks, where continuous and autonomous device authentication is required.

This challenge addresses the problem of maintaining reliable Radio Frequency (RF) fingerprinting performance when the monitoring receiver is replaced by another device in a deployed IoT system. When a new receiver is introduced, its hardware characteristics differ from those of the original receiver, leading to a domain shift and degraded identification performance. The challenge is based on an experimental dataset collected from 30 identical IoT transmitters, captured simultaneously by multiple software-defined radio receivers, enabling a controlled and reproducible study of this effect. The goal is to develop methods that adapt a trained RFFI model to a new, unseen receiver using only unlabeled signals collected after the replacement. This reflects a realistic post-deployment condition where relabeling data is not feasible. The scenario aligns with zero-touch operational requirements in 6G IoT systems, where security mechanisms must remain functional under hardware changes without manual intervention.

Dataset

The RF Fingerprinting Migration Dataset [3], introduced in Deliverable 5.1 [4] (Section 3.2.1), is publicly available at: https://zenodo.org/records/14801935

The dataset consists of raw In-phase and Quadrature (IQ) samples collected from 30 identical TI CC13XX IoT transmitters operating at 866 MHz using 2-GFSK modulation, as illustrated in Figure 1.

Receiver infrastructure

(a) Receiver infrastructure

30 IoT transmitters

(b) 30 IoT transmitters

Transmission scenario

(c) Transmission scenario

Figure 1: Experimental setup for receiver-invariant RF fingerprinting, including (a) Software-Defined Radio (SDR)-based receiver infrastructure, (b) 30 identical IoT transmitters used to collect data, and (c) an example transmission scenario illustrating data collection.

Each transmitted packet is captured by all receivers under synchronized conditions, and only successfully decoded packets are retained. This ensures that the same transmission instance can be directly compared across different receiver hardware. The dataset contains 815,367 packets collected in a controlled indoor environment, with transmitter–receiver distances of 0.5, 1, and 1.5 m. The consistent packet structure and sequence numbering allow reliable alignment of transmissions across receivers. This dataset enables the study of receiver-induced domain shift in RF fingerprinting and supports the development of methods for robust device identification under varying receiver conditions.

Challenge Description

No additional software is required beyond standard deep learning libraries.

In this challenge, an RFFI model is trained on labeled data collected from an initial receiver. After deployment, that receiver is replaced by a new one for which no labeled data is available. The goal is to adapt the model so that transmitter identification remains reliable on the new receiver. This challenge follows an open benchmark format. Participants train their own models, run their own experiments, and self-report results. They are encouraged to publish their findings citing the dataset. No base model is provided; participants must train their source model from scratch.

Data Split: The following fixed chronological split must be applied independently per receiver, per transmitter, and per transmission distance. Data from all three transmission distances (0.5, 1, and 1.5 m) must be used in training, adaptation, and evaluation:

  • Source Training: Packets 0–599 (600 packets per transmitter per distance), labeled data for training the source model.
  • Source Validation: Packets 600–699 (100 packets per transmitter per distance), labeled data for source model selection.
  • Source Test: Packets 700–799 (100 packets per transmitter per distance), held-out labeled data for evaluating the source model before deployment.
  • Adaptation: Packets 800–1399 (600 packets per transmitter per distance), unlabeled packets from the target receiver for unsupervised adaptation.
  • Oracle: Packets 1400–1499 (100 packets per transmitter per distance), labeled packets from the target receiver. These may optionally be used strictly for adapted model selection. They must not be used for training or fine-tuning the model. Any use of the Oracle split must be explicitly declared.
  • Challenge Test: Packets 1500–1599 (100 packets per transmitter per distance), held-out packets from the target receiver used to compute the final reported score.

Constraint: Data used for training the source model must not be reused during the adaptation phase. Any use of labeled target data must be explicitly declared and must not exceed the scope permitted by the chosen track category.

Example: A participant trains the source model using packets 0–599 from receiver R2. When adapting to R1 or R3, only packets 800–1399 from the target receiver may be used for adaptation. Packets 0–599 from R1 or R3 must not be used in any adaptation or evaluation step, as that interval is reserved exclusively for source model training.

Input and Output

Input: Raw IQ packets from the Challenge Test split of the target receiver, collected at all three transmission distances (0.5, 1, and 1.5 m), with receiver identity and sequence number information provided per packet. The challenge must be evaluated across all six source-target receiver pairs.

Output: The average Delta-F1 score across all six source-target transfer directions, as defined in the Evaluation Metric section. Participants must also submit a description of their methodology, including data preprocessing steps, model architecture, training procedure, adaptation strategy, and whether the Oracle split was used for model selection.

Evaluation Metric

The primary ranking metric is the Average Delta-F1, defined as:

Delta-F1 formula

(1)

where k indexes the six source-target receiver pairs, F1adapted(k) is the macro-averaged F1-score of the adapted model on the Challenge Test split of pair k, and F1baseline(k) is the macro-averaged F1-score of the unadapted source model on the same split. A higher ΔF1 indicates greater and more consistent performance recovery across all transfer directions. The macro-averaged F1-score is defined as:

Macro F1 formula

(2)

where C = 30 is the number of transmitter classes, and Pc and Rc are the precision and recall for class c, respectively. Macro-averaging is used to account for class imbalance, as the number of captured packets varies across transmitters. Participants must also report the per-direction Delta-F1 and absolute F1adapted scores as secondary metrics.

Bibliography

  1. 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.
  2. L. Xie, L. Peng, J. Zhang et al., “Radio frequency fingerprint identification for Internet of Things: A survey,” Security and Safety, vol. 3, 2024.
  3. C. Ayyildiz, F. E. Yildiz, O. Ayyildiz, and V. C. Yildirim, “RF fingerprinting migration dataset,” Zenodo, 2025, ROBUST-6G project, Version v2, CC-BY-4.0. https://doi.org/10.5281/zenodo.14801935
  4. “Deliverable D5.1: Library of known PHY attacks and PLS dataset,” Horizon Europe Project ROBUST-6G, Tech. Rep. Grant Agreement No. 101139068, 2024. PDF

To participate: submit your solution using the submission form.