GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS

Vadim Yanitskiy axilirator at
Sun Jul 16 15:51:59 UTC 2017

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the baseband-devel mailing list