Motorola Mo-bis / Implications for CCC Camp

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