OpenBTS / OpenBSC interaction

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

David Burgess dburgess at kestrelsp.com
Wed Oct 7 16:54:53 UTC 2009


Harald, Alexander, Sylvain, others -

I should probably speak up here at some point.

On Oct 7, 2009, at 8:35 AM, Harald Welte wrote:

> 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 :)

That doesn't count.

>>
>> 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.

True.  If you could just share registration information, you could  
have mobility among the cells, but OpenBTS does not yet support  
handovers of active calls.

We can send SMS, though, if you support RFC-3428.  (We even tested  
that interface with Voxbone's messaging gateway.)

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

Yes, and that would not be too hard if we could share an HLR function.

>
>> 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.

 From a testing standpoint, I can see value in putting an Abis  
interface on OpenBTS, but it's not a high priority for us, either.

>
>> 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.

Same here.  You don't really understand it until you actually do it.

>
>> 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.

Yes.  We can learn a lot from each other and face a lot of similar  
technical problems, but our goals and implementation styles are very  
different.

However, our design approach *is* to keep everything above L3 in  
outside applications.  Our L3 is just a collection of gateway  
functions between the ISDN world and the IETF world.  Everything else  
is done with outside applications over IP interfaces.  Our SIP-based  
SMSC replacement is a separate application.  Our SIP-based PBX is a  
separate application.  Our HLR replacement is also an outside  
application, although for now it is just Asterisk's SIP registry.

Something I think could be useful, and would allow a lot of  
interoperability, would be to have a common HLR/VLR replacement.  The  
Asterisk SIP registry doesn't meet our long-term requirements and so  
we need to develop one anyway.  If we can agree on an interface and  
an implementation, we could do something here.

>
> 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.

That kind of API should be easy.  OpenBTS follows a data-flow  
design.  At the top of L2, every channel is just a pair of FIFOs (up/ 
down) of L3 message objects.  It should be easy to funnel all of that  
through some kind of Abis adapter.

>
> 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.

No objection, but there will be questions about licensing.  To date,  
there are very few outside contributions in the OpenBTS distribution,  
maybe a few dozen lines out of ~12k.  The FSF copyright assignment  
gives us the flexibility to distribute a non-GPL release if we want.   
Given GPLv3's treatment of patent licenses, that will be very  
desirable for some users, even if the actual code is identical to  
what we release under GPL.  It also give us the opportunity to charge  
licensing fees and royalties for use of OpenBTS in commercial  
products, a plan for which we make no apology.  ("Free as in freedom,  
not free beer.")  We have no problem with sharing royalties with  
contributors, but our business plan requires that we preserve  
licensing flexibility, and so we would need to have formal agreements  
with any significant contributors if we were to actually use their  
contributions.  Admittedly, this creates a tension in the open source  
project, a tension that we are still learning to manage, especially  
since the lifting of the injunction has removed the biggest barrier  
to participation.

I would very much look forward to discussing this face to face.   
Maybe we'll get a chance next month.

>
>> 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.

See above.  The FSF granted us back a blanket license.  We can do  
anything we want *except* stop the FSF from distributing it under  
GPL.  The text of the agreement says we can use the code "in any why  
[we] see fit".  Period.

Also, since OpenBTS puts different functions in different  
applications, we can license those components differently, so the  
final application suite may be used commercially under a mix of GPL  
and non-GPL licenses.

>
> -- 
> - 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)


David A. Burgess
Kestrel Signal Processing, Inc.








More information about the OpenBSC mailing list