Hi Alexander, On Tue, Oct 06, 2009 at 08:36:04PM +0400, Alexander Chemeris wrote: I don't think we have a particular interest in interconnecting those two, as our resources are typically _extremely_ stressed, and we would rather not reconfigure the installation while it is running. It will already be very hard to do what we currently have on the agenda. I don't really see what would be gained from routing voice data over voip between OpenBTS and OpenBSC. What would be an interesting project is to reuse the OpenBTS transceiver code (but not the layer3 protocol stack + sip gateway) and add a BTS-side A-bis implementation, turning OpenBTS into a real BTS that can connect to OpenBSC through A-bis. If there's anyone volunteering to get that work started, I'd be willing to experiment with it at 26C3. But that also not on the actual production/live setup, but on a second OpenBSC instance. Regards, -- - 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)

There is A-bis over IP of course :) Because just connecting them with asterisk just proves asterisk works, you still have two independent GSM network. A better integration would allow roaming between an openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool. 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). 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 ... 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). The licenses are compatible that's a start :) (v2 or later vs v3) Anyway, just my 2cents. Sylvain

Harald, Alexander, Sylvain, others - I should probably speak up here at some point. On Oct 7, 2009, at 8:35 AM, Harald Welte wrote: That doesn't count. 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.) Yes, and that would not be too hard if we could share an HLR function. 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. Same here. You don't really understand it until you actually do it. 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. 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. 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. 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. David A. Burgess Kestrel Signal Processing, Inc.

Hi David, On Wed, Oct 07, 2009 at 09:54:53AM -0700, David Burgess wrote: 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. of course, I never assumed it was any of your priorities at all.. Well, we at OpenBSC are very interested in the actual GSM layer 3 protocols on the various interfaces (Abis, A, B and others). 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 :) 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. 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. I don't think it will be a big deal, don't worry too much about it :) 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)

Harald, David, On Thu, Oct 8, 2009 at 00:42, David Burgess <dburgess(a)kestrelsp.com> wrote: Right. At some point we'll need to create an adapter for normal HLRs anyway, so the early we start, the further we get. ;) I wonder - is there already any IETF-based protocol for such kind of interaction? Radius? -- Regards, Alexander Chemeris.