Hi Mychaela, The configuration that we have in the lab (I am working together with Alina in this project) is the following (I don't know now by heart the hw versions and names, but we'll get them): - Siemens BSC with TRAU - Siemens BTS, I think it's BS-240 Now the Abis interface is up and the BTS/BSC configuration is ok (we have done some tests with a K1297-G20, but unfortunately the K1297 is not functioning anymore, we have to solve also this problem :) ) - there is also a Siemens/NEC NodeB 440 that should be ok, but we don't a functional RNC (the Iub interface is a STM1 optical) Regards, Dan Robu.

The only reason I can think of is perhaps you are someone like me, someone who absolutely loves and adores retro-telecom technologies and old telco gear of all kinds, and wishes to keep the real Siemens BSC and its TRAU as a matter of philosophical principle. If this situation indeed holds, please let me know! I have to explicitly ask this question because motivations like mine are extremely rare in this community, most other participants around here seem to approach from a commercial PoV, and their mindset tends to be totally different from mine.

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. Since we have here at the university Mobile Communications courses, I am also interested in the didactic aspect of this project.

In any case, I am still interested in hearing what is your motivation for getting the Siemens BSC (with TRAU) working with Osmocom CNI, and not just the BTS part - if your motivation is akin to mine (philosophically principled retronetworking), then maybe we can be friends!

It seems that we have the same motivation, so indeed we can be friends and work on this nice project! Sincerely, Dan.

Hi, First, we are tying to connect our BTS directly to OsmoBSC. I'm trying to use configuration for Siemens Bs11, but I have problems with channels configuration in DAHDI. Do you have any advice for dahdi configuration? Regards, Alina În mie., 29 mai 2024 la 09:09, Mychaela Falconia <falcon@freecalypso.org> a scris:

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~

Hi, Do you think that it would be possible to initialize the BTS with the classic Siemens BSC and afterwards to connect it to Osmo-BSC? Of course, trying to use the same configuration parameters. We already tried something and we got some messages, but I think we missed some parameters. Dan.

Hi Dan,

Firstly I don't know if the list is still active or not.

I likewise don't know if openbsc ML is still functioning or not - but I am able to converse with you since you listed me as a direct email recipient. :)

We are trying again to connect the Siemens BTS to OsmoBSC.

Sounds like a fun project - but I'm sure you are aware that an extra 2 y have passed since the last time you brought it up on openbsc ML.

I suppose that the protocol that our BTS is speaking is very similar to the BS-11 one

Please correct me if I misunderstood you, but based on what you and Alina wrote so far, you are currently _hoping_ that the Abis dialect spoken by your Siemens BTS will be similar to the already supported BS-11 - but it is only a hope currently, not a confirmed fact yet.

so it will be easy to take the code from there and modify it.

*If* the Abis dialect proves to be similar enough - but that part needs to be confirmed first.

What we are trying to do now is to trace the initialization of BTS when is connected the Siemens BSC that we have and try to add the message sequence to the code of OsmoBSC.

You do have the advantage of having a real Siemens BSC - certainly use this advantage! The next question is exactly how to sniff the communication between your Siemens BSC and BTS. I saw your woes regarding K1297-G20 test instruments that no longer boot; I wish I could help, but I never worked with such instruments (never even saw one with my own eyes) and I don't have any help to offer there. There is, however, this alternative: https://osmocom.org/projects/e1-t1-adapter/wiki/E1_tracer The linked wiki page says "Fully assembled products based on this hardware are going to be made available by sysmocom" - but I don't see this product in the webshop. You can try asking Harald, or bite the bullet and build it yourself based on the published design files.

I remember that you are interested in the configuration that we have.

Please keep in mind that our last exchange was in 2024 - a lot of new developments happened over the past 2 y. :-) Back in the early summer of 2024 I was indeed interested in your BSC setup for its TRAU component, specifically hoping that you might have a TFO-capable TRAU that might be amenable to remote play. However, my quest for a TFO-capable TRAU has been satisfied since then: I now have a Nokia TCSM2 setup in my lab, which includes TFO support for FR, HR and EFR codecs.

What do you think about this approach?

If by "this approach" you mean sniffing communication between your Siemens BSC and BTS, and then getting OsmoBSC to talk to the same BTS instead, I say yes, it is a good approach. I also remember that you previously considered another approach where you would connect your Siemens BSC to OsmoMSC, which would require significant work on OsmoMSC to talk to E1-based BSCs. Comparing the two approaches, the approach of OsmoBSC driving your Siemens BTS has the advantage of sharing/reusing the work of American 2G Cooperative. In the 2 y period that elapsed since our last exchange, I co-founded a cooperative that seeks to operate a new GSM/2G network in some rural locations in USA, and we are moving ahead with Nokia Flexi Multiradio (sourced from the surplus market) as our choice of BTS hardware. Our architecture includes having OsmoBSC drive this E1-based BTS, with an osmo-bsc instance at each cell site, connecting to an MSC via a WireGuard tunnel running over public Internet. Each of our MSCs will consist of an osmo-msc process plus a bunch of our own add-ons described in our Hera MSC architecture spec. If you manage to connect your Siemens BTS to OsmoBSC, you will be able to benefit from all of the improvements I've made to the subsystem of OsmoBSC driving E1-based BTS, including the new tw-e1abis-mgw that partially replaces osmo-mgw in E1 role. And when Hera MSC (suite of add-ons to OsmoMSC) becomes a reality (hoping to get to it this year), you will likewise be able to run this very powerful MSC together with OsmoBSC, tw-e1abis-mgw and your E1-based Siemens BTS. OTOH, if you pursue the alternative approach of extending OsmoMSC to talk to an existing E1-based BSC (Siemens or any other), while such project would be very interesting and exciting from philosophical PoV, there won't be any real opportunity to share work in common with American 2G Cooperative. While I love the idea of using real historical BSCs as a philosophical (or lab!) exercise, it is impractical for the needs of A2GC. Surplus telecom hardware is inherently scarce and hard to obtain, plus it has the requirement of physical space and TDM transport to cell sites. When the BSC is reduced to a piece of software, as OsmoBSC is, it becomes trivial to outfit each individual cell site with its own BSC, with the physical hw of this per-site BSC being a Raspberry Pi or some other SBC of negligible physical size and power requirements, compared to the macrocell BTS it will sit next to. OTOH, a traditional BSC from any of the legacy vendors requires a physical building somewhere to house it, plus physical leased lines to haul Abis from each of many cell sites to this BSC hut - completely unaffordable to our tiny co-op. Contrast with our chosen approach where each cell site needs only a regular consumer-grade Internet connection, whatever happens to be available at the site, which can even be Starlink if nothing else is available on a barren mountaintop or wherever. Hopefully I have given you some food for thought. M~

Harald wrote:

In AoIP there's no BSC-colocated transcoder... while in classic TDM based A interface there normally is, and you have PCMA/PCMU.

I decided to dive into this rabbit hole once again, and I discovered some details which differ from what has always been taught in Osmocom land. The purpose of this post reply is to share these findings with the community. As it turns out, in Nokia's implementation of GSM BSS the transcoder (bank of TRAUs) is not enmeshed inside the BSC, nor is it enmeshed inside the MSC. Instead they introduced a third interface named Ater, joining the ranks of A and Abis. The voice path looks like this: MSC <---A i/f---> TCSM <---Ater i/f---> BSC <---Abis i/f---> BTS The bank of TRAUs (the term TRAU strictly means a single voice/CSD channel handler) is called TCSM in Nokia land, which stands for Transcoder and Submultiplexer. This TCSM sits between MSC and BSC in the voice path, while its physical placement can be either at the MSC site or the BSC site. (Locating the TCSM at the MSC site results in 4x savings on TDM leased line costs, hence I would imagine this choice was the popular one, but what do I know, I wasn't there...) Whatever the physical placement of the TCSM, the A interface is a bunch of E1/T1 circuits, and so is Ater. But the codecs are different: on A each call takes up a full timeslot in G.711, on Ater each call is 1/4 of a timeslot in the same format as on Abis. I have yet to learn how Siemens and Ericsson implemented this part in their respective BSS architectures, but at least old Nokia gear has a sane & sensible design in this regard. I am now looking to acquire a Nokia TCSM, either TCSM2 or TCSM3i. Based on my reading of the docs found online, it should be possible to fire up a TCSM by itself, having neither an MSC nor a BSC of TDM kind. What would one do with a TRAU by itself, without those other network elements? Answer: play with TFO! Without TFO, a TRAU is quite UNinteresting: it doesn't do anything more than what is contained in reference C sources for HR/EFR/AMR codecs from ETSI, i.e., practically free code which we can run and study as we please. But if a TRAU supports TFO and if that feature is enabled, then it is a complex wonder with a stealthy in-band messaging protocol (messages transferred by stealing the lsb of every 16th sample), lots of state machines and timers - this is the kind of stuff where it would be impractical to develop a new implementation and have any confidence about its correctness without being able to test against someone else's existing implementation. If anyone here has any leads to Nokia surplus GSM equipment dealers, I would greatly appreciate some pointers. I know there are people who run Nokia InSite/MetroSite/UltraSite BTSes with Osmocom - perhaps the same dealers who sell that BTS gear would also have some components from higher up the signal chain? M~