31 May
2019
31 May
'19
4:55 p.m.
Hi Harald,
Nevermind. This is a result of my delusion. See above.
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. 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.