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
Dear Andreas,
I noticed you rebased the code and I have further comments and requests
for general changes.
Magic Numbers:
Please avoid magic numbers where you can. There is no runtime overhead
by using a define and little pre-processing overhead.
E.g. in here
#define L1SAP_IS_LINK_SACCH(link_id) ((link_id & 0xC0) == 0x40)
Make your methods smaller:
Please compare this with the work Daniel and me to in cleaning up your
code in the osmo-pcu. By splitting up the alloc_algorithm_b code we
started to notice various defects just by looking at the code.
Remove copy and paste:
I think I saw the msgb in-place changing in at least two places. Avoid
copy and paste (code cloning).
Avoid putting logic in deeply nested constructs:
if (a)
if (b)
if (c)
important_stuff
kind regards
holger