hand-over in L1CTL / trxcon

Harald Welte laforge at gnumonks.org
Thu May 23 11:15:12 UTC 2019

Hi Vadim,

I'm currently facing the problem of testing hand-over related channel-activation
in OsmoBTS.  Three are various rules about how this has to be done, and a closer
look indicates that both osmo-bts-trx as well as osmo-bts-sysmo don't get that
right at all.

I'd like to write TTCN-3 tests as part of BTS_Tests.ttcn, which uses L1CTL
to control a (virtual or real) L1 for the MS side of testing the BTS.

To break this down to low-level requirements in terms of MS capabilities:

* switch to a different ARFCN
* switch to a speciifed timeslot
* change the synchroniztaion (in terms of where we currently are in the TDMA
  multiplex) to a given neighbor cell.  The MS will have performed neighbor
  measurements before, and as part of that will hav received FCCH + SCH and
  hence know the timing both in terms of carrier freq as well as TDMA position
  [none of this is relevant for a fake_trx + trxcon setup]
* ability to enable only the receiver for the main channel (SDCCH/FACCH), but
  suppress any reception (or passing up of received) SACCH.
* ability to transmit RACH burst[s] in uplink on that new dedicated channel
* ability to later on enable full Rx/Tx of all logical channels on that dedicated

I've looked at the jolly/handover branch from 2013, and rebased that on top of current
master, the result can be seen in laforge/jolly_handover_rebase

Change-Id Iadbc47f006d1f8a019822aedee180814de13cb2d specifically adds new flags
to DM_EST_REQ to
* disable uplink transmission
* use the sync information of a neighbor cell

I would like to get at least that change to L1CTL merged to master, and while
doing that, update all implementations of L1CTL at the same time.  It may make
sense to also merge Change-Id I792b52d9bf115a2def9720eed3d62982d8cdbe00 while
at it, which is required for neighbor channel measurements + reporting.
We should also use that opportunity to introduce some kind of versioning support
to L1CTL, to ensure future extensions of the protocol can be made in a way where
incompatibility can at least be detected at runtime.

Now the next question is how to this will impact trxcon/fake_trx.  AFAICT,
there is a comment in trxcon hinting that the TRX TUNE comamnd of a DM_EST_REQ
would fail if there was already and established channel before.  Is that correct?
If so, what is the suggested/recommended way to get trxcon to support at least
the minimum of what's required for handover in a virtual environment?

- 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 mailing list