hand-over in L1CTL / trxcon

Vadim Yanitskiy axilirator at gmail.com
Fri May 31 14:55:22 UTC 2019

Hi Harald,

> Sounds like we need a DM_REL_REQ - and we actually have one. I would
> normally expect that to be used to release dedicated mode?

Oh, right! L1CTL_DM_REL_REQ magically slipped my mind. Of course,
this one is used to release dedicated mode, and trxcon does
support it already. Sorry for confusion.

>> The main problem of this approach is that the new ARFCN the MS
>> is requested to switch needs to be C0 (i.e. transmit both FCCH
>> and BCCH). Otherwise L1CTL_FBSB_REQ would fail.
> You are referring to trxcon or calypso-layer1 here? [...]
>> That's a poor man's (I would even say ugly) approach, and as it
>> turns out, there is L1CTL_DM_FREQ_REQ, which allows to schedule
>> frequency change at the given TDMA frame number! But not the
>> timeslot change :/
> I actually think it's not ugly at all.  You release the old
> dedicated channel and establish a new one.

Nevermind. This is a result of my delusion. See above.

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

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


I've just confirmed that trxcon properly sends Access Bursts
on any (activated by L1CTL_DM_EST_REQ) time-slot, please see:


... and of course discovered a problem of OsmoBTS ;)
In short, it doesn't detect handover RACH.

The problem seems to be here:


An Access Burst is merely ignored if a logical channel is not active.

King regards,
Vadim Yanitskiy.

More information about the baseband-devel mailing list