7 Nov
2013
7 Nov
'13
7:15 p.m.
hi Jason,
sorry for the one week delay, but I've been super busy and have not been
able to follow the mailing lists as much as I used to.
I have been going through your Osmocom projects
especially Openbsc
(osmo-nitb) and Osmobts projects and I must say it's a real great
work!
On behalf of the teams behind that software: Thanks for the compliments!
I'm a lead engineer at Octasic and after looking
at your work on
OpenBSC and OsmoBTS, we decided to use your OpenBSC stack for internal
testing of our Octasic PHY.
Great. It is probably not your responsibility, but I would actually
hope that you not only consider it for internal testing but also as one
possible choice for your customers ;)
I know currently openbsc supports few BTS models like
ip.access,
sysmocom etc. I have gone through the wiki and some of the openbsc
archives. I could find an archive regarding Octasic SDR, but I guess
it has not gone any further.
http://lists.osmocom.org/pipermail/openbsc/2010-November/002196.html
I am not aware of anyone having done any work in that area, no.
I will be interested in osmo-nitb which I can use for
network part of
GSM and use osmo-bts for BTS L2/L3 stuff, which already has
abis-over-ip interface to openBSC(osmo-nitb). I have Octasic SDR
hardware that has the layer1 (DSP image), so all I need to implement
is the interfaces between Octasic Layer1 and osmobts L2/L3 to
communicate between them, which I'm working on.
This is good news!
It is probably worthwhile to use the trx branch that jolly (Andreas) is
working on for adding new L1 interfaces. The master branch has many
parts that are actually not sysmobts specific in the sysmobts specific
part of the source, and Andreas' branch is introducing a new interface
(l1 sap) to resolve this.
I have already installed openbsc (osmo-nitb) and also
osmobts on my
Debian 7.1.0. I'm currently in a process of writing interfaces between
Octasic L1 and osmobts.
great. Please note, the l1sap / trx branch of jolly is definitely going
to make it easier for you.
At present I'm trying to get TRX config request
from osmo-nitb.
However though I'm receiving few OML messages like NM_MT_SET_BTS_ATTR
(pcap attached), I guess they are specific to ip.access BTS, I'm not
able to see any TRX config request coming from osmo-nitb (Or by any
chance is that what I'm receiving is the TRX config one?)
The wirshark OML dissector should decode all the messages, even the IPA
specific ones. Please check the wireshark A-bis OML dissector
preferences for 'use nanoBTS definitions' or something along those
lines.
I'm simply sending ack for those OML messages and
eventually expecting
a TRX config request from osmo-nitb. I'm not sure if osmo-nitb expects
something to se sent from BTS side, looks like it is simply waiting
for something(see below).
Please check the wiki, I _thought_ we had pcap files of OML startup with
a nanoBTS online somewhere. If you cannot find it, please ask here on
the mailinglist for somebody with sysmoBTS or nanoBTS to provide you a
startup trace.
<0005> abis_nm.c:1442 Set BTS Attr (bts=0)
<0005> abis_nm.c:1763
OC=BTS(01) INST=(00,ff,ff) Sending OPSTART
Please refer to the TS 12.21 specification. When an OPSTART is sent
from BSC to BTS, you need to transition the operational state of the
respective MO (managed objects) and indicate that back to the BSC.
I'm expecting 1st message, TRX config request from
osmo-nitb and do
not see it. I was thinking, once the abis interface is up (OML link),
osmo-nitb will trigger TRX configuration and then based on the
response from BTS, other configurations. Does osmo-nitb require some
kind of handshake from the BTS side to send the TRX configuration?
there is no single 'trx configuration' message, but a fairly intricate
system of hierarchical managed objects that have to transition their
state in the correct order. Both osmo-bts as well as OpenBSC are only
doing a half-way decent job at implementing them.
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)