hand-over in L1CTL / trxcon

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Tue Jun 4 16:31:40 UTC 2019

Hi Vadim,

On Fri, May 31, 2019 at 09:55:22PM +0700, Vadim Yanitskiy wrote:
> > Looking at layer23, it seems we have DM_REL_REQ, then RESET,
> > then a new DM_EST_REQ during assignment.
> Right. I am now wondering, wouldn't this intermediate
> L1CTL_RESET_REQ cause an additional delay for handover?

I would assume the reset of the data structures is quite fast compared
to anything on the GSM radio interface?  Not sure if it would matter?

> >> So there is no warranty that the new dedicated channel would contain
> >> RACH slots, right? That's another limitation of trxcon: it can send
> >> RACH bursts on RACH slots only, and only on TS0.
> Fortunately, I found a work around, please see:
> https://gerrit.osmocom.org/#/c/osmocom-bb/+/14274/

Thanks, this has meanwhile ben merged.

> I've just confirmed that trxcon properly sends Access Bursts
> on any (activated by L1CTL_DM_EST_REQ) time-slot, please see:
> https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14291/

Which has also been merged, and is executing + passing for seveal
consecutive days, see 


> In short, it doesn't detect handover RACH.
> The problem seems to be here:
> https://git.osmocom.org/osmo-bts/tree/src/common/scheduler.c#n986
> An Access Burst is merely ignored if a logical channel is not active.

The logical channel must be previously activated by the BSC using RSL
CHAn ACT with type == handover.


- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the baseband-devel mailing list