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_results_analyzer/ 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 <lafo...@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
