Hi Oliver, great! 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. 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#… 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.