[BUG] UEs do not use dedicated gNBs in order

[yoursunny]

When PacketRusher is started with multiple gNB-UE pairs, the first UE connects to the second gNB, the second UE connects to the third gNB, …, the last UE connects to the first gNB. While this does not cause errors, it is a surprising behavior.

To Reproduce

Extract the archive: 2.tgz

# in first console at the extracted directory
docker compose build
docker compose create

# in second console
dumpcap -i br-n2 -w 2.pcapng

# in first console
docker compose up -d
docker logs -f gnb0
# wait approximately 40 seconds until all four UEs are registered

# in second console, press CTRL+C to stop dumpcap

Open 2.pcapng in Wireshark, enter search filter ngap.procedureCode == 15 for InitialUEMessage.

Actual behavior

The first UE connects to the second gNB, the second UE connects to the third gNB, …, the last UE connects to the first gNB.

Expected behavior

UEs with ascending MSINs are using gNBs with ascending gNB-IDs and N2 IPs.

Architecture

• OS: Ubuntu 24.04
• Platform: amd64
• Version: PacketRusher fb27b4610209b8f792f89d50987b4382b97ab266
• Kernel: 6.8.0-55-lowlatency
• Docker: 28.0.1
• gtp5g: v0.9.13

Pcap

2.pcapng.gz

frame #	nrCellIdentity	gNB N2 IP	UE MSIN
54	0x0000000000002000	172.25.198.19	7005551000
67	0x0000000000003000	172.25.198.20	7005551001
82	0x0000000000004000	172.25.198.21	7005551002
96	0x0000000000001000	172.25.198.18	7005551003

Additional context

PacketRusher config:

amfif:
  - ip: 172.25.198.16
    port: 38412
gnodeb:
  controlif:
    ip: 172.25.198.18 # upto 172.25.198.21
    port: 9487
  dataif:
    ip: 172.25.195.18 # upto 172.25.195.21
    port: 2152
  plmnlist:
    gnbid: "000001"
    mcc: "001"
    mnc: "01"
    tac: "000005"
  slicesupportlist:
    sd: "000000"
    sst: "01"
logs:
  level: 6
ue:
  amf: "8000"
  ciphering:
    nea0: true
    nea1: false
    nea2: true
    nea3: false
  dnn: internet
  homeNetworkPublicKey: 5a8d38864820197c3394b92613b20b91633cbd897119273bf8e4a6f4eec0a650
  homeNetworkPublicKeyID: 1
  hplmn:
    mcc: "001"
    mnc: "01"
  integrity:
    nia0: false
    nia1: false
    nia2: true
    nia3: false
  key: 3e2e5a70e2f70f17688bc1006095ede5
  msin: "7005551000" # upto 7005551003
  opc: b4b02d25a63b37093606107ca0ee55e4
  protectionScheme: 0
  routingindicator: "0000"
  snssai:
    sd: "000000"
    sst: 1
  sqn: "00000000"

PacketRusher invocation command line:

packetrusher --config=/config.gnb0.001017005551000.yml multi-ue -n=4 -d

[yoursunny]

I have found the cause of this unexpected behavior.

https://github.com/HewlettPackard/PacketRusher/blob/bd440ebd8238d72ebaa610b9c692e2c7676ac1ef/internal/templates/test-multi-ues-in-queue.go#L77-L92 templates.TestMultiUesInQueue creates UEs with 1-based IDs.

https://github.com/HewlettPackard/PacketRusher/blob/bd440ebd8238d72ebaa610b9c692e2c7676ac1ef/internal/common/tools/tools.go#L120-L137 https://github.com/HewlettPackard/PacketRusher/blob/bd440ebd8238d72ebaa610b9c692e2c7676ac1ef/internal/common/tools/tools.go#L83-L85 tools.SimulateSingleUE chooses the initial gNB with:

i := simConfig.UeId % numGnb
gnbId := ueCfg.GNodeB.PlmnList.GnbId + i

Assuming ueCfg.GNodeB.PlmnList.GnbId is 0x000001:

• For the first UE, i is 1, which generates gNB-ID 0x000002 that is the second gNB.
• For the last UE, i is 0, which generates gNB-ID 0x000001 that is the first gNB.

Since this part of code also affects handover, I need to study the handover code before attempting to change this.