More research into the Motorola Horizon macro and Mo-bis
Once upon a time there was an Americans company called Motorola, and they
decided to implement GSM. Unfortunately they decided to deviate
significantly from the specification and implement their own proprietary
back-haul protocol between BTS and BSC, called Mo-bis. It replaces the
standardized A-bis interface.
Today, There are plenty of phased-out Motorola
Horizon / Horizon II macro BTSs that have been phased out.
Basically you can get them for scrap value, which makes them an ideal
target for GSM enthusiasts willing to run a single-cell network with
little investment. So while there are actually people who are interested
in operating a power-consuming device roughly the size of a washing
machine in their home/office - they are normally not interested in
running a 19" rack sized Motorola BSC with it. Also, the BSCs are much
less frequently to be found compared to the BTS.
So it would be great to support Mo-bis from within OpenBSC. A couple of
brave young men have set out to try the seemingly impossible. There's
absolutely zero documentation available on that protocol, and no
wireshark support either. However, the University of Brno (Czech) has a
functional Motorola BTS + BSC setup, and I was able to obtain protocol
traces from them and actually experiment with the equipment in their
lab.
The entire Motorola GSM architecture seems to be over-engineered without
end. Basically you are looking at a distributed computer from the early
1990ies. Lots of processor cards (m68k, ppc) interconnected by HDLC
links on top of synchronous 2Mbps links with 64k timeslots. Those links
are available e.g. on the backplane of the BTS as a TDM highway.
So basically even inside the BTS, the individual processors talk over
E1 to each other. In the BSC, there is a token ring based LAN between
some of the cards instead. And the MCUF in the BTS even supports to
transport those proprietary inter-cpu links via fiber optic (!).
Each processor has a 16bit identifier by which it can be addressed in
form of physical addresses. Individual processes on the
processors have fixed process identifiers, and they allocate
a variety of mailboxes in which they can receive messages from
remote processors. There are routing functions at intermediate notes.
So any process on any processor card can send messages to any mailbox of
any other process on any other processor, independent of its physical
location (locally at the BTS, or at the remote BSC, or even at remote
BTSs).
Besides physical addresses, there are also functional addresses. Thos
addresses are used particularly to support fail-over. Every board in a
BTS and BSC can be fully redundant, and if you use physical addresses,
you would address one of the two redundant boards. Using functional
addresses, you address the function they both can perform, and some
routing magic will make sure it ends up at the current active node in
the pair.
There are multiple processors in every TRX, and a couple of processors
for each BTS, processors in the E1 line cards, etc. Now speaking of the
actual Mo-bis interface: It seems to be a weird mixture between 08.58
(RSL) and 08.08 (BSSAP/BSSMAP). However, after staring at the messages
sufficiently long, I have been able to write a more or less complete
wireshark dissector for them. Radio Channel Activation (RACH/IMM.ASS)
are for example handled directly inside the BTS, they don't exist as
transactions on the Mo-bis like they do in A-bis.
So implementing the actual location update / MO+MT voice call and SMS
related transactions is actually not all that hard. What makes things
really difficult is the way the BTS is initialized at startup.
Basically what resembles the OML part of standardized A-bis.
There is a lot of low-level management and bring-up of the individual
processes and boards, and the download of a large 500 kByte-sized BLOB
simply called database. This binary database contains literally
hundreds of configuration parameters for the BTS and its neighbors. It
also contains sophisticated configuration of the message routers, the
switching/multiplexing of 64k timeslots on the various links,
information on redundant paths within the back-haul network, etc.
Interestingly, using the password combination 3beatles and
4stooges on any of the serial consoles of the BTS or BSC, you can
enter into a "god-mode" which permits you to enter the executive
monitor (EMON). The executive is the operating system they run on
both m68k and ppc processors. It provides access to something like a
syslog of messages from the various processes, and you can manually
generate messages that are to be sent to mailboxes of processes. You
can inspect the object table (application programs an databases),
read/write to PCMCIA flash cards, read and write to logical and physical
memory, inspect CPU and I/O usage and much more. In fact, the
integrated Code Object Manager (COM) even allows the processors to
synchronize their code versions and remotely boot other CPUS via HDLC
channels.
For a communications system geek like myself, it's extremely fascinating
to see such a sophisticated and versatile system. I only wonder why on
earth somebody would come up with something as complex, only to connect
a couple of BTSs to a BSC. Thus, the only logical explanation is that
Motorola has developed this distributed proprietary computing system way
before they went into GSM, and they probably just recycled it as it
already existed.
If anyone knows more about the history of this, I would be excited to
hear about it. It literally feels like being an archaeologist.
Analyzing ancient technology from our forefathers. But then, it only
is 20 odd years old. The only time I had a similar feeling was when I
briefly came in touch with IBM mainframes in 2001 and looking at IBMs
SNA protocol stack.
Syndicated 2012-03-01 01:00:00 from Harald Welte's blog
