Proposal for consistent c-rnti and UE index

[ciccio25]

Hello,
I would like to propose an improvement regarding the c-rnti order.

The c-rnti that a UE receives depends on the order in which it completes RACH — not on its UE number (ue1.conf, ue2.conf, etc.). This makes it easy to misread gNB logs when debugging per-UE behavior (e.g. network slicing), since gnb.log's ue=N index does not necessarily correspond to UE N.

In the following issue, I used the latest commit b17514b with the default installation.

Problem

In run.sh#L91-L93, UEs are started in this order:

./run_background.sh 3
./run_background.sh 2
./run.sh

UE3 and UE2 start first (background), UE1 starts last (foreground). Since c-rntithe assignment follows RACH completion order, this makes it likely — but not guaranteed — that UE1 ends up with a later c-rnti than UE2/UE3.

Attempted fix (did not work)

I tried reordering the script run.sh to start UE1 first, but it didn't work as intended:

./run_background.sh 1
./run_background.sh 2
./run.sh 3

Expected:

UE	ue index SCHED	c-rnti
1	0	0x4601
2	1	0x4602
3	2	0x4603

Actual result:

UE	ue index SCHED	c-rnti
1	1	0x4602
2	0	0x4601
3	2	0x4603

UE1 and UE2 are still swapped, despite starting in config-file order, so reordering run.sh is not a reliable fix on its own, as shown in the following stdout of the 3 UEs.

Script started on 2026-07-11 10:59:03+02:00 [TERM="xterm-256color" TTY="/dev/pts/11" COLUMNS="133" LINES="33"]
Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_zmq.so
Inactive RF plugins: 
Reading configuration file configs/ue1.conf...

Built in Release mode using commit 6bcbd9e5b on branch master.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://*:2101,rx_port=tcp://10.201.0.5:2100,base_srate=23.04e6
Supported RF device list: UHD zmq file
CHx base_srate=23.04e6
Current sample rate is 1.92 MHz with a base rate of 23.04 MHz (x12 decimation)
CH0 rx_port=tcp://10.201.0.5:2100
CH0 tx_port=tcp://*:2101
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=334
Random Access Complete.     c-rnti=0x4602, ta=0
RRC Connected
PDU Session Establishment successful. IP: 10.45.0.101
RRC NR reconfiguration successful.
^CStopping ..
---  exiting  ---

Script done on 2026-07-11 11:00:49+02:00 [COMMAND_EXIT_CODE="0"]

Script started on 2026-07-11 10:59:01+02:00 [<not executed on terminal>]
Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_zmq.so
Inactive RF plugins: 
Reading configuration file configs/ue2.conf...

Built in Release mode using commit 6bcbd9e5b on branch master.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://*:2201,rx_port=tcp://10.201.0.9:2200,base_srate=23.04e6
Supported RF device list: UHD zmq file
CHx base_srate=23.04e6
Current sample rate is 1.92 MHz with a base rate of 23.04 MHz (x12 decimation)
CH0 rx_port=tcp://10.201.0.9:2200
CH0 tx_port=tcp://*:2201
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...
Closing stdin thread.
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=174
Random Access Complete.     c-rnti=0x4601, ta=0
RRC Connected
PDU Session Establishment successful. IP: 10.45.0.102
RRC NR reconfiguration successful.

Script started on 2026-07-11 10:59:00+02:00 [<not executed on terminal>]
Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_zmq.so
Inactive RF plugins: 
Reading configuration file configs/ue3.conf...

Built in Release mode using commit 6bcbd9e5b on branch master.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://*:2301,rx_port=tcp://10.201.0.13:2300,base_srate=23.04e6
Supported RF device list: UHD zmq file
CHx base_srate=23.04e6
Current sample rate is 1.92 MHz with a base rate of 23.04 MHz (x12 decimation)
CH0 rx_port=tcp://10.201.0.13:2300
CH0 tx_port=tcp://*:2301
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...
Closing stdin thread.
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=174
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=334
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=494
Random Access Complete.     c-rnti=0x4603, ta=0
RRC Connected
PDU Session Establishment successful. IP: 10.45.0.103
RRC NR reconfiguration successful.

Why this matters (concrete example)

I tested network slicing in the testbed, and I added these lines to the gNB conf file:

  slicing:
    - sst: 1
      sd: 1
      sched_cfg:
        min_prb_policy_ratio: 0
        max_prb_policy_ratio: 10
    - sst: 1
      sd: 2
      sched_cfg:
        min_prb_policy_ratio: 0
        max_prb_policy_ratio: 30
    - sst: 1
      sd: 3
      sched_cfg:
        min_prb_policy_ratio: 0
        max_prb_policy_ratio: 60

Pinging traffic from UE3 to the core (correctly, consistently mapped to 0x4603 across runs) produces the expected scheduler behavior — 63 PRB, i.e. sd=3's 60% quota:

2026-07-11T11:54:48.152591 [SCHED] [D] [561.8] Slot decisions pci=1 t=87us (0 PDSCHs, 1 PUSCH, 0 PUCCHs, ...):
- UE PUSCH: ue=2 c-rnti=0x4603 h_id=0 rb=[0..63) symb=[0..14) tbs=1985 ...

But pinging from UE1 to the core (which in that run held 0x4602, not 0x4601) produces:

2026-07-11T08:59:27.403809 [SCHED] [D] [415.7] Slot decisions pci=1 t=44us (0 PDSCHs, 1 PUSCH, 0 PUCCHs, ...):
- UE PUSCH: ue=1 c-rnti=0x4602 h_id=0 rb=[0..10) symb=[0..14) tbs=225 ...

At first glance this looks like ue=1 (our UE 2) (associated with sd=2, 10%) is receiving sd=1's 10% quota — a scheduler bug.

In reality ue=1/0x4602 is UE1, and 10 PRB (10%) is exactly its own correctly-applied quota.
Without independently checking each UE's own stdout (Random Access Complete. c-rnti=0x...), this is very easy to misdiagnose as an OCUDU bug.

Suggested fix

The fix should be ensuring UEs are assigned a c-rnti matching their UE number (UE1→0x4601, UE2→0x4602, UE3→0x4603) deterministically.

Logs and stdout captures attached for reference here

UE 1 and UE 3 pinging to core.zip

Thank you for taking the time to look into this.