You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(10) |
Nov
(7) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(38) |
Feb
(14) |
Mar
(25) |
Apr
(59) |
May
(25) |
Jun
(36) |
Jul
(39) |
Aug
(63) |
Sep
(98) |
Oct
(207) |
Nov
(116) |
Dec
(163) |
2010 |
Jan
(101) |
Feb
(105) |
Mar
(88) |
Apr
(68) |
May
(87) |
Jun
(46) |
Jul
(114) |
Aug
(183) |
Sep
(86) |
Oct
(70) |
Nov
(145) |
Dec
(78) |
2011 |
Jan
(80) |
Feb
(104) |
Mar
(87) |
Apr
(111) |
May
(91) |
Jun
(186) |
Jul
(204) |
Aug
(268) |
Sep
(91) |
Oct
(343) |
Nov
(351) |
Dec
(212) |
2012 |
Jan
(215) |
Feb
(205) |
Mar
(259) |
Apr
(157) |
May
(170) |
Jun
(155) |
Jul
(274) |
Aug
(172) |
Sep
(185) |
Oct
(162) |
Nov
(203) |
Dec
(218) |
2013 |
Jan
(278) |
Feb
(193) |
Mar
(155) |
Apr
(177) |
May
(204) |
Jun
(260) |
Jul
(127) |
Aug
(180) |
Sep
(185) |
Oct
(194) |
Nov
(84) |
Dec
(111) |
2014 |
Jan
(148) |
Feb
(165) |
Mar
(182) |
Apr
(365) |
May
(159) |
Jun
(224) |
Jul
(142) |
Aug
(82) |
Sep
(129) |
Oct
(128) |
Nov
(42) |
Dec
(180) |
2015 |
Jan
(198) |
Feb
(153) |
Mar
(98) |
Apr
(76) |
May
(54) |
Jun
(58) |
Jul
(42) |
Aug
(37) |
Sep
(19) |
Oct
(44) |
Nov
(49) |
Dec
(17) |
2016 |
Jan
(59) |
Feb
(50) |
Mar
(72) |
Apr
(33) |
May
(98) |
Jun
(52) |
Jul
(80) |
Aug
(28) |
Sep
(26) |
Oct
(44) |
Nov
(25) |
Dec
(33) |
2017 |
Jan
(108) |
Feb
(61) |
Mar
(42) |
Apr
(29) |
May
(34) |
Jun
(8) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(6) |
Dec
(5) |
2018 |
Jan
(8) |
Feb
(6) |
Mar
(13) |
Apr
(10) |
May
(13) |
Jun
(10) |
Jul
(6) |
Aug
(1) |
Sep
(4) |
Oct
(11) |
Nov
(8) |
Dec
|
2019 |
Jan
(4) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(3) |
Jun
(6) |
Jul
(1) |
Aug
(8) |
Sep
(8) |
Oct
(2) |
Nov
(1) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(3) |
2021 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Sylvain M. <24...@gm...> - 2009-10-10 21:30:03
|
Hi, I've been trying to run openBTS 2.4 for the last couple of days but with limited success. I use a Nokia 3310 in BTS Test mode locked on my ARFCN and it "sees" the network but can't join. Basically it sends RACH (I need it's monitoring AGCH on the lcd) but never gets any response. Once, after a recompile I started OpenBTS just to see the results of my additional debug and to my surspise, as soon as it started the phone saw the network, sent a RACH and got assigned a SDCCH and received the welcome sms and from there It worked, i sent sms thru command line and such. But as soon as I stopped the process and restarted it, never worked again ... My main problem currently I think are RX timestamps discontinuity. When looking at the USRPDevice::readSamples function, I would expect the timestamps on read packet to be continuous (i.e. lastPktTimestamp + 126 == newPktTimestamp). But in my case it's quite common to either have overlaps (new packets has samples that were in the old as well ... didn't check if they matched) or big jump forwards (sometime tens of thousands !!!). The transceiver process only takes like 20% of CPU so I don't think that's the problem. I also tried setting it to very high sched prio but that didn't help. For the sake of full disclosure, I am trying to run it in a 'officially unsupported' configuration since I have only 1 RFX900 board so I'm doing RX/TX on the same board. I obviously had to change the USRPDevice.cpp code to init the things properly. However I don't think the problem lies there since during the tests, it worked nicely for a few minutes, until I restarted. Regards, Sylvain |
From: Alexander C. <ale...@gm...> - 2009-10-10 17:34:03
|
Hi Andreas, On Thu, Oct 8, 2009 at 15:56, Andreas.Eversberg <And...@ve...> wrote: > on the congress i use linux-call-router to route isdn traffic from > versatel to berlin and vice versa for free as part of versatel > sponsoring. i would like to join the POC (phone operation center) in the > upper hall again this year. there we sit close to the "eventphone" guys, > so we can easier communicate and do cabeling of our hardware. it would > be nice to have also the openbsc and openbts projects close to us. we > could easier interact and build one test networks. since eventphone uses > an own linux-call-router hardware, i can use my test machine without > disturbing the external isdn connection to versatel. it is equipped with > two E1 cards, one for interconnection with eventphone, the second one > can be used for BS11. eventphone has a big DECT pbx running and provides > mobile access. We'll bring one or two our USRPs for OpenBTS testing even if David Burgess won't be able to come, and we would love to be located near OpenBSC guys and you. But that'll be our first time at 26C3 and we're little bit lost - should we send some request to get the space? Do you have an option for VoIP link rather then E1? -- Regards, Alexander Chemeris. |
From: Alexander C. <ale...@gm...> - 2009-10-10 16:45:44
|
Hi Eli, On Fri, Oct 9, 2009 at 22:25, David A. Burgess <dbu...@jc...> wrote: > On Oct 6, 2009, at 3:28 PM, Eli Gurvitz wrote: >> I am using the stock USRP. I understand the clock issue but I don't know how >> to replace the oscillator on my USRP. Is it something that I can do myself >> or should I order a new USRP board or a daugther card? I saw a mention of a >> kit from Funkamatur - do you think it will help? > > I have not used the Funkamatur kit, but others have and report good results. > We are using a 26 MHz TCXO with a clock doubler. We will move to a 52 MHz > VCTCXO in the future. You can do it yourself if you have advanced skills in soldering. We did this ourselves with VCO+PLL development board from National Semiconductors, 10MHz TCXO and some fragile soldering. We're now working on a producing some similar ones on a custom PCB and will make them available for sale. Refer to my previous posting to this mailing list "New external clock board for USRP" for details. PS You may also use laboratory reference generator if you have one - then you'll only need to solder SMA connector on USRP. -- Regards, Alexander Chemeris. |
From: David A. B. <dbu...@jc...> - 2009-10-09 18:45:56
|
On Oct 9, 2009, at 10:55 AM, dreamwvr wrote: > David, > I have a question before I buy a USRP std and the 2 RX900 I will > need > to tx and rx. If in north America can I without licensing and or > cooperation by any cell carrier do the following. Instead of 2 RFX900, I would recommend 2 RFX1800 and then reprogram them for 900. Also, you will need a better clock for good operation. This does not require cellular carrier cooperation, but does require VoIP carrier cooperation, which is easy to get. As for radio licensing, I cannot speak to that. It depends on how you operate the system and I dare not dispense legal advice. > 1 - send SMS/MMS and receive SMS/MMS from unit using local sim DID > installed in a Sierra Wireless GSM modem SMS but not MMS. Also, you must assign the DID. The SIM does not know its own DID, just its IMSI. For local SMS, the DID is just an extension in the SIP configuration. > 2 - rx and tx voice via voip for my cell calls when next to USRP unit Yes. > 3 - forward calls the normally would be rx by local cell carrier > network and relay to voip say vonage account to be picked up > by nokia test phones once I get my hands on them. > Currently only have bb and razor 4 testing which are not > supported. To do that, you would need to set the call forwarding parameters on the cellphones to route calls to a VoIP DID when they are not in the normal GSM network. Also, I would recommend using a more technically- oriented carrier and a local SIP PBX, not a mass-market service like Vonage. We have had good results with link2voip. (Vonage would work in principle, but they are probably not set up for the kind of support you might need. The VoIP carrier would be cheaper, too.) David A. Burgess Kestrel Signal Processing, Inc. |
From: David A. B. <dbu...@jc...> - 2009-10-09 18:31:07
|
On Oct 6, 2009, at 3:28 PM, Eli Gurvitz wrote: > Hi David, > > Thanks for the release. > > I am using the stock USRP. I understand the clock issue but I don't > know how to replace the oscillator on my USRP. Is it something that > I can do myself or should I order a new USRP board or a daugther > card? I saw a mention of a kit from Funkamatur - do you think it > will help? I have not used the Funkamatur kit, but others have and report good results. We are using a 26 MHz TCXO with a clock doubler. We will move to a 52 MHz VCTCXO in the future. > > I also wanted to ask - why can't we use the clock signal from a > commercial provider for correcting the stock USRP clock? I think I > read somewhere that each daughter card has an RX and a TX path, so > we should have a spare RX path for monitoring a commercial beacon? The problem is that the USRP would have to transmit and receive in the downlink band at the same time, or periodically interrupt its own beacon to measure the beacon of another station. That could be made to work in a desktop box, but will not work very well in a full-power system, with duplexers and filters in the receive path. Also, we need to design for greenfield deployment where we will *be* the only commercial carrier in the area. We cannot assume anyone else is out there, or even that other BTS units of our own network will be receivable. > > Thanks, > Eli > > David A. Burgess Kestrel Signal Processing, Inc. |
From: David A. B. <dbu...@jc...> - 2009-10-09 17:37:56
|
Anne - You will not receive 200 OK from OpenBTS unless/until the SMS is actually delivered to the handset. OpenBTS is just a conduit to the handset and has no store-and-forward function. So SIP MESSAGE either returns 200 OK after a few seconds or it just fails silently. You should probably set your SIP MESSAGE retry timeout to 5-10 seconds, but if the delivery attempt fails that probably means that the BTS is too congested to deliver anything or it means that the handset is out of service, turned off, etc. We do have a store-and-forward server that works with OpenBTS r2.5 and will release it publicly with r2.5 as soon as we get a few more bugs out. That server does produce an immediate 2xx response to a deliverable SIP MESSAGE and then stores the message locally until it is finally delivered. -- David On Oct 9, 2009, at 10:01 AM, anne kwong wrote: > Hi, > > When a SMS is delivered to MS, I don't see any L3CCFactory return > value. > > Is this an expected or something that can be fixed? > > The problem is that when openbts receives the SIP MESSAGE, it does > not send back an 200 OK. Therefore, the sip server keeps on > resending. I want to fix this problem, but I am not familiar with > the L2/L3 side of the story. > > Any pointers? > > thanks, > Anne David A. Burgess Kestrel Signal Processing, Inc. |
From: anne k. <akw...@gm...> - 2009-10-09 17:01:46
|
Hi, When a SMS is delivered to MS, I don't see any L3CCFactory return value. Is this an expected or something that can be fixed? The problem is that when openbts receives the SIP MESSAGE, it does not send back an 200 OK. Therefore, the sip server keeps on resending. I want to fix this problem, but I am not familiar with the L2/L3 side of the story. Any pointers? thanks, Anne |
From: Casey H. <spa...@gm...> - 2009-10-09 05:51:38
|
You will find OpenBTS 2.4 will solve all of your problems .. well..most :) On Oct 8, 2009, at 10:36 PM, Wenhui Liu wrote: > Thanks David,I'm now doing an research on openBTS,and got some > trouble with openBTS 1.6. > Your work is great! > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference_______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: Wenhui L. <fr...@gm...> - 2009-10-09 05:36:19
|
Thanks David,I'm now doing an research on openBTS,and got some trouble with openBTS 1.6. Your work is great! |
From: Christian M. <Chr...@in...> - 2009-10-08 23:34:09
|
Harvind, thank you for your reply. I checked out a fresh instance of revision 9581 5 minutes ago, opened it with Quartus 2 Web Edition 9.0 sp2 on Windows XP. I get about 160 errors for every bit of o_header_data Error: Net "rx_buffer_inband:rx_buffer|o_header_data[2][60]", which fans out to "rx_buffer_inband:rx_buffer|Mux3", cannot be assigned more than one value Error: Net is fed by "rx_buffer_inband:rx_buffer|rx_channel_buffer:cb[2].chan_buf[1]|o_header_data[60]" Error: Net is fed by "rx_buffer_inband:rx_buffer|rx_channel_buffer:cb[2].chan_buf[0]|o_header_data[60]" However I cannot really find the source of the error. I am currently trying to write a patch for two independent tx channels over the same dac. (for independent channels or digital baseband hopping inside fpga) I assume I won't touch the parts of Eric Schneider's changes, so I could develop against the current tag 3.2.2 version and it should then be easily integrated into Erics version to stay as most compatible as possible with the version you are integrating into OpenBTS. Any other ideas? Thanks Christian Harvind Samra schrieb: > Christian, > > I made no modifications. > > The version that Eric Blossom pointed me to was Eric Schneider's > development branch, rev. 9581. > > --- Harvind > > On Thu, 2009-10-08 at 23:39 +0100, Christian Meier wrote: > >> Hi Harvind, >> >> Harvind Samra wrote: >> >>> Christian, >>> >>> I'll be moving the Transceiver52M code to use the inband_1rxhb_tx.rbf >>> file soon. It will probably be off of Eric Schneider's gnuradio >>> developer branch, since it seems to have the fewest bugs. >>> >>> >> Today I tried to compile ets branch version, but i didn't get it >> compile. On contrast, the version of tag 3.2.2 >> compiled well and fitted. >> Did you modify something corresponding to Eric's version? >> >> Thanks >> Christian >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Openbts-discuss mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > |
From: Harvind S. <hs...@ke...> - 2009-10-08 22:50:57
|
Christian, I made no modifications. The version that Eric Blossom pointed me to was Eric Schneider's development branch, rev. 9581. --- Harvind On Thu, 2009-10-08 at 23:39 +0100, Christian Meier wrote: > Hi Harvind, > > Harvind Samra wrote: > > Christian, > > > > I'll be moving the Transceiver52M code to use the inband_1rxhb_tx.rbf > > file soon. It will probably be off of Eric Schneider's gnuradio > > developer branch, since it seems to have the fewest bugs. > > > Today I tried to compile ets branch version, but i didn't get it > compile. On contrast, the version of tag 3.2.2 > compiled well and fitted. > Did you modify something corresponding to Eric's version? > > Thanks > Christian > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: Christian M. <Chr...@in...> - 2009-10-08 22:39:58
|
Hi Harvind, Harvind Samra wrote: > Christian, > > I'll be moving the Transceiver52M code to use the inband_1rxhb_tx.rbf > file soon. It will probably be off of Eric Schneider's gnuradio > developer branch, since it seems to have the fewest bugs. > Today I tried to compile ets branch version, but i didn't get it compile. On contrast, the version of tag 3.2.2 compiled well and fitted. Did you modify something corresponding to Eric's version? Thanks Christian |
From: David B. <dbu...@ke...> - 2009-10-08 17:10:54
|
All - OpenBTS 2.4 ("Kinder") is available for anonymous download on sourceforge. This is *supposed* to be in the GNU Radio trunk by now, but I've run into some kind of automake/config problem that is preventing me from completing that check-in right now. The obvious new features since 1.6 are a command line interface, support for 52 MHz USRP clocks and partial support for SMS. It also works with a wider variety of handset models. -- David David A. Burgess Kestrel Signal Processing, Inc. |
From: Andreas.Eversberg <And...@ve...> - 2009-10-08 12:47:45
|
>I believe in the positive impact of OpenBTS and OpenBSC interoperability for >the both communities and as encouraging factor for possible future OpenBTS >test sites. > >We're ready to work with you beforehand to minimize on-site efforts. > >PS Where can we find agenda? Official 26C3 site is nearly empty. hi all, on the congress i use linux-call-router to route isdn traffic from versatel to berlin and vice versa for free as part of versatel sponsoring. i would like to join the POC (phone operation center) in the upper hall again this year. there we sit close to the "eventphone" guys, so we can easier communicate and do cabeling of our hardware. it would be nice to have also the openbsc and openbts projects close to us. we could easier interact and build one test networks. since eventphone uses an own linux-call-router hardware, i can use my test machine without disturbing the external isdn connection to versatel. it is equipped with two E1 cards, one for interconnection with eventphone, the second one can be used for BS11. eventphone has a big DECT pbx running and provides mobile access. what do you think? andreas |
From: Wenhui L. <fr...@gm...> - 2009-10-08 08:03:34
|
Thanks, I searched this on google,and found a multi-sims card(6 imsi) costs $4.1 (rmb 48) . -- Wenhui Liu Department of Computer Science,Nachang University,student |
From: <24...@gm...> - 2009-10-07 22:57:12
|
> > 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, ie using > the > standard interfaces that GSM/3GPP use for the HLR - which I doubt is > something > that you would want to see :) After having a quick look at the specs : - The VLR would stay in each OpenBTS/OpenBSC instance (since it's usually attached 1:1 to a MSC) - The common part needed would group HLR/AuC/EIR If you want 'official' interfaces, that means D interface, F interface & G interface to implement. Each run over SCCP and there are standardized ways to transport SCCP over IP. Most of it seems to be in GSM 09.02 (using ASN.1 notation, enjoy ...) AFAICS. The whole VLR & D/F/G MSC side code can obviously be shared by both project and just expose an very simple internal API. Sylvain |
From: Alexander C. <ale...@gm...> - 2009-10-07 20:51:23
|
Harald, David, On Thu, Oct 8, 2009 at 00:42, David Burgess <dbu...@ke...> wrote: > Harald - > > On Oct 7, 2009, at 12:53 PM, Harald Welte wrote: > >> >>> 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 :) > > I'm open minded at this point. We eventually have to interface to standard > HLRs anyway and I need some project to force me to learn the MAP stuff. It > would also be good if the underlying database can be used to generate > configurations for FreeSWITCH or Asterisk, but that should not be hard given > any SQL-based system. 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. |
From: David B. <dbu...@ke...> - 2009-10-07 20:45:56
|
Harald - On Oct 7, 2009, at 12:53 PM, Harald Welte wrote: > >> 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 :) I'm open minded at this point. We eventually have to interface to standard HLRs anyway and I need some project to force me to learn the MAP stuff. It would also be good if the underlying database can be used to generate configurations for FreeSWITCH or Asterisk, but that should not be hard given any SQL-based system. -- David David A. Burgess Kestrel Signal Processing, Inc. |
From: Harald W. <la...@gn...> - 2009-10-07 20:05:00
|
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 <la...@gn...> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) |
From: Alexander C. <ale...@gm...> - 2009-10-07 18:29:50
|
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 <dbu...@ke...> 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, 24...@gm... 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. |
From: David B. <dbu...@ke...> - 2009-10-07 17:02:20
|
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, 24...@gm... 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. >> >> 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.) > >> 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. > > 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. > >> 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. > > -- > - Harald Welte <la...@gn...> http:// > laforge.gnumonks.org/ > ====================================================================== > ====== > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 > 175-7 Ch. A6) David A. Burgess Kestrel Signal Processing, Inc. |
From: Harald W. <la...@gn...> - 2009-10-07 15:35:39
|
Hi Sylvain and others, On Wed, Oct 07, 2009 at 02:09:14PM +0000, 24...@gm... 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 :) > > 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. > A better integration would allow roaming between an > openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool. Indeed! > 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. > 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. > 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. 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. 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. > 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. -- - Harald Welte <la...@gn...> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) |
From: <24...@gm...> - 2009-10-07 14:09:27
|
> 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 :) 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 |
From: Alexander C. <ale...@gm...> - 2009-10-07 12:32:20
|
We're using two Multi-SIM cards here, but we found this way pretty expensive, so switched to use old SIM cards from local and non-local operators. Yet Multi-SIM cards are much better for testing, because you can program them to belong to any MCC/MNC you want to (MCC and MNC codes are what IMSI starts with - http://en.wikipedia.org/wiki/IMSI). On Tue, Oct 6, 2009 at 03:21, Casey Halverson <spa...@gm...> wrote: > Has anyone found a good source for testing GSM SIMs? My goal is to have a > pile of SIMs dedicated and provisioned in OpenBTS. I have seen some on > dealextreme, chinese sites, etc. but was unsure what others have done. > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 |
From: Alexander C. <ale...@gm...> - 2009-10-07 12:30:06
|
Hi Harald, On Wed, Oct 7, 2009 at 10:19, Harald Welte <la...@gn...> wrote: > On Tue, Oct 06, 2009 at 08:36:04PM +0400, Alexander Chemeris wrote: >> We're thinking about bringing one or two USRPs configured to run >> OpenBTS. We'll be interested in testing the setup in real life and >> interconnecting them with your OpenBSC setup - I think it should >> be possible with Asterisk. > > 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. 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. I believe in the positive impact of OpenBTS and OpenBSC interoperability for the both communities and as encouraging factor for possible future OpenBTS test sites. We're ready to work with you beforehand to minimize on-site efforts. PS Where can we find agenda? Official 26C3 site is nearly empty. -- Regards, Alexander Chemeris. |