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/.

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:

https://gerrit.osmocom.org/#/c/osmocom-bb/+/14274/

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/

... and of course discovered a problem of OsmoBTS ;)
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.

King regards,
Vadim Yanitskiy.



More information about the baseband-devel mailing list