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.