Hi Vadim,
On Fri, May 31, 2019 at 09:55:22PM +0700, Vadim Yanitskiy wrote:
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?
I would assume the reset of the data structures is quite fast compared to anything on the GSM radio interface? Not sure if it would matter?
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:
Thanks, this has meanwhile ben merged.
I've just confirmed that trxcon properly sends Access Bursts on any (activated by L1CTL_DM_EST_REQ) time-slot, please see:
Which has also been merged, and is executing + passing for seveal consecutive days, see https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_resul...
Thanks!
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.
The logical channel must be previously activated by the BSC using RSL CHAn ACT with type == handover.
Regards, Harald