Hi Dan,
Yes, you are right, this is the motivation. I used to
work with this kind of
equipment and I would like to see it working again.
Yay, nice to hear!
Since we have here at the university Mobile
Communications courses,
I am also interested in the didactic aspect of this project.
Which university is it? And approximately where in the world (which
geopolitical region) is this equipment located?
It seems that we have the same motivation, so indeed
we can be friends
and work on this nice project!
Yes indeed. :-) Let me start with the documentation I was able to find
for Siemens' version of GSM network infrastructure:
https://www.freecalypso.org/pub/GSM/Siemens/70183086-Siemens-D900-D1800.pdf
Are you familiar with this document? Does it look like your hardware
is the same as what it describes, or something different?
Are you able to identify the interfaces between components? You
already wrote this bit earlier about Abis:
Now the Abis interface is up and the BTS/BSC
configuration is ok [...]
What about A and Asub interfaces? Are you able to identify them? How
many E1 circuits are coming out of the TRAU toward the MSC: just one
or more? Are you able to identity the timeslot on the A interface on
which the BSC is trying to talk BSSAP to the MSC? And what about Asub,
the interface between the BSC and the TRAU - do you see just one E1
there, or more than one? (Note for others following this thread on
the ML: the interface which Siemens called Asub is the same as Nokia's
Ater. The other diff in terminology is that Nokia used the term TRAU
to mean each individual speech/data channel, whereas for Siemens the
whole rack is called TRAU; Nokia called the latter TCSM.)
Are you able to connect to the management interface of your BSC and
fully examine/modify its configuration? Do you see any config settings
related to the TRAU? Of particular interest to me, is there a setting
to enable or disable TFO?
Toward your goal of bringing this equipment to life, using Osmocom to
fill in those network elements (MSC and above) where you don't have
corresponding legacy equipment, you will need to start by identifying
exactly where and how the MTP2/MTP3/SCCP/BSSAP interface is coming out
of your BSC. Then it will be a task to either extend OsmoMSC with its
underlying libraries to speak SCCP over MTP2/MTP3 directly, or find
some converter to SCCP over {SCTP,TCP}/M3UA which Osmocom currently
speaks.
This signaling layer (BSSAP over lower layers) will need to be tackled
first. In the initial implementation, simply ignore all voice user
plane issues: calls won't work initially of course, but you need to
reach the point of an MS successfully finding the network and registering
(location update) before you can even begin playing with calls - hence
my recommendation is to ignore the voice user plane initially and
focus on BSSAP signaling.
M~