Clarification regarding unexpected UE serving-cell changes with NrNoOpHandoverAlgorithm

[Shankar Balu T.M.B]

Dear CTTC 5G-LENA Team,

I am currently using 5G-LENA v5.1 for a 7-gNB, 35-UE simulation in which a controller explicitly selects a gNB to enter a sleep state. Before putting the selected gNB to sleep, the UEs currently attached to that gNB are handed over using NrHelper::HandoverRequest().

To ensure that handovers are controlled only by my controller, I configure:

nrHelper->SetHandoverAlgorithmType("ns3::NrNoOpHandoverAlgorithm");

and I explicitly trigger handovers only for UEs attached to the gNB selected for sleep.

However, I am observing an unexpected behaviour. In one run, only gNB 7 was selected for sleep. At 2 s, the connected UE counts were:

gNB1: 2
gNB2: 7
gNB3: 5
gNB4: 7
gNB5: 3
gNB6: 9
gNB7: 2

The two UEs attached to gNB 7 were explicitly handed over to gNB 1, which is expected. At 4 s, the connected UE counts became:

gNB1: 4
gNB2: 9
gNB3: 4
gNB4: 6
gNB5: 3
gNB6: 9
gNB7: 0

The change from gNB7 to gNB1 is expected, but I also observe that gNB2 gains two UEs while gNB3 and gNB4 each lose one UE, even though no explicit handover request was issued for those cells.

The UEs are using RandomWalk2dMobilityModel at approximately 1.5 m/s.

Could you please clarify whether, when NrNoOpHandoverAlgorithm is used, a UE can still change its serving cell through another mechanism such as radio link failure, reconnection, cell selection/reselection, or another RRC procedure?

If so, is there a recommended way in 5G-LENA to disable these unintended serving-cell changes temporarily, so that I can isolate and evaluate only the controller-triggered handovers?

Thank you very much for your help.

Warm regards,
Shankar Balu

[Gabriel Ferreira]

It can switch, like you said. It will go through RLF, scan for a new cell and attach to it. You can disable RLF to accomplish your goal.