Openbsc support for new BTS

historical

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)