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¶

• 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

• 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¶

• 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¶

• 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

Patches have been merged to keep SACCH deactivated in certain situations
(depending on what IEs the BSC sent during Channel Activation).

Still, OsmoBSC always sends the MS Power IE, so those patches will never have an effect when using OsmoBSC.
The rather non-trivial question is: what IEs should the BSC send in which situations?

The aim of this ticket is to keep SACCH deactivated as long as the TA is not known.
3GPP TS 48.058 4.1.3 and 4.1.4 define which SAPIs should be enabled for a handover target lchan.
Summary of that spec:

          |          | Access ||  transmit         |  activate  
          | MS Power | Delay  ||  on main channel  |  dl SACCH  
 ----------------------------------------------------------------------
 async ho   no         *     -->  yes                 no        
 async ho   yes        *     -->  yes                 may be started
 sync ho    no         no    -->  yes                 no        
 sync ho    yes        no    -->  yes                 may be started
 sync ho    yes        yes   -->  yes                 shall be started

So for this ticket we are mostly interested in the MS Power IE being present or not.

Looking at 3GPP TS 48.058 we get this information from the footnotes:

• MS Power IE has two different meanings:
  • when MS Power Parameters IE is not present: MS Power IE indicates the initial power the MS should use.
  • when MS Power Parameters IE is present: MS Power IE indicates the maximum permitted MS power value.

OsmoBSC transmits the MS Power Parameters IE only when in dynamic power control mode.
See https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/abis_rsl.c?id=80184ae1714f52cbeed8d94472975f07122e806f#n205

For a new lchan assignment or handover to another cell, OsmoBSC sends the bts->ms_max_power in the MS Power IE.
For a handover within the same cell, OsmoBSC sends the previous lchan's MS power in the MS Power IE.
(see https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/lchan_fsm.c?id=80184ae1714f52cbeed8d94472975f07122e806f#n577)

So, first of all, it seems that we have a bug in OsmoBSC:
If a channel activation for handover sends both MS Power IE as well as MS Power Parameters IE (in dynamic power control mode),
then the BTS should interpret the MS Power IE as the maximum permitted MS power. But we send the previous lchan's power.

The other question is whether we can or ever should omit the MS Power IE from a channel activation,
to get the effect that we wanted to achieve with this issue in the first place,
being to omit the DL SACCH from a handover channel activation until the TA is known.
I would have assumed that the lchan should omit DL SACCH when the Timing Advance is omitted from the Channel Activation,
but at least for async HO, the TA presence (the Access Delay IE) apparently does not make any difference in the decision
to activate DL SACCH or not on initial channel activation, according to the spec.

At this moment I am a bit confused / undecided on what IEs the BSC should send in what situations...
any help is welcome.

the merged patches are
https://git.osmocom.org/osmo-bts/commit/?id=f733cf826375a3f348b6195b286af872beef0ff7
https://git.osmocom.org/osmo-bts/commit/?id=1c05ef15ecb1a9053112b2c11bb5c062cee06478
https://git.osmocom.org/osmo-bts/commit/?id=61585254338d16bb359987ad1f4537900e6288db
https://git.osmocom.org/osmo-bts/commit/?id=4ee4d6be2a66a151de0fc0ef258d89fad4135a91
https://git.osmocom.org/osmo-bts/commit/?id=def24f0d9af2463a5ef557d35f23abd5b4d07120

 async ho   yes        *     -->  yes                 may be started

I just realize that OsmoBTS could always deactivate DL SACCH for async HO,
regardless of the MS Power IE presence, because the spec says the DL SACCH may be started, not shall be started.

For sync HO it's a bit different, but this ticket here is about async HO.

          |          | Access ||  transmit         |  activate  
          | MS Power | Delay  ||  on main channel  |  dl SACCH  
 ----------------------------------------------------------------------
 async ho   no         *     -->  yes                 no        
 async ho   yes        *     -->  yes                 may be started
 sync ho    no         no    -->  yes                 no        
 sync ho    yes        no    -->  yes                 may be started
 sync ho    yes        yes   -->  yes                 shall be started

A possible overall solution for both async and sync handover:

• when both MS Power and Access Delay IEs are present, then activate SACCH.
• otherwise, do not activate SACCH.

This would adhere to all the "no" rows, would opt for not sending SACCH for all "may be started" rows,
and also adheres to the last "shall be started" row.

Hence OsmoBSC would in practice trigger DL SACCH activation or not by sending Access Delay or not.
Then we can implement in OsmoBSC that we mostly omit an Access Delay IE in HO channel activation.
Send Access Delay only when it is an intra-cell HO with an already known TA.

I am trying to investigate a handover related bug report from one of our customers, so I noticed that TC_sacch_chan_act_ho_async 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.

Test case TC_sacch_chan_act_ho_async fails because after sending a CHANnel ACTIVation message with 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 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]