Hi Neels,
I checked RF and BB hopping with my MetroSite with my patch added, and
they both seem to work, multi-TRX was tested a couple days ago, that
also works with 2 TRXes. Obviously I did not tested every possible
hopping scenarios, but in both cases the node manager reported the
correct hopping states and I also checked with a spectrum analyzer.
This means that either my UltraSite still has some issues, or that the
config logic for it needs a bit of tuning. The one difference I have
noticed is that the MetroSite does starts the RSL LAPD when the TRXes
reach a configured state, while the UltraSite needs the BSC to start
the RSL LAPD links even after the TRXes reach the same configured
state. FYI, I am running exactly the same BTS SW release on both units
(latest LTS ever released by the vendor), so they should not behave
differently from a pure SW point of view.
Anyway, at this point in time I don't see any particular issues that
indicates a BSC problem. One feature missing is the ability to
configure sectors (Nokia calls a sector a "BTS" while the base station
is called "BCF"). My question is, do we have any BTS type that has
sector configuration support so I can take a look how this was done
(if any) ?
Regards,
Csaba
Hello,
I know it's quite a dummy question (Beginner) but I'm actually trying the
BSC to two external MSCs but the attempt failed.
As per the doc, I did configure the cs7 instance.
Is there an example configuration file which I could go through.
--
Best Regards,
Varoon
Hi Neels,
Sorry for the late response.
As there is still a slight chance that the issue on my side is HW
related, I digged out my old MetroSite with 4 TRX as that is a little
bit smaller and easier to move compared to the Ultra cabinet :-)
So I will conduct some tests with it in the next couple days. Lets say
the issue is the same: what exactly do you need from me to maybe look
into it? I assume E1 pcap and logs. If you have a specific log mask,
or you need something else, please let me know.
Regards,
Csaba
Dear Osmocom community,
we're happy to announce the next incarnation of OsmoDevCall.
when:
June 21, 2023 at 20:00 CEST
where:
https://osmocom.org/OsmoDevCall (Big Blue Button)
This time, @falconia will be leading a discussion on
FR/HR/EFR voice codecs in Osmocom RAN
This meeting will have the following schedule:
20:00 meet + greet
20:10 topic as outlined above
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you soon!
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Harald,
I made some progress with the Nokia UltraSite and managed to fix its
backplane, so at least I was able to continue with reintroducing
hopping control with the first 2 TRX slots of the cabinet.
During this process I realized that apparently even multi-TRX support
is broken, which was working on the old OpenBSC codebase in 2016. If
only the first TRX is configured the BTS bootstraps fine, but when a
second TRX is configured, the unit goes into this weird state: the
first TRX loops through configurng and waiting for LAPD states and
stays in configuring state, while the second TRX is stuck ad
supervisory state where TRX test is possible (it does pass the test).
I used my old multi-TRX config file that actually worked with
UltraSite (and MetroSite) where the second TRX only has TCH/F so
nothing fancy, no hopping or anything like that.
I wonder if my modification of moving the RSL bootsrap to after
CONF_COMPLETE somehow changed something, maybe the BTS requires the
RSL LAPD links to be up during the CONF state? Or the new FSM lchan
refactoring might have introduced this in 2018...
So apparently we have some more basic issues here then hopping :-)
Regards,
Csaba
Dear Osmocom Community,
I have noticed that the wiki page for OpenBSC GPRS at
https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has
not been updated for four years, and since then, there have been
significant updates to the software. As a result, the information on the
GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS
on my system.
I have attached my configuration files below for your review.
ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel
state DOWN group default qlen 1000
link/ether ec:8e:b5:41:cb:90 brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
link/ether b8:8a:60:4f:59:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.109/24 brd 192.168.1.255 scope global dynamic
noprefixroute wlp1s0
valid_lft 7152sec preferred_lft 7152sec
inet6 fe80::649b:2ab5:6dd3:8779/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Hello Osmocom,
I have written a new specification, in the style of 3GPP specs, for
enhanced RTP transport of FR and EFR codec frames in an IP-based GSM
RAN, addressing problem areas where the general standard RTP format
for these codecs creates functional regressions relative to the
original T1/E1 Abis architecture with TRAU frames. The new spec has
its official home here:
https://www.freecalypso.org/specs/tw-ts-001-v010001.txt
and here is a pair of patches adding OsmoBTS support for accepting
this TW-TS-001 format in RTP input and optionally (per vty config)
emitting it in RTP output:
https://cgit.osmocom.org/osmo-bts/log/?h=falconia/rtp_traulike
The code patches are just for better context - they will go to Gerrit
for review later - but right now I am soliciting a review of the
specification, rather than code implementation. I am not aware of any
established process in Osmocom for reviewing new specifications
(different from code review), as writing new 3GPP-style specs is not
something this community does often. But in the present case I am
genuinely convinced that the Internet standard RTP format for GSM-FR
and GSM-EFR (written with VoIP rather than GSM RAN in mind) is truly
deficient for GSM RAN purposes, especially for those who wish to
deploy their GSM networks in a retronetworking fashion, and the only
way to bring back the full set of E1 Abis bells and whistles over IP
is to invent our own (completely optional) pseudostandard format that
will likely only be used within {Osmocom+Themyscira} community.
With this context in mind, I cordially invite all of you, esteemed GSM
FOSS developers, to review the new specification linked above.
Sincerely,
Mother Mychaela
Hi Harald,
I tested and can confirm that the Nokia code cannot handle a situation
when the first TRX is not the first physical TRX in the cabinet. This
affects MetroSite and UltraSite and all other variants that can handle
more than one TRX. Given the fact these units are getting 20+ years
old, backplane or other HW issues can force a user to not start with
the first physical TRX and in that case the RSL bootstrap fails as the
BTS receives a config starting with trx1 while the unit may has trx2
or trx3 etc.
Question is how to handle this?
One option is that on Nokia, each TRX has its own RSL TEI, and that is
a 1:1 match as much as I know. Physical TRX1 has TEI1, TRX2 has TEI2
etc. So we can make a check during fu_config to first determine the
first physical TRX based on the RSL TEI, and then check at each
iteration which is the next one. For example you can have trx2 and
trx4 as well, so we cannot expect that the TRX-es are in a continuous
order nor that they always start with trx1.
Another option is to introduce a new Nokia specific TRX variable that
describes the physical location of the TRX inside the cabinet and do
the above mentioned checks with that.
Or there is a 3rd option I am not thinking about :-)
Any and all opinions are welcome.
Regards,
Csaba
Dear Harald,
Sorry for the delay, the UltraSite cabinet has some massive
backplane/interconnect issues, I tried to sort those out in the last
couple days (with not much success).
I had some time to further investigate the Nokia UltraSite situation,
and here are the outstanding issues I faced:
1. 2-3 seconds after BTS_RESET the OML LAPD link is reestablished
(coming from the BTS itself), and the signalling logic tries to
bootstrap OML (sometimes RSL as well) during the BTS performing the
reset. This tries do fail of course. Not sure if this causes any
practical error, although it does not look nice. Maybe adding some
logic state checks can help?
2. Sometimes on the OML LAPD link (and only on that one) I can see
these error messages:
DLLAPD lapd_core.c:1315 (0:1-T1-S62) S frame response with F=1 error
DLLAPD lapd_core.c:421 (0:1-T1-S62) sending MDL-ERROR-IND cause 6 from
state LAPD_STATE_MF_EST
Sometimes they arrive in batches, sometimes only a few. FYI the BTS
and the TRE both runs the latest SW ever released for UltraSite
(CX8.2).
3. Moving the RSL bootstrap to after "NOKIA_BTS_CONF_COMPL" received
seems to be working fine, this way we don't need to add another timer,
and Osmo-BSC can wait long enough to make sure all the TRXes loaded
the SW, configured and waiting for LAPD. In case more than one TRX is
used, the TRXes reach the "waiting LAPD" state in different order.
Did you had time to maybe try with InSite? I dont think my patch can
brake it, but I remember InSite was an odd ball within the Site
family.
I also started to re-introduce RF/BB hopping control for Nokia, if you
- or anyone -
can review it that would be lovely:
https://github.com/dchard/osmo-bsc/commit/41f6cd4723961700c5e5eceab4c92e7ce…
I was not able to try it out yet, as due to my backplane issues with
the cabinet, only TRX1 and TRX3 and TRX4 slots are working. And for
some reason if I try to use TRX3 and 4, the RSL bootstrap fails. I
wonder if the Nokia code has some limitation if the first TRX is not
actually the first? I tried to configure Osmo-BSC to start with "trx
2" but it does not want to start anything other than "trx 0". Of
course the question is what OsmoBSC sends during OML bootstrap. As
much as I can see, the Nokia code does not take into account if the
first TRX is not the first physically in the unit, but I am not a 100%
sure yet. Some help or hint here would be very welcome.
This is where I am now. The HW issues with the unit makes it pretty
time consuming to focus on the SW side, for now.
If you or anyone has any ideas or comments, please let me know.
Regards,
Csaba
Hi! I just purchased a used Ericsson RBS 6000 chassis with a DUS 31 module in it. From what I have read, this module should be compatible with Open5GS for the LTE side, but I wanted to inquire about the status of support for it on the GSM side under OsmoBSC. As far as I know, it should work the same as the DUG series which is supported, with the only difference being it's use of Ericsson packetAbis/IP rather than hardware T1 lines for the voice backhaul connectivity. Will these units work with osmocom for GSM, or will I have to purchase a DUG unit for my enclosure? Is there anything else I should be aware of?
Thank you,
Enzo D'Amato