hand-over in L1CTL / trxcon
axilirator at gmail.com
Fri May 31 14:55:22 UTC 2019
> 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.
More information about the baseband-devel