This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi all,
it seems like supporting the Motorola BTS from OpenBSC is a really big
challenge. Not only are there problems regarding an unknown
configuration database format (see
http://laforge.gnumonks.org/weblog/2011/06/18/)
Dieter has found the following excellent document, which in Chapter 5
describes the architecture of the Motorola specific changes to A-bis:
http://read.pudn.com/downloads61/ebook/212957/SYS01.pdf
Judging from the document:
* there is an unknown 'motorola executive header' in front of RSL
* many RSL standard messages have been replaced by proprietary ones
* they use a mixture of 08.08 (A) and 08.58 (A-bis) information elements
* many features normally found in the BSC are implemented in the BTS,
e.g. the entire CHAN RQD / RSL CHAN ACT / IMM ASS CMD sequence is
done fully inside the BTS.
As a result, I think it will be a quite complex project to support those
BTSs from OpenBSC. It's not just a matter of adding some small
vendor-specific OML messages like with Siemens, Ericsson and ip.access.
While it might still be interesting, I think it's unrealistic to assume
this would happen ahead of the camp [unless somebody finds a compatible
Motorola BSC that they can borrow us for analysis + protocol tracing].
Thus, the focus for the 2011 CCC Camp is now back to ip.access. The
main issues we will be facing is on the RF side, i.e.
* RF PA for the TX side
* combining the PA outputs to be transmitted on one antenna
* filter + LNA for Rx side
* splitting the Rx signal
As indicated previously, I would love to see something like two BTS
with three TRX each.
If we'd recycle the duplexer/combiner blocks from the Motorola BTS, we
could do something like three sites with 2 TRX each. (as they can only
combine two TRX).
We _might_ also be able to re-cycle the TX PA from the Motorola CTUs, at
least on the RF side it would be pretty easy to drive them from a
nanoBTS rather than its internal source (as there's a connector).
The bigger question is how do we get the controller logic of the PA into
a state that the PA is actually enabled and active...
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)