Change in osmo-bts[master]: early IMM ASS: add configurable delay for RR IMM ASS

laforge gerrit-no-reply at
Tue Aug 17 12:11:05 UTC 2021

laforge has posted comments on this change. ( )

Change subject: early IMM ASS: add configurable delay for RR IMM ASS

Patch Set 4:

I understand why this patch exists, but I think it should not.  I'd prefer to understand what exactly is creating a problem here, rather than introducing arbitrary configurable delays because we've seen those to work in one specific situation.

If the channel is really active on the radio side [i.e.we are already transmitting valid downlink SACCH contents?], any IA after that point in time should not fail.

Maybe there is a problem in osmo-bts-trx that makes it confirm channel activation too early towards the upper layers?  Maybe this is "only" the rts-advance we're seeing here?  I.e. channel activated in scheduler, but the PHY is still transmitting downlink bursts which were already pre-computed? In that case, shouldn't either the CHAN ACT ACK contain the exact frame number from which the channel will actually be active, or at least this newly introduced timeout correspond to the rts-advance / fn-advance?

To view, visit
To unsubscribe, or for help writing mail filters, visit

Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: Ia1e63b98944dc840cde212fc732e20277cdc5585
Gerrit-Change-Number: 25201
Gerrit-PatchSet: 4
Gerrit-Owner: neels <nhofmeyr at>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: Hoernchen <ewild at>
Gerrit-CC: fixeria <vyanitskiy at>
Gerrit-CC: laforge <laforge at>
Gerrit-Comment-Date: Tue, 17 Aug 2021 12:11:05 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gerrit-log mailing list