OpenBTS / OpenBSC interaction

historical

Hi Sylvain and others,

On Wed, Oct 07, 2009 at 02:09:14PM +0000, 246tnt at gmail.com wrote:
> >We see this from different points of view. :) We're interested to
> >show possible
> >ways of OpenBTS interoperability with more conventional BTSes like ones
> >OpenBSC use and evaluate problems which will arise there. But we want to
> >show this with "flat IP" network instead of burdening OpenBTS with
> >A-bis interface.
> 
> There is A-bis over IP of course :)
> 
> Because just connecting them with asterisk just proves asterisk
> works, you still have two independent GSM network.

I agree.  Showing that you can make a call from OpenBTS through asterisk
through asterisk (through lcr) through openbsc to a nanobts doesn't really say
anything about a GSM level of interaction.  you're simply testing whether one
asterisk can talk voip to the other asterisk.

There is no GSM protocol level interaction between those two networks, so you
would have no way for handover, or things like sending sms from one network to
the other.

> A better integration would allow roaming between an
> openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool.

Indeed!

> Now that can be done either by OpenBTS having a Abis-over-IP IF
> (much like the nanoBTS), or by implementing inter-msc roaming in
> both (I think, didn't check deeper).

yes, both ways should work.  To me, Abis-over-IP would make a lot of sense. Why
not reuse the existing transceiver code and the code that we already have for
the BSC side of A-bis (like TLV parser, lots of utility functions, etc.) to
turn the USRP into a true BTS.

Having a BTS side A-bis implementation would also help us with my other dream:
A virtual/simulated BTS.  This BTS would not talk to an actual RF layer, but
it would simply use something like mac-blocks or gsm bursts with GSMTAP header
over multicase UDP/IP.  It would allow us to further work on a MS side layer 2+3
stack, without even having to touch the actual radio interface.

That, in turn, would allow us to do 90% of a GSM phone without having a full
RF / layer 1 implementation.  Also, it would allow us to do regression and load
testing of OpenBSC without any real phone or even real BTS.

So far my "if I only had the time" plan.

> I must admit I don't personally think it's ideal to have the
> BSC/MSC/HLR... layers duplicated in both OpenBTS/OpenBSC. It's
> pretty common in opensource to have several project 'doing the same
> thing' and it usually helps innovation and such but in this case
> there aren't thousands of developers with good GSM knowledge ...

yes, but I would never have the knowledge (and neither would e.g. Holger have
his), if we didn't actually do the implementation.

> OTOH, OpenBTS and OpenBSC have made some choice that don't make a
> seamless reuse of code trivial (C vs C++, single vs multi thread).

Also, the intended purpose is quite different. OpenBSC is about playing with
higher level GSM protocols, research and analysis.  To some people it also
serves as a cheap minimal BSC to work with proprietary BTS, which is fine.

OpenBTS is about creating an as thin as possible gateway between the Um
interface and SIP.  They don't want to run a BTS program, a BSC program, a MSC
program, a SIP proxy program, a SMSC program and then configure each of those
programs individually.

Which is why I think a modular approach makes sense.  We're already splitting
BSC and MSC functionality inside the OpenBSC project.  If somebody finds the
time to introduce some kind of API between layer 2 and layer 3 of OpenBTS,
then that would be the ideal case.  People who want to use OpenBTS standalone
can continue to do so, while people who want to put a BTS-Side A-bis on top
(and use with proprietary BSC or OpenBSC) can also do that.

I haven't spoken about this with David so far, since I didn't have the time to
actually do the implementation.  But I believe as long as the changes are not
intrusive and OpenBTS doesn't loose features / stability or performance, I
wouldn't expect much objection to it.

> The licenses are compatible that's a start :) (v2 or later vs v3)

You may be missing the fact that (I believe) Kestrel might be interested in
doing dual licensing on OpenBTS.  However, thinking more about this, it seems
unlikely since the copyright is now with the FSF.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)