OpenBTS / OpenBSC interaction

historical

Hi David,

On Wed, Oct 07, 2009 at 09:54:53AM -0700, David Burgess wrote:
> >>There is A-bis over IP of course :)
> 
> That doesn't count.

well, that would be what I'd implement if I was to write a BTS-side
Abis implementation that would like to OpenBTS' transceiver + LAPDm code.

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

of course, I never assumed it was any of your priorities at all..

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

Well, we at OpenBSC are very interested in the actual GSM layer 3 protocols
on the various interfaces (Abis, A, B and others).

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

I think I would actually want to have a protocol-compatible HLR, i.e. using the
standard interfaces that GSM/3GPP use for the HLR - which I doubt is something
that you would want to see :)

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

Yes, I've looked at the code before and thought it should be relatively easy.

I see one other advantage for this: More and more OpenBTS bits that are
currently static (like channel configuration or similar) would have to become
configurable in order to support GSM 12.21 (A-bis OML).  Initially, having
all of this static is fine, of course.

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

sure.  That shouldn't be much of a problem either.  If we introduce the API
that I've proposed above, then the part 'below' the API stays like it is, with
copyright assingments to the FSF, etc.  However, the BTS side A-bis code on top
would be GPL (v2+) licensed and copyright is with whoever does the
implementation.  That part would not neccesarrily be a part that is required to
be part of the OpenBTS standard distribution.

If some alternative licensing is required by one of your customers down the
road, arrangements would have to be made with the copyright holder of that
A-bis BTS part.

> ("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 don't think it will be a big deal, don't worry too much about it :)

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

ok, that's interesting and good to know.

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