OpenBSC development

[Peter Stuge]

Labs wrote:
>> We had some tangential discussions at 28c3 in Berlin between X-mas
>> and NYE, where we last ran an OpenBSC test network.
>
> So there are more people thinking like me?

I started an early discussion because I was thinking of how we could
make it even easier to run an OpenBSC CCC event network, which has
been done on a handful of times by now but mostly with some amount of
manual labour also on the software side, and without producing
documentation.

My idea so far is to start with a so-called spec file for the Gentoo
catalyst tool, which can be used to very conveniently build a
ready-to-run system. That work would be reusable for a VM image.


>> * The OpenBSC software may be integrated in many different ways
>>
>> OpenBSC does not neccessarily run only on Linux operating systems
>> (maybe this is actually a requirement now, but I don't think it needs
>> to be, and generally it is good to have software be portable across
>> many different operating systems) - this is significant because any
>> interface configuration is always highly system specific, and every
>> integration will have different processes here. Following the UNIX
>> principle, this is outside the scope of OpenBSC. Ie. interface
>> configuration is one step considered belonging to the base system,
>> while software configuration to use those interfaces is a separate
>> step which needs to match the system base configuration.
>
> I am thinking that you always need to separate the traffic based on 
> destination. That being said you will not use the same interface for 
> management of the box and also for Abis or A interfaces.

You can.


> All of them should be separately defined.

Not neccessarily.


> Management interface can be defined via normal OS way (or an OpenBSC 
> GUI/startup menu?)

This part falls very clearly outside the scope of the OpenBSC
software. It could however be part of another, "higher level"
software project, something like a Linux distribution tailed
to OpenBSC.


> but the rest of interfaces should be defined via OpenBSC 
> config. I don't know how it works now, is there any "limitation"
> or you can have everything on one ethernet interface?

OpenBSC does nothing at all with interfaces, and does not care where
or how communication goes as long as it has IP connectivity with the
units it needs to communicate with. Management and BTSes can be on
the same network if so desired.


> design should be done in advance

I am sure that you appreciate that OpenBSC was not put together
without design. Please be careful with wording.


> so there will not be a complete re-write of the code in case of
> small/big? changes.

If you're not a programmer it seems you're now venturing into a field
you may not be experienced in. The developers in OpenBSC are, on the
other hand, quite experienced. Don't worry about the code quality.

Re-write is not neccessary to avoid at all cost, especially not at
very high design cost. In fact, one solution in the short term is
perfectly fine even if a different solution has already been foreseen
to be neccessary in the medium term.


>> If it happens I would argue that OpenBSC should configure only those
>> interfaces which are related to GSM, and that they be kept separate
>> from the "regular" interfaces used by the system.
>
> Correct, agree.

It's important to remember that OpenBSC supporting such configuration
MUST NOT mean that operations and management are suddenly required to
be on different interfaces. But this is easy; OpenBSC will just not
do any configuration at all unless told to do it.


>> Such a change will tie OpenBSC more strongly to the particular
>> operating systems it runs on, which is generally considered a bad
>> thing.
>
> It is considered bad but you cannot just keep on testing different 
> behaviors on all Linux flavors.

Oh it's not about Linux distributions. Linux is a single operating
system. Distributions are not relevant. I'm talking about various
variants of BSD, Windows and Solaris.


> I think most, probably 99%, are running the project on Debian.

Again, this does not, and MUST NOT, matter. OpenBSC is not and will
quite likely never be debian specific.


> I guess I put it in the wrong way in my first email. I work with CLI 
> everyday but for some things I like the GUI. I am probably used with 
> the commercial BSC CLI/GUI so...

Of course all constructive ideas for the user interface are
interesting. Since the CLI is what is currently there it can be
compared with other BSC CLI, and if OpenBSC can be made even better
than it is then of course the good ideas should not get lost.


> I prefer to have a GUI for checking fast some transmission line parameters 
> (type/line code/BER results/IP address of BTS), check and reset different 
> BTS boards that go crazy sometime...
>
> I am not sure what you can do now in regard to BTS components/modules

The "show bts 1" command is probably a good start. Of course, if you
think it should be extended with further important information then
let's hear about it.


> and if the OML commands sent to BTS can do the above things.

That depends on the BTS, right?


//Peter