2 Apr
2024
2 Apr
'24
4:25 p.m.
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
3 Apr
3 Apr
12:31 a.m.
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
28 May
28 May
11:40 a.m.
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.
8:54 p.m.
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
11:15 p.m.
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.
29 May
29 May
8:09 a.m.
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~
5 Jun
5 Jun
7:13 p.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(a)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~
6 Jun
6 Jun
6:01 p.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~
15 Jun
15 Jun
1:59 p.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.
3 Apr
3 Apr
12:58 a.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 Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7 Apr
7 Apr
8:08 a.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~
280
days inactive
354
days old
10 comments
5 participants
participants (5)
-
Alina Androne -
Dan Robu -
danr677＠gmail.com
-
Harald Welte -
Mychaela Falconia