OpenBTS supports GPRS, but at least for me it does not work very reliably, I consider this only a proof of concept. While voice/SMS range is up to 200m, GPRS breaks down after 5m (!) distance, and the connection stalls after a while, requiring a restart of OpenBTS. I am using an USRP1 with WBX board.
Ralph.
From: openbsc-bounces(a)lists.osmocom.org [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of Sipos Csaba
Sent: Thursday, 23 January, 2014 18:37
To: Don Fanning
Cc: openbsc(a)lists.osmocom.org
Subject: Re[2]: GPRS, EDGE support
Hi Don,
Thanks for the answer.
THe problem with nanobts that it is unaccessible, and even when it turns up on ebay, it costs a fortune.
I'd rather pay that fortune for an USRP or half that fortune for a bladerf, and I will have an SDR which I can use not only as a BTS.
So, at the moment GPRS/EDGE is only possible with nanoBTS? What about USRP or BladeRF running OpenBTS?
BR,
Csaba
There has been a working GPRS stack for a while now:
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS
As for USRP or OpenBTS, I cannot comment upon having never used either platform.
Well, at least voice and SMS is not affected and works just great. GPRS uses only an open power control, no closed loop, maybe it has to do with this? At the moment I do not have other hardware for comparison, so digging deeper into this may be not so useful. The issue is discussed on the OpenBTS mailing list, with no clear results at the moment.
Ralph.
From: Sipos Csaba [mailto:dchardware@gmail.com]
Sent: Thursday, 23 January, 2014 22:01
To: Ralph A. Schmid, dk5ras
Cc: 'Don Fanning'; openbsc(a)lists.osmocom.org
Subject: Re[4]: GPRS, EDGE support
Thanks for the info!
At least now I know, that the GPRS/EDGE is part of the OpenBTS code, so any hardware is OK for packet data which can run OpenBTS. That is good news.
Anyway, it is just an educated guess, but don't you think your problem with GPRS is related to timing? My experience with real life networks clearly shows that even a slight timing related problem or inaccuracy can led to something like that.
My other experience is with R&S CMW500, which I used with a little external antenna and encountered the same problem. After a few meters even the voice calls started to drop with -60 RSSI. The reason was obvious: the device lacks any filters on the input chain (it is designed for production mode), and when all the received RF energy hits the receiver from all the bands, it causes problems like that. And the packet data was way more sensitive to this than voice calls. After installing proper filters, the problem is gone.
BR,
Csaba
OpenBTS supports GPRS, but at least for me it does not work very reliably, I consider this only a proof of concept. While voice/SMS range is up to 200m, GPRS breaks down after 5m (!) distance, and the connection stalls after a while, requiring a restart of OpenBTS. I am using an USRP1 with WBX board.
Ralph.
Csaba,
We use UmTRX routinely to develop GPRS code for OpenBSC and it works well.
I can't say much about other SDR equipment, but we have some timing related
bugs with USRP1 based devices of one of our customers.
Regarding the official OpenBTS GPRS code - we've never tried to run it, but
looking into the code, it lacks quite a few features the OpenBSC
implementation has.
On Fri, Jan 24, 2014 at 1:01 AM, Sipos Csaba <dchardware(a)gmail.com> wrote:
> Thanks for the info!
>
>
> At least now I know, that the GPRS/EDGE is part of the OpenBTS code, so
> any hardware is OK for packet data which can run OpenBTS. That is good news.
>
>
> Anyway, it is just an educated guess, but don't you think your problem
> with GPRS is related to timing? My experience with real life networks
> clearly shows that even a slight timing related problem or inaccuracy can
> led to something like that.
>
>
> My other experience is with R&S CMW500, which I used with a little
> external antenna and encountered the same problem. After a few meters even
> the voice calls started to drop with -60 RSSI. The reason was obvious: the
> device lacks any filters on the input chain (it is designed for production
> mode), and when all the received RF energy hits the receiver from all the
> bands, it causes problems like that. And the packet data was way more
> sensitive to this than voice calls. After installing proper filters, the
> problem is gone.
>
>
> BR,
>
> Csaba
>
>
>
> OpenBTS supports GPRS, but at least for me it does not work very
> reliably, I consider this only a proof of concept. While voice/SMS range is
> up to 200m, GPRS breaks down after 5m (!) distance, and the connection
> stalls after a while, requiring a restart of OpenBTS. I am using an USRP1
> with WBX board.
>
>
>
> Ralph.
>
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
hi,
while re-basing the osmo-bts-trx code with master, i saw that the ABIS
code has been replaced by libosmo-abis. libosmo-abis is not capable of
handling multiple RSL connections, so the multi-TRX support is broke
now. the attached patch will add multiple RSL connection support to
libosmo-abis.
regards,
andreas
Hi Jason,
On Fri, Nov 08, 2013 at 01:21:46PM +0000, Jason DSouza wrote:
> But I'm waiting at Opstart for Obj Class - RADIO_CARRIER to trigger
> trx-init() which is never received from BSC. That is where I'm struck
> now. All this so far is similar to sysmobts interface, something
> similar to bts_model_opstart() function in osmo-bts-sysmo.
Please see the following code from bts_ipaccess_nanobts.c:
==============
/* Callback function to be called whenever we get a GSM 12.21 state change event */
static int nm_statechg_event(int evt, struct nm_statechg_signal_data *nsd)
{
[...]
case NM_OC_RADIO_CARRIER:
trx = obj;
if (new_state->operational == NM_OPSTATE_DISABLED &&
new_state->availability == NM_AVSTATE_OK)
abis_nm_opstart(trx->bts, obj_class, trx->bts->bts_nr,
trx->nr, 0xff);
break;
==============
So the opstrart for the RADIO_CARRIER is sent in response to an incoming
NM_MT_STATECHG_EVENT_REP withe the operational state set to DISABLED and
the availability set to OK.
My guess is that you are not sending such a state event from the BTS to
the BSC. I can also not see that in the pcap file you have sent. All
OML messages in there relate to the Site MAnager or the BTS object
class, but there are no messages related to any other MOs.
As indicated, it is best to start from a known-working setup with a
supported BTS model, or at least from a protocol trace of an existing
supported configuration.
Please also make sure to set your 'bts model' to nanobts, I _think_ the
'bts model sysmobts' is still broken.
Regards,
Harald
--
- 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)
From: Álvaro Neira Ayuso <alvaroneay(a)gmail.com>
If the default codec is not specified, I get no voice in my calls.
This patch adds the parameters default-codec tch-f and tch-h to get
the voice working.
Signed-off-by: Alvaro Neira Ayuso <alvaroneay(a)gmail.com>
---
openbsc/doc/examples/osmo-nitb/nanobts/openbsc.cfg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/openbsc/doc/examples/osmo-nitb/nanobts/openbsc.cfg b/openbsc/doc/examples/osmo-nitb/nanobts/openbsc.cfg
index 7a44308..0eda9f6 100644
--- a/openbsc/doc/examples/osmo-nitb/nanobts/openbsc.cfg
+++ b/openbsc/doc/examples/osmo-nitb/nanobts/openbsc.cfg
@@ -75,3 +75,6 @@ network
phys_chan_config TCH/F
timeslot 7
phys_chan_config TCH/F
+mncc-int
+ default-codec tch-f amr
+ default-codec tch-h amr