Dear Neels,
Sorry for that I might have deleted the trailing of my previous mail,
will keep it added if that is preferred.
Yes its about the Nokia Site support.
To relay some good news: the MetroSite unit of mine does bootstrap
with two TRX correctly. I tried various combinations:
1. First TRX is CCCH+SDCCH4 + TCH/Fs, second TRX just TCH/Fs.
2. First TRX is CCCH+SDCCH4 + SDCCH8 + one TCH/F, second TRX is just TCH/F.
3. First TRX is CCCH+SDCCH4 + SDCCH8, second TRX is just TCH/F.
And in all cases MO/MT calls and MO/MT SMS succeeded, so from a
functional point of view, so far so good.
Will continue with my added hopping patches to see if BB/RF hopping
works as well.
Question remains: why the UltraSite does not work then with >1 TRX?
There is a slight chance that it is still a HW fault, a suspected
cable is on its way to me, will retest it when arrives.
One difference I noticed between Ultra and Metro is that for MetroSite
the RSL bootstrap is initiated by the BTS (and not triggered by the
BSC when receiving NOKIA_BTS_CONF_COMPL), but for UltraSite even when
the unit reaches CONF_COMPL state and the TRX-es are in "waiting for
lapd" state, there is no incoming LAPD link and the BSC needs to start
those links. The other thing is that first the first TRX is waiting
for lapd --> it is being bootstrapped, and once that succeeded, the
second TRX waits for lapd, then it gets bootstrapped. For ultra on the
other hand all TRXes reaches the SW DL --> configure --> waiting for
lapd state before CONF_COMP arrives and even after the BSC needs to
trigger the RSL lapd, or maybe we are not waiting long enough...
So maybe the issue with the Ultra is related to the different logic or
order the TRXes become available for LAPD.
Regards,
Csaba
Neels Hofmeyr <nhofmeyr(a)sysmocom.de> ezt írta (időpont: 2023. jún.
21., Sze, 5:48):
Hi Csaba,
this mail arrived out of its mail thread context, and I'm afraid I no longer
remember what this was about...
Oh, the broken Nokia BTS support?
I believe I'm not the best candidate for helping you with that. But definitely
feel free to create an issue on
osmocom.org where you attach a pcap of
everything leading up to the failure. (because sending a pcap on the ML here
means we all get it into our mail inboxes, and attaching to
osmocom.org issue
means there is one copy we all have access to.)
Ideal is a single pcap with all relevant protocols (e.g. just capture
everything with wireshark), as well as including gsmtap_log from all the
osmocom components in the same wireshark pcap (see VTY 'log gsmtap').
~N
On Mon, Jun 19, 2023 at 08:32:47PM +0200, Sipos Csaba wrote:
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
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte