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.
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