Hi Harald and Sebastian,

Some of you will have alrady noticed, over the last few days I reviewed, cleaned up, submitted and merged the virtual Um interface support on both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).

First, my congratulations to Sebastian, great work! I also would like to add my two cents to this topic. As we already discussed with Harald, the virtual Um-interface could be helpful for testing, so I have some ideas regarding to this application.

Regarding to the previous topic, where the problem of multiple BTS and multiple MS was discussed. I am not going to say, than my implementation of virtual Um-interface is better or worse. Moreover, one was created for my personal requirements just for testing of some code parts I am currently working on. Instead of that, I would like to do some relative analysis of both implementations:

- At the moment, my implementation do support only a single MS <-> BTS connection. But, I have been writing all the code as modular as possible, so handling multiple L1CTL connections at the same socket (/tmp/osmocom_l2) could be added by a few lines of code. Currently the L1CTL link handler discard any incoming connections if there is already established one. This behaviour could be changed to accept more than one connection, allocating dedicated set of structures (trx interface, scheduler stuff, etc.) for each.

- Regarding to the current state of work, I have xCCH RX / TX working, so L23 applications are capable to establish a dedicated channel and perform regular operations like: LUR, USSD, SMS, etc. Right now I am woring on TCH, relaying at OsmoBTS source code. As I know, mobile app can be connected to Linux Call Router, so this could be used for TCH testing (high load if required).

- As I use OsmoTRX style transceiver interface for OsmocomBB, no changes are required on OsmoBTS side. All bursts are being forwarded from BTS to MS and vice versa through a simple Python application. From the other side, this limits us to use osmo-bts-trx with its compatibility issues. If you think, why Python? I've choosed this language because of implementation speed - first working code was ready after a hour of work. CPU load is about 2%, the most hungry is a clock generator. Anyway, it can be easily reimplemented in C for better performance.

So, if you guys think that this implementation could be useful for high load / regression testing too, just let me know, and I'll do required changes in the source code.

With best regards, Vadim Yanitskiy.