OpenBTS / OpenBSC interaction

historical

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

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.