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~
