Project

General

Profile

Actions

Bug #2963

closed

Measurement Reports cease to be useful some time into a voice call / after handover (not sure which project has the bug / bugs yet)

Added by neels about 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
02/19/2018
Due date:
% Done:

100%

Spec Reference:

Description

Have two BTSes (so far tested with sysmoBTS) and start a voice call between two phones.
Each phone sends measurement reports on the respective other neighbor cell.
However, after performing a handover, the measurement reports cease to be useful.

(Details follow.)

For a pcap, see https://osmocom.org/attachments/download/2947/failing_meas_reports_after_a_while.pcapng (attached to #1606)


Files

si2_and_meas_rep.pcapng si2_and_meas_rep.pcapng 344 Bytes neels, 03/08/2018 03:51 AM
neighbor_cells_are_correct.pcapng neighbor_cells_are_correct.pcapng 474 KB neels, 03/08/2018 04:23 AM

Related issues

Related to OsmoBTS - Bug #3057: OsmoBTS fails to schedule SACCH filling like SI5Resolvedlaforge03/11/2018

Actions
Related to OpenBSC - Bug #3059: System Information on SACCH missing L2 Pseudo-LengthResolvedlaforge03/11/2018

Actions
Blocks OsmoBSC - Feature #1606: hand-over for load distribution among BTSsResolvedneels02/23/2016

Actions
Blocks OsmoBSC - Bug #3002: HO2: handover decision for dynamic timeslotsNewneels02/26/2018

Actions
Actions #1

Updated by neels about 6 years ago

  • Blocks Feature #1606: hand-over for load distribution among BTSs added
Actions #2

Updated by neels about 6 years ago

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...

Actions #3

Updated by neels about 6 years ago

  • Description updated (diff)
Actions #4

Updated by neels about 6 years ago

  • Blocks Bug #3002: HO2: handover decision for dynamic timeslots added
Actions #5

Updated by laforge about 6 years ago

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.

Actions #6

Updated by neels about 6 years ago

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.

Actions #7

Updated by neels about 6 years ago

  • Status changed from New to In Progress
  • Assignee set to neels
Actions #8

Updated by neels about 6 years ago

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.

Actions #9

Updated by neels about 6 years ago

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.

Actions #10

Updated by neels about 6 years ago

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.

Actions #11

Updated by laforge about 6 years ago

On Thu, Mar 08, 2018 at 04:38:41AM +0000, neels [REDMINE] wrote:

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.

indeed. extended is only required for meaurement of cells of different RAT or more cells, AFAIK.

Actions #12

Updated by laforge about 6 years ago

Would be a good idea to verify the decoded SI2 message with e.g. a TEMS phone
or some eother third-party decoder. Maybe wireshark is displaying an erroneous
message without indicating any "ERROR", but the phone is discarding it due to some
wrong bit somewhere.

Actions #13

Updated by laforge about 6 years ago

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.

Actions #14

Updated by neels about 6 years ago

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

Actions #15

Updated by laforge about 6 years ago

On Sun, Mar 11, 2018 at 12:58:26AM +0000, neels [REDMINE] wrote:

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

Do you see the SACCH FILLING for SI5 on Abis/RSL durning RSL start-up? If yes,
then it's a BTS problem. If not, it's the BSC.

But at least there's a clean explanation now.

btw: I've just started working on SACCH tests in BTS_Tests.ttcn. So far I only
have the test to check if DEACT SACCH works on all channel combinations.

SACCH FILL and SACCH INFO MODIFY is currently in progress, as is testing for
different SI combinations (5/5bis/5ter/6) on SACCH.

Actions #16

Updated by laforge about 6 years ago

  • Related to Bug #3057: OsmoBTS fails to schedule SACCH filling like SI5 added
Actions #17

Updated by laforge about 6 years ago

  • Related to Bug #3059: System Information on SACCH missing L2 Pseudo-Length added
Actions #18

Updated by neels about 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 10 to 100

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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)