5G NR-ARFCN Priority-Based Cell Reselection Testing with srsRAN - Implementation Challenges

[DerMichael0408]

Objective
I'm conducting research on 5G Fake Base Station (FBS) attacks, specifically testing priority-based cell reselection behavior in IDLE mode. My goal is to demonstrate that a UE will prefer a malicious FBS on a high-priority frequency over legitimate cells on lower-priority frequencies.

Test Scenario
Setup:

gNB1 (legitimate): ARFCN 633984, PCI 0, Cell ID 0xa, tx_gain: 50, rx_gain: 30

gNB2 (legitimate): ARFCN 635232, PCI 2, Cell ID 0xb, tx_gain: 53, rx_gain: 30

FBS (attacker): ARFCN 633984, PCI 3, Cell ID 0xc, tx_gain: 50, rx_gain: 30

Expected Behavior:

1. UE connects to gNB1 (ARFCN 633984)

2. UE receives RRC Release with frequency priorities: 633984= Priority 6, 635232= Priority 2; Trigger: 4sec inactivity timer

3. UE enters RRC_IDLE and should prefer FBS when reselecting (same high-priority ARFCN as gNB1)

4. UE should ignore gNB2 (lower priority despite stronger signal)

Current Status

• 3GPP 38.304 states that only NR-ARFCNs mentioned in broadcasting messages are candidates in reselection, except for serving ARFCN (automatically included in reselection) -> Send out SIB4 with ARFCN 635232 entry -> SIB4 sets priority 1 for 635232 and is overwritten by RRC Release priority 2 in the UE

• Implemented hardcoded RRC Release in the lib/rrc/ue/rrc_ue_message_handlers.cpp with dedicated priorities, packs this message
  {
  "message": {
  "c1": {
  "rrcRelease": {
  "criticalExtensions": {
  "rrcRelease": {
  "cellReselectionPriorities": {
  "freqPriorityListNR": [
  {
  "carrierFreq": 633984,
  "cellReselectionPriority": 6
  },
  {
  "carrierFreq": 635232,
  "cellReselectionPriority": 2
  }
  ],
  "t320": "min30"
  }
  }
  },
  "rrc-TransactionIdentifier": 0
  }
  }
  }
  }

• Tried to implement SIB4 in /lib/du/du_high/du_manager/converters/f1ap_configuration_helpers.cpp which results in this message
  {
  "interFreqCarrierFreqList": [
  {
  "absThreshSS-BlocksConsolidation": {
  "thresholdRSRP": 70
  },
  "cellReselectionPriority": 1,
  "deriveSSB-IndexFromCell": false,
  "dl-CarrierFreq": 635232,
  "frequencyBandList": [
  {
  "freqBandIndicatorNR": 78
  }
  ],
  "nrofSS-BlocksToAverage": 8,
  "q-OffsetFreq": "dB0",
  "q-RxLevMin": -64,
  "smtc": {
  "duration": "sf3",
  "periodicityAndOffset": {
  "sf20": 0
  }
  },
  "ssbSubcarrierSpacing": "kHz30",
  "t-ReselectionNR": 1,
  "threshX-HighP": 11,
  "threshX-LowP": 11
  }
  ...
  ]
  }

• Configure sib usage in the gnb1.yml. SIB4 not implemented in srsRan, therefore created together with SIB2

sib:
si_window_length: 20 # Short window for frequent updates
si_sched_info:
- si_period: 8 # Broadcast every 8 radio frames (80ms)
sib_mapping: 2 # Include

Observations

✅ RRC Release message is sent successfully

✅ UE transitions to RRC_IDLE after 4s inactivity timer

✅ After moving UE closer two gnb2 and FBS it reselects to either

❌ UE selects gNB2 (priority 2, stronger) over FBS (priority 6, same ARFCN)

Debugging Attempts

SIB4 Issues: srsRAN rejects SIB4 in sib_mapping with error "4 not in {2,19}"

Priority Validation: Cannot confirm if UE processes RRC Release priorities

Questions for the Community
Is my current approach with sending hardcoded SIB4 and RRC Release viable, or does srsRan not enable dedicated priority signaling?

Priority Verification: How can I verify that RRC Release priorities are correctly formatted and received by the UE?

UE Compliance: Are there known issues with commercial UEs not following 3GPP TS 38.304 priority-based reselection procedures?

Alternative Approaches: Would using srsUE instead of commercial UE provide more predictable reselection behavior?

Environment
srsRAN Version: Latest (commit 20.10)

Core Network: Open5GS

Hardware: USRP B210 × 3

UE: Samsung Galaxy S25 Edge with programmable SIM card