Project

General

Profile

Actions

Bug #4009

open

Channel Activation starts SACCH too early in Synchronous Handover

Added by laforge almost 5 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/19/2019
Due date:
% Done:

50%

Spec Reference:
3GPP TS 48.058 Section 4.1.4

Description

In case of a synchronous hand-over related channel activation, 3GPP TS 48.058 Section 4.1.4 is very specific:

BTS starts transmission immediately on the main channel in the indicated mode and with encryption if so indicated. If
the MS Power and Timing Advance element are present, BTS shall start transmission also on SACCH with the timing
advance and MS power control parameters indicated. If only the MS power element is present the BTS may start
transmission also on the SACCH.
When receiving a correct access burst with the correct handover reference, BTS starts the normal reception process on
the main channel in the indicated mode, with deciphering applied if so indicated, and starts receiving (and sending if not
started earlier) on SACCH. The handover detection procedure towards BSC is also started. Alternatively, the reception
of a correctly decoded frame from the MS on the main channel, in the indicated mode and deciphering applied if so
indicated, allows the start of sending on SACCH (if not already started) and starts the handover detection procedure
towards the BSC.

However, as uncovered by an upcoming BTS_Tests.TC_sacch_chan_act_ho_sync test case, we appear to be activating the SACCH unconditionally from the first moment.

The problem here is quite obvious: Until we have received the access burst from the MS, we don't yet know the timing offset, and hence the timing advance that we should advertise in the downlink SACCH. If we start SACCH transmission too early, it means that a wrong TA is advertised, which may be picked up by the MS, which will then apply a wrong TA value -> boom.


Related issues

Related to OsmoBTS - Feature #3750: Extension of BTS_Tests.ttcn test coverageResolved01/08/2019

Actions
Related to OsmoBSC - Feature #4010: Test RSL CHAN ACT related details for different scenariosNewneels05/19/2019

Actions
Related to OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous HandoverFeedback05/19/2019

Actions
Actions #1

Updated by laforge almost 5 years ago

  • Related to Feature #3750: Extension of BTS_Tests.ttcn test coverage added
Actions #2

Updated by laforge almost 5 years ago

  • Related to Feature #4010: Test RSL CHAN ACT related details for different scenarios added
Actions #3

Updated by laforge almost 5 years ago

There's good news and bad news.

The actual behavior of the BTS is very dependent on the specific PHY used. I've analyzed osmo-bts-trx and osmo-bts-sysmo as two representatives, where lc15 and oc2g are mostly like -sysmo.

osmo-bts-sysmo

osmo-bts-sysmo gets it half-way right. It
  • checks if the activation is HO related, and only activates uplink RACH detection until a RACH is received
  • then activates all other logical channels / SAPIs after the RACH was received
What it gets wrong:
  • it doesn't activate DL main channel (FACCH/SDCCH) while waiting for the RACH
  • it unconditionally delays activation of DL+UL SACCH, even if the MS Power IE and/or TA IE were present in RSL CHAN ACT

osmo-bts-trx

osmo-bts-trx gets it wrong in all cases:
  • it always activates both main channel and SACCH in UL and DL from the very beginning, even before any RACH is received in UL

In fact, osmo-bts-trx and its scheduler don't even know the concept of L1 SAPI and hence don't have the infrastructure to enable/disable individual logical channels within one dedicated channel.

Summary

What does this all mean in practice for osmo-bts-trx? There is a significant risk of poor hand-over performance, as
  • some phones could receive a massively wrong timing advance before we even know the TA
  • some phones could simply refuse to send the RACH if there is no downlink FACCH/SDCCH visible
Actions #4

Updated by laforge over 4 years ago

  • Priority changed from Urgent to High
Actions #5

Updated by laforge over 4 years ago

  • Assignee deleted (laforge)
Actions #6

Updated by laforge over 4 years ago

  • Priority changed from High to Normal
Actions #7

Updated by fixeria about 2 years ago

  • Related to Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handover added
Actions #8

Updated by fixeria about 2 years ago

  • % Done changed from 0 to 50

I am trying to investigate a handover related bug report from one of our customers, so I noticed that TC_sacch_chan_act_ho_sync is failing and stumbled upon this ticket. The scope of my investigation is limited to osmo-bts-trx, so whatever you see below is related to this BTS model only.

First of all, it should be noted that the current osmo-bts master behaves more or less correctly, except one bug in rsl_rx_chan_activ() that I just found and fixed:

https://gerrit.osmocom.org/c/osmo-bts/+/27486 rsl: fix wrong IE being checked in rsl_rx_chan_activ() [NEW]

Test case TC_sacch_chan_act_ho_sync fails because after sending a CHANnel ACTIVation message with only the MS Power IE it does expect Downlink SACCH to be activated immediately, before the first handover RACH is received. The specs. state that "if only the MS power element is present the BTS may start transmission also on the SACCH". May does not mean shall, so osmo-bts-trx does not activate it. I corrected the test case expectations, and it started to pass in my local test setup.

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27487 BTS_Tests: remove misleading comments in f_sacch_{present,missing}() [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27488 BTS_Tests: cosmetic: use setverdict() in f_sacch_{present,missing}() [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27489 BTS_Tests: fix expectations in TC_sacch_chan_act_ho_{sync,async} [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27490 BTS_Tests: exec TC_sacch_chan_act_ho_{sync,async} on g_AllChanTypes[] [NEW]

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)