Dear Harald,
A long time passed since I worked with the Nokia Site family and OpenBSC. I managed to save an UltraSite cabinet from scrap, so I try to revive it for a museum.
On the old NITB versions I managed to make this work once, now I am trying with the new (at least to me) Osmo-BSC implementation.
To keep it simple, only one TRX is configured: OML <--> E1 TS 1 (64kbit) RSL <--> E1 TS 2 (64kbit) TRXSIG <--> E1 TS 3 and 4
DAHDI is used with a Digium Wildcard TE110P T1/E1 Board.
Osmo-BSC is able to do the OML bootstrap, but the RSL waits for LAPD endlessly.
My first question is: should Osmo-BSC be able to bootstrap the BTS fully (all the way to "on air" mode) if it is not (yet) connected to any other core element (MGW, MSC, STP) ?
This is the Osmo-BSC log (after the NOKIA_BTS_RESET command + the reset_wait_time passed):
DLLAPD input/lapd.c:245 (0:1-T1-S62): LAPD Allocating SAP for SAPI=62 / TEI=1 (d l=0x56284cfbd220, sap=0x56284cfbd200) DLLAPD input/lapd.c:255 (0:1-T1-S62): k=1 N200=3 N201=260 T200=1.0 T203=10.0 DLLAPD input/lapd.c:519 (0:1-T1-S62): LAPD DL-ESTABLISH request TEI=1 SAPI=62 DLLAPD input/lapd.c:654 (0:1-T1-S62) LAPD DL-ESTABLISH confirm TEI=1 SAPI=62 DNM bts_nokia_site.c:63 (bts=0) bootstrapping OML DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x82) NOKIA_BTS_OMU_STARTED DNM bts_nokia_site.c:1583 (bts=0) Rx BTS type = 17 (UltraSite GSM 900) DNM bts_nokia_site.c:1098 (bts=0) Sending NOKIA_BTS_START_DOWNLOAD_REQ DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x84) NOKIA_BTS_MF_REQ DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x88) NOKIA_BTS_CONF_REQ DNM bts_nokia_site.c:1098 (bts=0) Sending NOKIA_BTS_ACK DNM bts_nokia_site.c:1260 (bts=0) Sending multi-segment 0 DNM bts_nokia_site.c:1260 (bts=0) Sending multi-segment 1 DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x81) NOKIA_BTS_ACK DNM bts_nokia_site.c:1604 (bts=0) Rx ACK = 1 DLLAPD input/lapd.c:245 (0:2-T1-S0): LAPD Allocating SAP for SAPI=0 / TEI=1 (dl= 0x56284d252a20, sap=0x56284d252a00) DLLAPD input/lapd.c:255 (0:2-T1-S0): k=2 N200=3 N201=260 T200=1.0 T203=10.0 DLLAPD input/lapd.c:519 (0:2-T1-S0): LAPD DL-ESTABLISH request TEI=1 SAPI=0 DLLAPD lapd_core.c:421 (0:2-T1-S0) sending MDL-ERROR-IND cause 1 from state LAPD _STATE_IDLE DLLAPD input/lapd.c:658 (0:2-T1-S0) LAPD DL-RELEASE indication TEI=1 SAPI=0 DLLAPD input/lapd.c:282 (0:2-T1-S0): LAPD Freeing SAP for SAPI=0 / TEI=1 (dl=0x5 6284d252a20, sap=0x56284d252a00) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-0)[0x56284d251770]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-0)[0x56284d251770]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-1)[0x56284d2519b0]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-1)[0x56284d2519b0]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-2)[0x56284d251bf0]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-2)[0x56284d251bf0]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-3)[0x56284d251e30]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-3)[0x56284d251e30]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR)
Would be nice to make this old beast running again.
Much appreciate any and all help.
Regards, Csaba
Hi Sipos,
On Wed, May 10, 2023 at 07:07:44PM +0200, Sipos Csaba wrote:
A long time passed since I worked with the Nokia Site family and OpenBSC. I managed to save an UltraSite cabinet from scrap, so I try to revive it for a museum.
excellent project!
My first question is: should Osmo-BSC be able to bootstrap the BTS fully (all the way to "on air" mode) if it is not (yet) connected to any other core element (MGW, MSC, STP) ?
yes.
This is the Osmo-BSC log (after the NOKIA_BTS_RESET command + the reset_wait_time passed):
I think it would be best to have a pcap file of the LAPD traffic.
I haven't used any Nokia BTS in ages, but at least in general E1 based BTS support is tested very recently with Ericsson RBS6000 units by Keith and Philipp.
The only big difference between the E1 BTSs is in the OML. So if the OML bring-up works, I'm surprised there are problems with the LAPD for RSL...
Hi Harald,
Much appreciate the prompt response.
Just try to save a piece of telco history, the Nokia *Site family made the mobile technology widely available in my country. At some point 2 out of the 3 operators complete network was based on Site (and other Nokia PDH/SDH MW) products.
think it would be best to have a pcap file of the LAPD traffic.
Will try to create one tomorrow.
The OML part works correctly, the BTS even tells OMUSIG is up and running, only TRXSIG (RSL) waits for LAPD and nothing happens. And yes: the RSL config is correct on both the BTS and in Osmo-BSC :-)
Now that we talk about it, some faint memory ring a bell about what might go wrong:
The UltraSite bootstrap differs from InSite and MetroSite in a sense that 1. after the NOKIA_BTS_RESET command it takes a lot of time for it come up (we have the "nokia_site bts-reset-timer" to handle that), and 2. even after that the TRX SW is not loaded yet: once the BSC issues "NOKIA_BTS_START_DOWNLOAD_REQ" the SW load starts but that takes another good amount of time, but Osmo-BSC starts the RSL bootstrap right away and times out (obviously, as the RSL link is not yet available as the TRX SW is not loaded yet).
I am pretty sure the above is the issue. I implemented (was more like a nasty hack) a similar timeout for the RSL as the "nokia_site bts-reset-timer" for the OML (it was so big of a hack, I never shared it I believe).
The correct way to handle this would be not via (another) timeout, but a way to poll the BTS if the TRX SW is loaded yet, but I suspect we have no idea nor documentation available to figure out how to do that. So it might be a timeout after all...
Non the less, I think this can be fixed with a bit of help :-)
Regards, Csaba
Hi Harald,
I uploaded the pcap and the associated BSC log:
I also did some measurements for how much time does it takes for the SW to load:
1. After the NOKIA_BTS_RESET command, it takes about 60-70 sec. for the OML to wait for LAPD. 2. After the NOKIA_BTS_START_DOWNLOAD_REQ it can take another 40-50 seconds for TRX to load the SW and be ready for RSL LAPD.
Do you happen to know what "NOKIA_BTS_MF_REQ" means? The rest of the commands are self explanatory, but I can't figure out what this does.
A few interesting things in the log:
After the initial OML bootstrap where we only send NOKIA_BTS_RESET_REQ and we close the LAPD after the ACK, the BSC tries to do another OML bootstrap while the BTS is being reset and the bts_reset_timer is not yet counted down.
If you look at the RSL LAPD activation part:
DLLAPD input/lapd.c:245 (0:2-T1-S0): LAPD Allocating SAP for SAPI=0 / TEI=1 (dl=0x5610bcd19e00, sap=0x5610bcd19de0) DLLAPD input/lapd.c:255 (0:2-T1-S0): k=2 N200=3 N201=260 T200=1.0 T203=10.0 DLLAPD input/lapd.c:519 (0:2-T1-S0): LAPD DL-ESTABLISH request TEI=1 SAPI=0 DLLAPD lapd_core.c:421 (0:2-T1-S0) sending MDL-ERROR-IND cause 1 from state LAPD_STATE_IDLE DLLAPD input/lapd.c:658 (0:2-T1-S0) LAPD DL-RELEASE indication TEI=1 SAPI=0 DLLAPD input/lapd.c:282 (0:2-T1-S0): LAPD Freeing SAP for SAPI=0 / TEI=1 (dl=0x5610bcd19e00, sap=0x5610bcd19de0)
The above clearly happens because it is issued before the RSL link is able to accept any LAPD connections (TRX SW is not finished loading yet).
What is interesting is that although the "NOKIA_BTS_CONF_COMPL" message arrives way late (the RSL LAPD timed out a long time ago), but it does arrive after the TRX SW is loaded correctly. Maybe this would be a good trigger to wait for before the RSL bootstrap begins? Either this or a similar timer for the RSL as we have for the OML.
Regards, Csaba
Hi Harald,
Have some good news.
I managed to bootstrap the UltraSite to on air, what I did was this:
https://github.com/dchard/osmo-bsc/commit/9be89196930f72f4f19d6c0bf512d68bda...
Just moved the RSL bootstrap to the NOKIA_MSG_CONF_COMPLETE part so Osmo-BSC waits for it to start the bootstrap. I was not able to test it with a call yet, but the site was on air and the phones where able to find it. Of course I am not sure how this affects possible error or exception handling.
I have no idea how this affects MetroSite or Insite, but hopefully their protocol stack is not that different and this can be a generic solution.
I also fixed a typo in the code:
https://github.com/dchard/osmo-bsc/commit/f3554f78985b339ea0d440ea38386c1d57...
Any and all input are welcome.
Regards, Csaba
Hi Csaba,
On Fri, May 12, 2023 at 12:11:41PM +0200, Sipos Csaba wrote:
I managed to bootstrap the UltraSite to on air, what I did was this:
congratulations.
https://github.com/dchard/osmo-bsc/commit/9be89196930f72f4f19d6c0bf512d68bda...
Just moved the RSL bootstrap to the NOKIA_MSG_CONF_COMPLETE part so Osmo-BSC waits for it to start the bootstrap.
makes sense.
I was not able to test it with a call yet, but the site was on air and the phones where able to find it.
I have no idea how this affects MetroSite or Insite, but hopefully their protocol stack is not that different and this can be a generic solution.
I have an InSite here that I wanted to set up into a working state for quite some time, so if I get around doing that, I'd be happy to test the related patch.
https://github.com/dchard/osmo-bsc/commit/f3554f78985b339ea0d440ea38386c1d57...
Please submit both of those patches to gerrit, thanks!
-
Harald Welte -
Sipos Csaba