<div dir="ltr">Hi Harald and Sebastian,<br><br>> Some of you will have alrady noticed, over the last few days I reviewed,<br>> cleaned up, submitted and merged the virtual Um interface support on<br>> both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).<br><br>First, my congratulations to Sebastian, great work! I also would like to<br>add my two cents to this topic. As we already discussed with Harald, the<br>virtual Um-interface could be helpful for testing, so I have some ideas<br>regarding to this application.<br><br>Regarding to the previous topic, where the problem of multiple BTS and<br>multiple MS was discussed. I am not going to say, than my implementation<br>of virtual Um-interface is better or worse. Moreover, one was created<br>for my personal requirements just for testing of some code parts I am<br>currently working on. Instead of that, I would like to do some relative<br>analysis of both implementations:<br><br>  - At the moment, my implementation do support only a single MS <-> BTS<br>    connection. But, I have been writing all the code as modular as<br>    possible, so handling multiple L1CTL connections at the same socket<br>    (/tmp/osmocom_l2) could be added by a few lines of code. Currently<br>    the L1CTL link handler discard any incoming connections if there is<br>    already established one. This behaviour could be changed to accept<br>    more than one connection, allocating dedicated set of structures<br>    (trx interface, scheduler stuff, etc.) for each.<br><br>  - Regarding to the current state of work, I have xCCH RX / TX working,<br>    so L23 applications are capable to establish a dedicated channel and<br>    perform regular operations like: LUR, USSD, SMS, etc. Right now I am<br>    woring on TCH, relaying at OsmoBTS source code. As I know, mobile app<br>    can be connected to Linux Call Router, so this could be used for TCH<br>    testing (high load if required).<br><br>  - As I use OsmoTRX style transceiver interface for OsmocomBB, no changes<br>    are required on OsmoBTS side. All bursts are being forwarded from BTS<br>    to MS and vice versa through a simple Python application. From the<br>    other side, this limits us to use osmo-bts-trx with its compatibility<br>    issues. If you think, why Python? I've choosed this language because<br>    of implementation speed - first working code was ready after a hour<br>    of work. CPU load is about 2%, the most hungry is a clock generator.<br>    Anyway, it can be easily reimplemented in C for better performance.<br><br>So, if you guys think that this implementation could be useful for high<br>load / regression testing too, just let me know, and I'll do required<br>changes in the source code.<br><br>With best regards,<br>Vadim Yanitskiy.<br><br></div>