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