Project

General

Profile

Actions

Bug #3525

closed

handover is unreliable

Added by neels over 5 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
High
Assignee:
Category:
osmo-bts-sysmo
Target version:
-
Start date:
09/05/2018
Due date:
% Done:

0%

Spec Reference:

Description

when attempting intra-cell handovers using sysmoBTS, I currently get at best a success rate of 1 out of 10.
This tracks investigation of the problem.

Actions #1

Updated by fixeria over 5 years ago

  • Category set to osmo-bts-sysmo
Actions #2

Updated by neels over 5 years ago

  • Category deleted (osmo-bts-sysmo)
  • Status changed from New to In Progress
  • Priority changed from Normal to High

Measurement reports weirdness:

  • Normally, when activating a channel when establishing a call, we very soon get measurements for the new channel and send a measurement report to the BSC.
  • After RSL Chan Activ and RSL Chan Activ ACK for handover, however, there are no measurements for a while.

Using a not-yet-merged patch from pmaier to log measurements in detail ("adding measurement") in osmo-bts, I see that we are not receiving any measurements from the l1.

Looking at the failing cases:

0ms   Channel Activ Ack
      (no measurements from l1 all this time)
700ms Handover Failure

Looking at the cases where handover succeeds:

0ms   Channel Activ Ack
200ms first Handover Detection
      couple more Handover Detection
250ms last Handover Detection
260ms first measurement from l1, from now on every ~15ms
400ms RSL Establish IND
550ms Handover Complete

Looks bleak in comparison to a normal TCH/F channel activation:

0ms   Chan Activ ACK
2ms   first measurement from l1
21ms  2nd
45ms  3rd
56ms  4th
62ms  5th

(these timings according to the packet timestamps when the gsmtap_log is received on the core host, didn't bother with the gsmtap_log timestamps themselves)

It actually looks like the l1 purposefully waits for a Handover Detection before it even considers sending measurements.
Which does make sense to me, as these are uplink measurements, and we wouldn't get any if the MS isn't telling us about them, IIUC.

So, I think examining measurements for handover, as I did now, is actually moot.

Actions #3

Updated by neels over 5 years ago

  • Category set to osmo-bts-sysmo
Actions #4

Updated by neels over 5 years ago

  • Status changed from In Progress to Rejected

so I assumed my BTS were well calibrated, but after going through sysmobts-calib the handover is super reliable. 100% success rate.
(sigh) another episode of "how to waste time unnecessarily by assuming things".

Actions #5

Updated by laforge over 5 years ago

On Wed, Sep 05, 2018 at 01:22:21PM +0000, neels [REDMINE] wrote:

  • Normally, when activating a channel when establishing a call, we very soon get measurements for the new channel and send a measurement report to the BSC.
  • After RSL Chan Activ and RSL Chan Activ ACK for handover, however, there are no measurements for a while.

Using a not-yet-merged patch from pmaier to log measurements in detail ("adding measurement") in osmo-bts, I see that we are not receiving any measurements from the l1.

This may be related to the L1 SAPIs we activate at that point. I guess we only activate RACH, then wait for the RACH bursrts to arrive, and then actually activate the TCH/F, FACCH/F, SACCH/TF (for a TCH/H) SAPIS. And then my suspicion is that measurement reports are only generated once those L1 SAPIs are active.

Probably not worth investigating further as you have discovered BTS frequency calibration was to be blamed.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)