Hello all!
I'm still trying to bring onAir any of BTS in lab. Today we were trying with Ericsson RBS-2206. We limited hardware to the minimal possible setup containing: DXU-21 dTRU-1800 CDU-G 1800 And we created IDB with 1 cell 1TX 2RX
After it we tried to use default config from master branch initially created for RBS-2308. It worked pretty fine except RF Power which was configured as 41dBm and 41 - 12 = 29 dBm. Value 29 was not acceptable for our RBS. I checked with Ericsson BSC Doc and found that our RBS2206 has max RF output 47dBm for DCS1800. (btw, RBS2308 has only 34dBm max output according to the same document, maybe config needs to be corrected) After setting 47dBm to config, TX-0 was configured correctly and Operational led was on.
The main problem we are faced now is unavailability to perform "Enable"action on TX and RX objects and all next steps are not successful too.
After getting logs from RBS (all files are attached) I see that TX and RX enabling fails with line: [20-11-03 11:51:27.264] 0\RC_HWU_TX hwu_tx_state.c:223 TRACED:TX Enable FAILED!, RCFW_ATC_State NOT Synchronized
Looks like internal oscillator is not ready. So, the question is how to make internal oscillator synchronized? Could it be an E1 Sync stability issue caused by Digium cards? I remember we discussed it on earlier steps of bringing up OSMO-BSC. Now I have just 2 ideas what to do: 1. Set Digium card to get Sync from RBS. Now Digium is configured for Internal clocking and acts as master. Maybe in case when both sides will be configured to get sync from E1 it will decrease difference between internal clock of RBS and E1 and RBS will get Synced state. 2. Theoretically I can try to use Nokia DX200 BSC as a clock master for Digium and deliver sync to RBS from Digium. I'm not sure if timing accuracy is the same for Nokia and Ericsson HW.
One more question is where can I find some info about timing accuracy for BTS and any possible way to check it on the existing E1 line?
Thank you Babanov Ivan
Hi Ivan,
On Wed, Nov 11, 2020 at 01:26:01AM +0300, Ivan Babanov wrote:
After it we tried to use default config from master branch initially created for RBS-2308. It worked pretty fine except RF Power which was configured as 41dBm and 41
- 12 = 29 dBm. Value 29 was not acceptable for our RBS.
I checked with Ericsson BSC Doc and found that our RBS2206 has max RF output 47dBm for DCS1800. (btw, RBS2308 has only 34dBm max output according to the same document, maybe config needs to be corrected)
feel free to send a patch.
Looks like internal oscillator is not ready. So, the question is how to make internal oscillator synchronized? Could it be an E1 Sync stability issue caused by Digium cards?
The question is not "could". Any BTS always needs a proper, stable reference clock. So unless your BTS has a built-in GPS clock refrence (and that reference is configured/enabled), your E1 will have to provide a stable clock reference.
"stable" means (likely) fulfilling a clock stability that is _at the very least_ the stability of what commercial TDM/ISDN networks used to have. It doesn't hurt to have better stability.
Any crystal oscillator on any E1/T1 peripheral card (digium or not) is by far not stable enough, possibly up to 1000 times worse than required.
- Set Digium card to get Sync from RBS. Now Digium is configured for
Internal clocking and acts as master. Maybe in case when both sides will be configured to get sync from E1 it will decrease difference between internal clock of RBS and E1 and RBS will get Synced state.
And what would that get you to? In the end, a BTS that transmits at a frequency that will likely be so far off that you have serious problems connecting phones to it.
- Theoretically I can try to use Nokia DX200 BSC as a clock master for
Digium and deliver sync to RBS from Digium. I'm not sure if timing accuracy is the same for Nokia and Ericsson HW.
Sure, that should work. You can use any proper clock reference. One option I'm using here is to use a SIU-02. It has a 1PPS input for GPS, and it clocks up to 16 E1/T1 interfaces with that clock. You can then feed that clock signal to one port of your multi-port Digium card, and configure that as clock source, and the other ports will use that clock when talking to your BTSs.
One more question is where can I find some info about timing accuracy for BTS and any possible way to check it on the existing E1 line?
You would have to use some kind of test equipment that has a much more accurate/stable clock itself, like a rubidium oscillator or a GPS-DO. And then you can try to measure the Allan deviation/variance. But why do that? It's obvious that a normal crystal oscillator is way insufficient, no need to measure it.
Hi,
The question is not "could". Any BTS always needs a proper, stable
reference
clock. So unless your BTS has a built-in GPS clock refrence (and that reference is configured/enabled), your E1 will have to provide a stable
clock
reference.
How does the BTS judge if the clock satisfies its needs? Less sophisticated systems don't care and simply are unstable / off the frequency when the master clock is unstable / off-freq. The question is just because I am technically interested in the topic. Everyday there pops up some exciting stuff to learn out there :)
Ralph.
Hi,
How does the BTS judge if the clock satisfies its needs? Less sophisticated systems don't care and simply are unstable / off the frequency when the master clock is unstable / off-freq. The question is just because I am technically interested in the topic. Everyday there pops up some exciting stuff to learn out there :)
I can't be 100% sure, but my understanding is it just compares to its internal OCXO.
It know the margin of error of its OCXO, so if the incoming freq is more different than what it expects, Either the OCXO went bad or the incoming clock is bad. In either case, it's a fault.
Cheers,
Sylvain
Hi,
I can't be 100% sure, but my understanding is it just compares to its internal OCXO.
It know the margin of error of its OCXO, so if the incoming freq is more different than what it expects, Either the OCXO went bad or the incoming clock is bad. In either case, it's a fault.
OK, possibly less sophisticated than expected :) I have thought about some crazy jitter and drift detection...
Cheers,
Sylvain
Thanks!
Ralph.
Hello Harald,
Today I was able to achieve a state similar to your *.pcap file from here: https://osmocom.org/issues/4645 I see my RBS produces the pcap with the same data. I'm a bit worried about MO CONN which has DISABLED state and ERROR in RSL after sending 5ter to RBS. Is it possible to try calls in this state? I had no time today to connect Spectrum Analyser to RF output and check signal, and until next visit to the lab I hope that signal exists onAir :) At least I see that led "RF Off" is switched off now on dTRU.
Regarding clock stability issue that I was describing in previous mail, I solved it by using CISCO 3640 with E1 card as the root for SYNC. My Digium card takes clock from CISCO and provides it to RBS. RBS looks happy with it. All other tricks I planned to try were unsuccessful. Setting both sides of E1 to get sync from the neighbour did not work as expected. When I tried with real BSC DX200, it looked like BSC was un-configured and was not able to bring E1 link up.
So, my next steps are checking RF signal with analyser and trying to make a call with real UE. What do you think, is it possible?
Thank you Babanov Ivan
ср, 11 нояб. 2020 г. в 12:14, Harald Welte laforge@osmocom.org:
Hi Ivan,
On Wed, Nov 11, 2020 at 01:26:01AM +0300, Ivan Babanov wrote:
After it we tried to use default config from master branch initially created for RBS-2308. It worked pretty fine except RF Power which was configured as 41dBm and
41
- 12 = 29 dBm. Value 29 was not acceptable for our RBS.
I checked with Ericsson BSC Doc and found that our RBS2206 has max RF output 47dBm for DCS1800. (btw, RBS2308 has only 34dBm max output
according
to the same document, maybe config needs to be corrected)
feel free to send a patch.
Looks like internal oscillator is not ready. So, the question is how to make internal oscillator synchronized? Could it be an E1 Sync stability issue caused by Digium cards?
The question is not "could". Any BTS always needs a proper, stable reference clock. So unless your BTS has a built-in GPS clock refrence (and that reference is configured/enabled), your E1 will have to provide a stable clock reference.
"stable" means (likely) fulfilling a clock stability that is _at the very least_ the stability of what commercial TDM/ISDN networks used to have. It doesn't hurt to have better stability.
Any crystal oscillator on any E1/T1 peripheral card (digium or not) is by far not stable enough, possibly up to 1000 times worse than required.
- Set Digium card to get Sync from RBS. Now Digium is configured for
Internal clocking and acts as master. Maybe in case when both sides will
be
configured to get sync from E1 it will decrease difference between
internal
clock of RBS and E1 and RBS will get Synced state.
And what would that get you to? In the end, a BTS that transmits at a frequency that will likely be so far off that you have serious problems connecting phones to it.
- Theoretically I can try to use Nokia DX200 BSC as a clock master for
Digium and deliver sync to RBS from Digium. I'm not sure if timing
accuracy
is the same for Nokia and Ericsson HW.
Sure, that should work. You can use any proper clock reference. One option I'm using here is to use a SIU-02. It has a 1PPS input for GPS, and it clocks up to 16 E1/T1 interfaces with that clock. You can then feed that clock signal to one port of your multi-port Digium card, and configure that as clock source, and the other ports will use that clock when talking to your BTSs.
One more question is where can I find some info about timing accuracy for BTS and any possible way to check it on the existing E1 line?
You would have to use some kind of test equipment that has a much more accurate/stable clock itself, like a rubidium oscillator or a GPS-DO. And then you can try to measure the Allan deviation/variance. But why do that? It's obvious that a normal crystal oscillator is way insufficient, no need to measure it.
--
- Harald Welte laforge@osmocom.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-
Harald Welte -
Ivan Babanov -
Ralph A. Schmid, dk5ras -
Sylvain Munaut