Cellular Network Infrastructure

With two sysmoBTS and the osmo-bsc branch neels/ho2, with 'handover algorithm 2' set in the config, this is what the problem looks like on the HODEC logging output:

Initially:

DHODEC DEBUG handover_decision_2.c:1129 (lchan 1.020 TCH/F) (subscr unknown) MEASUREMENT REPORT
DHODEC DEBUG handover_decision_2.c:1134 (lchan 1.020 TCH/F) (subscr unknown)   0: arfcn=868 bsic=63 neigh_idx=0 rxlev=57 flags=0
DHODEC DEBUG handover_decision_2.c:291 (lchan 1.020 TCH/F) (subscr unknown) neigh 868 new in report rxlev=57 last_seen_nr=0
DHODEC DEBUG handover_decision_2.c:1156 (lchan 1.020 TCH/F) (subscr unknown) HODEC2: evaluating measurement report

Once the error is occuring, I see:

DHODEC DEBUG handover_decision_2.c:1129 (lchan 0.020 TCH/F) (subscr unknown) MEASUREMENT REPORT
DHODEC DEBUG handover_decision_2.c:1134 (lchan 0.020 TCH/F) (subscr unknown)   0: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
DHODEC DEBUG handover_decision_2.c:1134 (lchan 0.020 TCH/F) (subscr unknown)   1: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
DHODEC DEBUG handover_decision_2.c:1134 (lchan 0.020 TCH/F) (subscr unknown)   2: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
DHODEC DEBUG handover_decision_2.c:1134 (lchan 0.020 TCH/F) (subscr unknown)   3: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
DHODEC DEBUG handover_decision_2.c:1134 (lchan 0.020 TCH/F) (subscr unknown)   4: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
DHODEC DEBUG handover_decision_2.c:1134 (lchan 0.020 TCH/F) (subscr unknown)   5: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
DHODEC DEBUG handover_decision_2.c:1134 (lchan 0.020 TCH/F) (subscr unknown)   6: arfcn=0 bsic=0 neigh_idx=0 rxlev=0 flags=0
DHODEC DEBUG handover_decision_2.c:1156 (lchan 0.020 TCH/F) (subscr unknown) HODEC2: evaluating measurement report

The obviously weird thing is that there is a list of six neighbors zeroed out. Before, the list length was a useful value and reflected the single reported neighbor.

The RR Measurement Report PDU does not actually pass ARFCNs directly, the above list is computed. So bugs are possible there...

with all the changes/fixes going into OsmoBTS during the last 7-10 days, it might be worth re-testing if this issue still persists at all.

I thought the same, and, when was it, like 24 hours ago I still got the same symptoms, unfortunately. Still need to hunt it, it seems.

Tested again today; besides seeing various oddities, I also still see the measurement reports missing for neighbors after a handover.
There is a fix on gerrit for the weird list of seven(!) empty neighbors: https://gerrit.osmocom.org/7149

And I verified again that SI2 does include the respective other neighbor.
Attached pcap (with just two packets) shows the SI2 with the neighboring ARFCN and the empty neighbor measurements; the two packets were actually adjacent in the taken overall trace.

In 3GPP TS 04.18 10.5.2.10, it says
"1 1 1 Neighbour cell information not available for serving cell"
Which sounds almost like the cell was asked to measure itself as a neighbor, as if we told it that its own ARFCN were its neighbor.

However, attached pcap confirms that the BTS with ip 192.168.0.21 has ARFCN 870 (see packet 839, where OML sets the ARFCN BTS attribute)
and advertises neighbor 868 in its SI2 (see packet 1476)
yet says the above bits in the Measurement Report, packet 1488.

I'm still in the dark about why we get empty neighbor cell lists in the measurement reports.

Could the Extended Measurement Report be related? According to 3GPP TS 04.18 we would send a Extended Measurement Order to the MS with a list of frequencies to report on, and would receive an Extended Measurement Report on those. However, if we already expect six neighbors as inidicated in SI2 to be reported in the non-extended Measurement Report, I don't see the need to use the Extended one.

actually, not SI2 is the important message in this context, but SI5.

After the handover to the new BTS, the phone of cours has no way of knowing what's broadcast on the BCCH. Instead, it relies on the SI5/5bis/5ter messages sent by the new cell in its SACCH downlink.

So if the new cell had some errors in its SI5* messages, that would explain why measurement reports cease to contain neighbors after handover.

well, shucks, looks like my network isn't even sending out any SI5* to begin with.

The problem is fixed by #3057 and #3059! i.e. https://gerrit.osmocom.org/7220 and https://gerrit.osmocom.org/#/c/7218/
A lot of head scratching is finally over and I can go on to properly test handover decision 2! Thank the holy powers of two.
Let me resolve this here and leave tracking to those other two issues.