Hi all,
I will answer to David's e-mail, because I'm mostly agree with him
on tech questions.
On Wed, Oct 7, 2009 at 20:54, David Burgess <dburgess(a)kestrelsp.com> wrote:
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(a)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.
Right, that's not what I meant by "flat". A-bis over IP is a tunneling
rather then real
network.
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.)
That was what I had in mind too.
1) We should share the same HLR and then it won't be two separate networks
with "roaming". And this makes sense, and is the first target to work on.
2) For SMS we can interoperate if we had a gateway between SIP/SIMPLE
and OpenBSC's SMSC (not sure what does OpenBSC use for SMSC?
Do you plan to support SMPP or such?).
That'll be nice, but that's obviously not the top priority.
Could we work on HLR interoperability and try to test it at 26C3?
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.
I second this. See above.
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.
I strongly believe and has spoken several times, that something there
must be changed - current situation is simply discouraging both users and
potential developers.
My points are:
1) Main svn must be open and all non-funded development should be done
there, so everyone will be able to get latest bugfixes and not wait months
while David and Harvind have no time and desire to publish them.
2) Funded development may go in a private branch (Mercurial or git helps
here a lot) and will be published when needed. Having that OpenBTS
architecture will be more and more stable as time passes, changed will
be pretty non-intrusive.
re: sharing royalties with contributors
That's great, but how do you plan to measure how much each contributor
should gain? Should one, contributed 120 lines receive 120/12K part of
royalties?
But what if these 12 lines where a critical fix or an important feature?
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.
That's an interesting way. But won't this GPL parts have the same problems
with the patents as main OpenBTS core?
--
Regards,
Alexander Chemeris.