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.