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 channel
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?
Regards, Harald
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.
Hi 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
Hi Vadim and others,
given how long L1CTL has been around, and how many programs implement it by now, I really would like to ensure backwards compatibility without introducing weird breakage all over the place.
The good news: I think it's possible to extend L1CTL in a backwards-compatible way, and I started with a related implementation.
Some of my raw notes below:
--- Extension of L1CTL in a compatible way
* enhance l1ctl_reset with version and feature bitmap ** used by L1CTL_RESET_CONF, possibly also REQ, IND ** old implementation ignores trailer ** new implementation recognizes new format due to longer message (and enables use of new features)
* new DM_EST_2_REQ ** sent by L23 only if feature-bit was set in RSEET_CONF ** contains additional fields *** L1 SAPI bitmask *** sync_source member to select own cell or neighbor cell sync info * new DM_EST_2_CONF ** response to _REQ (which is currently missing from DM_EST_REQ)
* extend l1ctl_neigh_pm_ind with new fields at end ** L23 can use size to determine if new fields exist or not
* new DM_MODIFY_REQ ** sent by L23 to change L1 SAPI bitmask * new DM_MODIFY_CONF to confirm it
/* bit definitions for individual features communicated in RESET_CONF */ enum l1ctl_feature { L1CTL_FT_DM_EST2_MODIFY, /* DM_EST_2 and DM_MODIFY procedures */ L1CTL_FT_RACH_DM, /* RACH can be sent in dedicated mode */ L1CTL_FT_EXT_RACH_REQ, /* Extended RACH (11bit) support */ L1CTL_FT_SPKR_MIC, /* Hardware Speaker + Microphone supported */ L1CTL_FT_TRAFFIC_IND, L1CTL_FT_BURST_IND, L1CTL_FT_TBF, /* support for TBF_CFG and DATA_TBF procedures */ L1CTL_FT_SIM_SLOT, /* physical SIM slot exists */ L1CTL_FT_SIM_SLOT, /* physical SIM slot exists */ L1CTL_FT_BAND_850, L1CTL_FT_BAND_900, L1CTL_FT_BAND_1800, L1CTL_FT_BAND_1900, L1CTL_FT_CIPH_A51, L1CTL_FT_CIPH_A52, L1CTL_FT_CIPH_A53, }; ---
I won't go "full steam ahead" on this, but will try to get it implemented within the next week or so.
Regards, Harald
Hi Harald,
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?
Oh, right! L1CTL_DM_REL_REQ magically slipped my mind. Of course, this one is used to release dedicated mode, and trxcon does support it already. Sorry for confusion.
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? [...]
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.
Nevermind. This is a result of my delusion. See above.
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?
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/
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/
... and of course discovered a problem of OsmoBTS ;) 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.
King regards, Vadim Yanitskiy.
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:
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 https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_resul...
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
baseband-devel@lists.osmocom.org
-
Harald Welte -
Vadim Yanitskiy