hand-over in L1CTL / trxcon

Vadim Yanitskiy axilirator at gmail.com
Sat May 25 23:50:21 UTC 2019


Hi Harald,

sorry for late response, I took me some time to recover after PHDays.

> 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.

Great! I will be happy to cooperate you on the MS side.

> To break this down to low-level requirements
> in terms of MS capabilities:
> * switch to a different ARFCN
> * switch to a speciifed timeslot

As far as I understand (sorry, my HO knowledge is very limited),
this should be possible while being on a dedicated channel. In
general, it is already possible with the current code: that's
exactly how ASSIGNMENT COMMAND works AFAIR.

To do that, the controlling side need to send a L1CTL_RESET_REQ,
followed by L1CTL_FBSB_REQ, and then finally L1CTL_DM_EST_REQ.
Otherwise the old dedicated connection would remain active...

The main problem of this approach is that the new ARFCN the MS
is requested to switch needs to be C0 (i.e. transmit both FCCH
and BCCH). Otherwise L1CTL_FBSB_REQ would fail.

That's a poor man's (I would even say ugly) approach, and as it
turns out, there is L1CTL_DM_FREQ_REQ, which allows to schedule
frequency change at the given TDMA frame number! But not the
timeslot change :/

At the moment, trxcon does not support L1CTL_DM_FREQ_REQ. But I
think this is the way to go. (Ab)using L1CTL_DM_EST_REQ in order
to change ARFCN and/or TDMA TN looks like a bad idea to me. It
should be used for a single purpose - go from IDLE to DEDICATED.

> * change the synchroniztaion (in terms of where we currently are
> in the TDMA multiplex) to a given neighbor cell. [...]
> [none of this is relevant for a fake_trx + trxcon setup]

Why not relevant? I believe with the recently refactored FakeTRX
we can connect as much BTS and/or TRX instances as we need, and
I think we can even play with the clock distribution, so two or
more BTS instances would use independent clock sources ;)

For changing TDMA parameters, we can think about introducing a new
message, e.g. L1CTL_DM_TDMA_REQ, that by analogy with the mentioned
L1CTL_DM_FREQ_REQ would allow to schedule TDMA parameters change
at the given TDMA frame number.

> * ability to enable only the receiver for the main channel
> (SDCCH/FACCH), but suppress any reception (or passing up
> of received) SACCH.

So this is only needed for handover, right? If yes, we can extend
the 'l1ctl_info_ul' (which is included in L1CTL_DM_FREQ_REQ) with
such information. Fortunately, there are two padding bytes in it.

> * ability to transmit RACH burst[s] in uplink on that
> new dedicated channel

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.

The second limitation can be easily fixed by indicating a proper
timeslot in the 'l1ctl_info_ul' header of L1CTL_RACH_REQ. Currently
the higher layers leave this header empty, so we always assume
'chan_nr' == 0x88, which corresponds to RACH on TS0.

The first limitation comes from the architecture of trxcon. Unlike
the firmware for Calypso targets, trxcon's scheduler is 'layout-based',
i.e. we have the TDMA multiframe layouts and mapping the current TDMA
frame number to them gives us an idea what to do.

The firmware's scheduler, which runs on top of the DSP's internal
scheduler, is following the 'task-based' approach, i.e. we have
different sets of active and inactive tasks with TDMA frame
numbers indicating when exactly we should execute them.

The 'layout-based' approach does not allow us to schedule any tasks,
such as frequency redefinition, TDMA parameters change, or Access
Burst transmission, on a given frame number. Therefore, we either
need to completely switch (i.e. rewrite) trxcon to the 'task-based'
architecture, or extent the existing scheduler with the ability to
schedule some tasks, so we would have a mixed architecture.

> * ability to later on enable full Rx/Tx of all logical channels
> on that dedicated channel

It looks like we need a new L1CTL message for (de)activating TDMA
timeslots on the current channel, and (de)activate particular
logical channels on them. That would be also useful for other
tests, e.g. multi-TS transmission in (E)GPRS.

> 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

I had a quick look so far, and in general it looks good to me.
We just need to conclude on the L1CTL changes (see above).

> 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 [...]

A very early / draft implementation can be found
in a separate branch 'fixeria/l1ctl_nego':

https://git.osmocom.org/osmocom-bb/log/?h=fixeria/l1ctl_nego

this branch actually depends on:

https://gerrit.osmocom.org/#/c/libosmocore/+/10034/

I wish I had more time to finish it...

> 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 an
> established channel before.  Is that correct?

I just checked the code, and I think it would not fail, but
result into having the old channel left active. As I already
mentioned above, I don't like the idea of abusing this message
for handover.

> 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?

Let's resume everything, so that would be the answer:

 - We should not abuse L1CTL_DM_FREQ_REQ for handover, it should
   be used for a single purpose: switch from IDLE to DEDICATED.

 - Let's instead use both L1CTL_DM_FREQ_REQ and L1CTL_DM_TDMA_REQ
   (to be introduced) for handover remated manipulations.

 - Alternatively, we can introduce L1CTL_DM_HANDOVER_REQ that
   would contain both FDMA and TDMA parameters.

 - Let's introduce a new L1CTL message for (de)activating TDMA
   timeslots on the current channel, and (de)activating its
   logical channels.

 - We need to implement the ability to schedule tasks at the given
   TDMA frame number in trxcon, so it would be possible to change
   the FDMA and TDMA parameters, and send Access Bursts
   on non-RACH slots.

 - Let's try to hack the clock distribution in FakeTRX, so that
   would allow us to test handover between non-synchronized
   virtual Base Stations.

Please note that I don't insist on any of these points, this is just
my understanding of the way how the handover integration should be
done. I am open for discussion ;)

With best regards,
Vadim Yanitskiy.


More information about the baseband-devel mailing list