Starting to experiment with Anritsu MD8470A signalling generator
Earlier this week I was able to pick up some new equipment (aka toys) from
the customs at Berlin TXL airport. Among other things I learned that despite
filing an Internet-Zoll-Anmeldung (IZA) (Internet Customs Declaration),
online via the German customs web site, you still have to print two copies of
it on actual paper. I only had one copy, and the customs department does not
have a copier to produce another copy. Buerocrats :/
In any case, I am now the proud owner of an Anritsu MD8470A signalling
generator, which is basically a small 3G (WCDMA) network on steroids, all
inside a single box. It can do mobility management, call control, voice calls,
sms, packet data service, WAP, etc. It even has a legacy GSM/GPRS radio, so you
can do inter-RAT hand-over between 3G and GSM.
But what is even more exciting: It includes (proprietary) APIs that allow you
to send sequences hand-crafted messages on RRC and any layer above. This means
it is an excellent tool for security and robustness testing of mobile phones.
Struggling with adding Ericsson RBS support to OpenBSC
I've been spending way too much time recently in understanding the low-level
aspects of Ericsson RBS 2000 and the associated OM2000 protocol. The goal
here is to support this family of BTS from OpenBSC.
The first big obstacle was that the A-bis Layer2 (LAPD) is quite different
from what we've seen with Siemens BTS before - and also from what the GSM Specs
TS 08.56 says.
In the Ericsson A-bis, there are the following key differences regarding standard A-bis:
- E1 timeslot is not configured statically. Instead, the BTS scans the entire E1 link and looks for SABM messages to TEI=62/SAPI=62
- There is no TEI manager
- LAPD sessions are initiated from BSC to BTS
- There is not only one OML connection for each BTS, but one additional OML connection for each TRX
- OML does not follow 08.59/12.21 but is proprietary
All those parts above have now been solved. We can initialize the A-bis link
and talk OM2000 to the DXU/IXU of Ericsson RBS 2000, and we can use that to
configure and initialize the CF (central function), as well as to configure
the IS (Interface Switch) and CON (concentrator).
However, the IS configuration is already quite difficult. In that
configuration you connect 1:1 mappings of various ICPs (Interface Connection
Points). So you can connect any 64k or even 16k sub-slot of a TRX with any of
the E1 interface(s) timeslots. However, the assignment of which TRX(TRU) is
represented by which ICP is BTS specific. On a RBS 2401 for example, the first
TRX (TRX0) is attached to ICP 512..523 (1x 64kbps signalling + 8x16kbps traffic).
So if we configure the IS to connect those ICPs 512..523 to the ICPs 4..15,
then we will get the TRX0 routed to Timeslot 1,2 and 3 of the first E1/T1
interface. You can see some examples in page
89 (pdf page 115) of this document. This works on the RBS 2401, but it
seems like the RBS 2308 has different ICP/DCP assignments than the generic RBS
2000 example that they are showing.
If anyone is more familiar with the details of the Interface Switch in RBS2000,
and specifically the ICP / DCP mapping inside the RBS 2308, I would definitely
want to have a chat with you.
If we cannot figure this out, it is impossible to bring up the per-TRX OML and
RSL links, and thus impossible to use those BTS with OpenBSC :(