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/OpenBSC@lists.osmocom.org/.
Vadim Yanitskiy axilirator at gmail.comHi Oliver,
> I'm working on the TTCN3 tests for OsmoPCU.
great!
> He also said that since there is trxcon/fake_trx nowadays,
> it would be better to use that instead, if it supports PDCH.
Well, I wouldn't say better. It depends what do you need to test.
With the virt_phy, you can test the higher layers of OsmoBTS, so
you are not affected by potential problems / bugs of particular
L1 implementation, such as osmo-bts-trx.
With fake_trx.py and trxcon you can test the whole stack, including
the L1 implementation (scheduling, convolutional coding, etc.). As
a bonus, you can simulate different parameters of the virtual radio
interface, including RSSI, ToA256, C/I, and even BER.
> From a quick "git grep", it looks like PDCH is supported in trxcon.
Yep, it does. You can find the multiframe layout of PDCH:
https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_mframe.c#n1811
which contains two logical channels:
PDTCH - Packet Data Traffic Channel, and
PTCCH - Packet Timing advance Control Channel.
Neither in OsmoBTS nor in trxcon PTCCH is handled correctly:
https://osmocom.org/issues/4102
but PDTCH is implemented, please see:
https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_lchan_desc.c#n501
https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_lchan_pdtch.c
Currently there is only one TTCN-3 test case that uses PDTCH
support in trxcon - f_TC_pcu_data_ind_lqual_cb:
https://git.osmocom.org/osmo-ttcn3-hacks/tree/bts/BTS_Tests.ttcn#n4320
The main problem is that trxcon has a bit different philosophy
when it comes to packet data and PDCH in particular. Its early
development was mostly influenced by OsmoBTS, and at that time
I knew almost nothing about GPRS and its PHY.
One big difference from virt_phy is that trxcon uses different
L1CTL messages: L1CTL_TRAFFIC_{REQ,CONF,IND} instead of
L1CTL_DATA_{REQ,CONF,IND}. I don't insist on this, but IMHO
this kind of message is better for PDTCH.
Another important detail is that there is no such thing as TBF flow
in trxcon. Everything that was received on PDTCH will be forwarded
to the higher layers, so they need to do TBF filtering themselves.
Ideally, we need to be able to configure one or more TBFs (using TFI),
so trxcon would filter received packets. In virt_phy this can be done
using L1CTL_TBF_CFG_{REQ,CONF}. At the same time, I would like to
keep the possibility to receive everything for sniffing ;)
Finally, there is no way to ask trxcon to send a given Uplink
block on particular TDMA frame number. Instead, a queued block
will be sent almost immediately.
Resuming the above, we need to solve at least three problems:
1) L1CTL_TRAFFIC_{REQ,CONF,IND} vs L1CTL_DATA_{REQ,CONF,IND};
2) Downlink TBF flow control: L1CTL_TBF_CFG_{REQ,CONF};
3) Uplink TBF flow control: L1CTL_DATA_TBF_{REQ,CONF}.
While writing this mail, I've got an idea about a potential solution
of the 1st one. We can just keep L1CTL_TRAFFIC_{REQ,CONF,IND} for
the 'flowless' control (i.e. Rx/Tx everything regardless of TBFs),
and implement L1CTL_DATA_{REQ,CONF,IND} handling for selective
reception and transmission. Switching between the both modes
can be done one reception of L1CTL_TBF_CFG_REQ.
I am open for the further discussion. Added Harald to CC.
With best regards,
Vadim Yanitskiy.