Channel Activation starts SACCH too early in Asynchronous Handover

Added by laforge 5 months ago. Updated 3 months ago.

Status:

New

Priority:

Normal

Assignee:

Category:

Target version:

Start date:

05/19/2019

Due date:

% Done:

Spec Reference:

3GPP TS 48.058 Section 4.1.3

Description

In case of an asynchronous hand-over related channel activation, 3GPP TS 48.058 Section 4.1.3 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 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 and starts receiving (and sending if not started earlier) on SACCH. Deciphering
is started if so indicated. The handover detection procedure towards BSC is also started.

However, as uncovered by an upcoming BTS_Tests.TC_sacch_chan_act_ho_async 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.

Checklist

osmo-bts-sysmo
osmo-bts-oc2g
osmo-bts-lc15
osmo-bts-trx

Related issues

History

#1 Updated by laforge 5 months ago

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

#2 Updated by laforge 5 months ago

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

#3 Updated by laforge 5 months ago

Checklist item osmo-bts-sysmo added
Checklist item osmo-bts-oc2g added
Checklist item osmo-bts-lc15 added
Checklist item osmo-bts-trx added

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