hand-over in L1CTL / trxcon

[Harald Welte]

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