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/.
Vadim Yanitskiy axilirator at gmail.comHi 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.