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:
https://gerrit.osmocom.org/#/c/osmocom-bb/+/14274/
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:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14291/
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_resu…
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
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)