This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Vadim,
On Sun, May 26, 2019 at 06:50:21AM +0700, Vadim Yanitskiy wrote:
> Great! I will be happy to cooperate you on the MS side.
thanks!
> > 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.
correct. However, for BTS_Tests.ttcn it doesn't really matter, as
we are testing the individual low-level transactions and we can
simply
* RSL CHAN ACT (type == handover)
* ask the MS to enter dedicated mode directly on that timeslot
without any actual hand-over and no previous channel present. But
that of course is insufficient for using it on real networks.
> In general, it is already possible with the current code: that's
> exactly how ASSIGNMENT COMMAND works AFAIR.
good.
> 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...
Sounds like we need a DM_REL_REQ - and we actually have one. I would
normally expect that to be used to release dedicated mode?
Looking at layer23, it seems we have DM_REL_REQ, then RESET, then
a new DM_EST_REQ during assignment.
> 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.
You are referring to trxcon or calypso-layer1 here?
I'm asking as it is a perfectly natural occurring event to have an
ASSIGNMENT on the same BTS but to a dedicated channel on a different
ARFCN - and I would be surprised if caylypso-l1 of osmocom-bb wouldn't
support that.
> 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 :/
I actually think it's not ugly at all. You release the old dedicated
channel and establish a new one.
> At the moment, trxcon does not support L1CTL_DM_FREQ_REQ. But I
> think this is the way to go.
This is for changing the frequency on an exstablished dedicated channel,
because the network descides to change its ARFCNs or hopping sequences
at some point during operation. A very rare event, which I wouldn't
be too worried about if we didn't cover it (but we in fact do in
OsmocomBB!).
> (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.
It's not abusing. We actually do release the old channel and establish
a new one...
> > * 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 ;)
you are right for the frame numbers which of course would be different
between [even virtual] BTSs. However, there's of course no acquisition
of FCCH to track the carrier frequency, which is probably what I was
thinking, but not writing about.
> 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.
I don't like such hacks, sorry.
> > * 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 new dedicated channel is a normal SDCCH or TCH/F or TCH/H and
there are no "rach slots".
> 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.
ACK.
> 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.
I think a complete rewrite might be too much work.
> > * 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 would like to think of it as "Layer 1 SAPIs", which could be activated
and deactivated on the given dedicated channel. We have the same
concept in osmo-bts-{sysmo,lc15,oc2g}, where one can e.g. activate
SDCCH independent of SACCH, and do that independently for UL and DL.
So I would completely decouple the different domains of:
1) changing the 'sync' (clock + TDMA) to a cell
This can either be achieved by
a) the classic FBSB_REQ during cell search / cell selection, or
b) with a some new primitive which allows us to switch to one of the
neighbors (whose clock + TDMA sync has to be established during the
idle slots in dedicated mode). In Jolly's work, this is done
with a special parameter to DM_EST_REQ, but I would make that
a separate primitive.
2) changing the frequency while retaining sync
This is used whenever channels on different ARFCN (or HSN/MAIO)
on the same BTS are assigned to the MS. Changing frequency *without*
also changing the timeslot (like our existing DM_FREQ_REQ) only
happens in case of frequency changes/redefinitions, which I would
consider rather rare and unusual events during normal operation.
But yes, best to leave the DM_FREQ_REQ for this purpose unmodified.
3) establishing dedicated mode (DM_EST_REQ). It currently automatically
activates all L1 SAPSs, but see below for my idea there.
4) returning back to idle mode (DM_REL_REQ). Care has to be taken about the
situation where we fist hand-over to a new cell in dedicated mode,
and then switch back to idle mode *on the new cell with its
clock/tdma*.
4) activating/deactivating L1 SAPIs within that logical channel.
this is where we can e.g. activate SACCH or not - or even activate
RACH or not on a dedicated channel. The bit-masks of initial L1
sapis for UL and DL could be part of L1CTL_DM_EST_REQ. We could then
modify that later using a L1CTL_DM_MOD_REQ (modify request)?
So a typical hand-over scenario would then be
FBSB_REQ - establish sync to first cell
RACH_REQ
DM_EST_REQ - establishing initial channel
<MS performs neighbor mesurements in idle frames>
<MS performs measurement reporting of neighbors in UL SACCH>
<bsc sends handover command>
DM_REL_REQ - release old channel
SYNC_NEIGH_REQ - change clock + tdma sync to a specific neighbor cell
DM_EST_REQ - establish new channel on that neighbor cell;
* ARFCN can be different from C0 of that cell!
* initial L1 SAPI bitmask contains only DL DCCH + FACCH
RACH_REQ
<BTS sends us PHYSICAL INFO in DL>
DM_MOD_REQ - activate UL DCCH + ACCH
> > 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).
ACK.
>
> > 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...
I know the feeling...
> > 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.
I guess you're referring to DM_EST_REQ here? See above.
> - Let's instead use both L1CTL_DM_FREQ_REQ and L1CTL_DM_TDMA_REQ
> (to be introduced) for handover remated manipulations.
I would argue L1CTL_DM_FREQ_REQ is for frequency changes while on
an active dedicated channel on a given BTS.
For hand-over, it's actually almost like we're establishing a completely
new dedicated L1 channel. The higher-layer state (L3+) is retained,
but L1 and L2 are completely new. So I don't think this is just
a frequency + TDMA change.
> - Alternatively, we can introduce L1CTL_DM_HANDOVER_REQ that
> would contain both FDMA and TDMA parameters.
I would think that's too specific. I would say we release the old
channel and establish a new one. And if the new one fails to establish,
we re-establish the old one using the freq + TDMA sync information we've
kept around for the old cell.
> - Let's introduce a new L1CTL message for (de)activating TDMA
> timeslots on the current channel,
I would consider this part of DM_EST_REQ + DM_REL_REQ - for both
the Assignment and the Handover case. The only difference is whether
we stay with freq+TDMA sync on the current cell, or on a new cell.
> and (de)activating its logical channels.
bitmask of L1 SAPI in DM_EST_REQ and new DM_MOD_REQ.
> - 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.
Not sure how much of that we really need beyond ability to send RACH
on normal traffic channels...
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)