hand-over in L1CTL / trxcon
laforge at gnumonks.org
Tue Jun 4 16:31:40 UTC 2019
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
> 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.
The logical channel must be previously activated by the BSC using RSL
CHAn ACT with type == handover.
- 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)
More information about the baseband-devel