Hello,
How can I utilize the iCE40 E1 USB adapter to transition from E1 to IP in a GSM network, connecting a physical Siemens BSC (which has a BTS connected) to OsmoMSC? Only the BTS and BSC are physical. I already have osmo-e1d installed. Should I use osmo-e1d or dahdi version for this transition? What would be the best approach to begin the process?
Regards, Alina
Hi Alina,
How can I utilize the iCE40 E1 USB adapter to transition from E1 to IP in a GSM network, connecting a physical Siemens BSC (which has a BTS connected) to OsmoMSC? Only the BTS and BSC are physical.
Did you say that you have only one BTS connected to your Siemens BSC?
I am not certain whether or not OsmoMSC has any support for talking to non-Osmocom BSCs: I know that Sysmocom support (for their commercial customers) the arrangement where OsmoBSC talks to pre-existing proprietary MSCs, but I don't know if there is any support for going the other way around. I am reasonably certain that OsmoMSC plus its associated OsmoMGW cannot talk to a BSC via TDM, be it osmo-e1d or otherwise - OsmoMSC+OsmoMGW combo is designed to talk 3GPP AoIP to BSCs, not the TDM version.
However, OsmoBSC plus its associated OsmoMGW instance do support the possibility of driving E1-based legacy BTS gear. Therefore, if you have only one E1-based (also Siemens?) BTS connected to your Siemens BSC, you may be able to migrate that BTS to Osmocom CNI environment by taking the legacy BSC out of the equation and making the E1-to-IP transition at the BSC (OsmoBSC+OsmoMGW) rather than at the MSC.
What are the actual models of your BTS and BSC? The specific BTS model will matter for OsmoBSC support, whereas the model of Siemens BSC is more for general education.
I also have to disclose that I have an ulterior motive in helping you with this project - I have been searching the world high and low, looking for someone who has some kind of legacy GSM BSC (at opposed to just BTS) in operation, and you may have what I've been looking for. Does your Siemens BSC include a TRAU component? If you don't know what GSM TRAU is, let me phrase the question differently: the voice channels that come out of your BSC toward the A interface (toward the MSC), what do they look like? Are they like Abis, carrying GSM-encoded speech, or are they full 64 kbit/s voice channels carrying G.711 A-law? (Either A-law or mu-law would be fine, but I am guessing A-law based on your time zone and inferred geopolitical location.)
If your Siemens BSC puts out G.711 A-law (or mu-law), then it has to include a TRAU component, and you are that precious unicorn I've been looking for! Do you have access to the management interface of that BSC, where one would presumably find an option to enable or disable TFO? Is it enabled, or can you enable it?
If your BSC is indeed TRAU-equipped and TFO-capable, I would be very happy to not only help you free-of-charge in whatever ways I can with your migration project, but possibly also pay you generously if we can work out some mechanism through which you could let me remotely play with that BSC of yours.
Sincerely, Mychaela Nadezhda Falconia (aka Nadezhda Mikhailovna in Russian) GSM/2G network operator, extreme GSM & retro-telecom enthusiast and occasional Osmocom contributor, based in USA
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.
Hi Dan,
The configuration that we have in the lab [...]
- Siemens BSC with TRAU
- Siemens BTS, I think it's BS-240
OK, sounds good. But what are your objectives, what are you seeking to accomplish? Alina said earlier that you were seeking to connect the Siemens BSC to OsmoMSC; Harald replied that this task would be quite difficult, and I concur - but of course difficult != impossible, everything is possible with enough effort - but what is the real goal? Why is the alternative solution of connecting the Siemens BTS to OsmoBSC not acceptable?
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.
- 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)
This part is outside my area of knowledge: I focus on 2G only, no 3G.
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!
Sincerely, Mychaela
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 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,
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 Alina,
First, we are tying to connect our BTS directly to OsmoBSC. I'm trying to use configuration for Siemens Bs11,
I recall Dan saying that your Siemens BTS is not BS-11 but some other, presumably bigger model. Do you know for certain if it speaks the same flavor of Abis as BS-11? Are you (or were you) able to capture any Abis traces from this BTS working with its native BSC, to see if the Abis flavor matches expectation?
Also a question for Osmocom community: it is my understanding that (almost) no one has been playing with BS-11 hardware in a long time. When was the most recent time that someone tested it and saw that it still works? Do we as a community _know_ that Siemens BTS support still works and hasn't been broken by bitrot?
but I have problems with channels configuration in DAHDI. Do you have any advice for dahdi configuration?
I don't have any experience with DAHDI yet: I expect to have a need to start playing with DAHDI soon, but I haven't got there yet. Yesterday I gave a RetroNetCall presentation on my Nokia TRAU adventures (you can watch the recording in BigBlueButton), and the current status is:
1) When I get the additional parts for my TRAU that do the actual E1 interfaces, I will need to connect those E1s to the Digium TE405P card I recently bought, and will need to learn DAHDI then.
2) Harald graciously offered to send me a Nokia InSite BTS (small like nanoBTS, but E1-based); whenever I receive that BTS and find the time to play with it, I will likewise need to learn DAHDI.
Thus I expect to have more DAHDI knowledge in a few months, but I am not there yet.
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.
Hello Mychaela,
Firstly I don't know if the list is still active or not. We are trying again to connect the Siemens BTS to OsmoBSC. I suppose that the protocol that our BTS is speaking is very similar to the BS-11 one so it will be easy to take the code from there and modify it. 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. I remember that you are interested in the configuration that we have. What do you think about this approach?
Regards, Dan Robu.
On Thu, Jun 6, 2024, 19:01 Mychaela Falconia falcon@freecalypso.org wrote:
Hi Alina,
First, we are tying to connect our BTS directly to OsmoBSC. I'm trying to use configuration for Siemens Bs11,
I recall Dan saying that your Siemens BTS is not BS-11 but some other, presumably bigger model. Do you know for certain if it speaks the same flavor of Abis as BS-11? Are you (or were you) able to capture any Abis traces from this BTS working with its native BSC, to see if the Abis flavor matches expectation?
Also a question for Osmocom community: it is my understanding that (almost) no one has been playing with BS-11 hardware in a long time. When was the most recent time that someone tested it and saw that it still works? Do we as a community _know_ that Siemens BTS support still works and hasn't been broken by bitrot?
but I have problems with channels configuration in DAHDI. Do you have any advice for dahdi configuration?
I don't have any experience with DAHDI yet: I expect to have a need to start playing with DAHDI soon, but I haven't got there yet. Yesterday I gave a RetroNetCall presentation on my Nokia TRAU adventures (you can watch the recording in BigBlueButton), and the current status is:
When I get the additional parts for my TRAU that do the actual E1 interfaces, I will need to connect those E1s to the Digium TE405P card I recently bought, and will need to learn DAHDI then.
Harald graciously offered to send me a Nokia InSite BTS (small like nanoBTS, but E1-based); whenever I receive that BTS and find the time to play with it, I will likewise need to learn DAHDI.
Thus I expect to have more DAHDI knowledge in a few months, but I am not there yet.
M~
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~
Hi Alina,
I'm very busy at the moment preparing the sysmocom office move, so let me just add very few notes.
On Tue, Apr 02, 2024 at 05:25:55PM +0300, Alina Androne wrote:
How can I utilize the iCE40 E1 USB adapter to transition from E1 to IP in a GSM network, connecting a physical Siemens BSC (which has a BTS connected) to OsmoMSC?
You will need something that can translate circuit-switched SS7 (MTP2/MTP3/SCCP/BSSAP) to 3GPP AoIP (SCTP/M3UA/SCCP/BSSAP). This can be done for example with a real/physical Cisco ITP. But then you wouldn't need any icE1usb.
Alternatively, if you go for icE1usb, I would recommend trying to use DAHDI as driver and yate as softswitch that can do the CS7-MTP2-MTP3 to M3UA translation.
Note that all of the above is just for the signaling, and not for the voice calls.
We do not currently support interfacing any circuit-switched BSCs for voice. While this is exciting from a retrocomputing / retronetworking point of view, it has some rather different challenges than what we've done so far: Support E1/TDM only on the Abis interface and then do AoIP on the A side between OsmoBSC and OsmoMSC.
There are significant differences between TDM based A and AoIP, well into the signaling - and also regarding voice codecs. In AoIP there's no BSC-colocated transcoder... while in classic TDM based A interface there normally is, and you have PCMA/PCMU.
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~
-
Alina Androne -
Dan Robu -
danr677＠gmail.com
-
Harald Welte -
Mychaela Falconia -
Mychaela Falconia