6 Apr
2016
6 Apr
'16
11:46 a.m.
Dear Harald,
As one of the few users of OsmoBTS/OsmoNITB with an USRP SDR, let me comment on this one.
First, I don't have any commercial interest in this, I am an academic researcher, and
as most of us, the only way to be able to create a GSM network and test it is via an SDR.
For this reason I created and maintaining the Wiki article of how to get the full Osmocom
stack to work with and Ettus SDR:
http://openbsc.osmocom.org/trac/wiki/Ettus_USRP_B2xx_family
For the first few tries I was only able to get it work with a lot of non-master branches
involved.
At this time, almost all non-master branches are now avoided, OsmoBTS is the only one that
remains.
I wanted to update this Wiki article and debug the current failures with EDGE introduced
on both the PCU/BTS and TRX end, but unfortunately I am now abroad and I don't have
access to any USRP devices.
When I'll be back home, I am willing to take a closer look and try findig the issues,
but that is 2 months away.
Regards,
Csaba
----- Eredeti üzenet -----
Feladó: "Harald Welte" <laforge(a)gnumonks.org>
Címzett: "Tom Tsou" <tom.tsou(a)ettus.com>
Másolatot kap: "OpenBSC Mailing List" <openbsc(a)lists.osmocom.org>
Elküldött üzenetek: Szerda, 2016. Április 6. 9:59:11
Tárgy: Re: Lack of maintenance for osmo-bts-trx
Hi Tom,
On Wed, Apr 06, 2016 at 12:01:05AM -0700, Tom Tsou wrote:
I suspect that there were issues since the beginning
of the merge. The
issue that I saw with master was reported by Sipos Csaba back in Nov
2015.
http://lists.osmocom.org/pipermail/openbsc/2015-November/000856.html
I guess there is something wrong with the OML setup since
trx->mo.nm_state is reporting NM_OPSTATE_NULL during the post-RACH
channel allocation, but I am not familiar enough with those procedures
to debug more.
The lack of proper OML MO state machines on both sides of the A-bis OML
link doesn't make it easier either, I know :/
I'm not quite sure how that relates to the bug report above, which
indicates a problem in the UDP-based osmo-trx/osmo-bts-trx control
interface about setting the BSIC. I would assume that this is the root
cause, which only elevates towards e.g. a MO state not changing as it
normally should.
I can provide a supporting role in the above tasks on
behalf of Ettus
Thanks.
but we do need a working starting point - that makes
number 4 the most
critical item. Unfortunately, I am not able to resolve the patch
differences (I painfully tried) to make master the main user branch. I
agree that directing users to the Fairwaves branch is the wrong
approach, but right now it is the only branch for osmo-bts-trx that
works.
Can you or somebody else interested in getting this resolved provide a
full bug report, including
* debug log output on OsmoNITB side for for the rsl and nm
* debug log output on OsmoBTS side for oml / transceiver interface or
anything else related
* pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as
the control commands between osmo-bts-trx and osmo-trx
The above is what to me seems like the "obvious" way to report a bug in
order for other developers on this list to try to figure out what is
causing the problem. Maybe it's not as obvious to others and we should
put together some guidelines in the wiki on this?
In any case, I don't recall seeing a comprehensive report like this on
the list yet. If I missed it, my apologies.
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)