Dear Pau,
Not sure if osmo-bsc code to handle nokia bts is actually using any of the "new" nm_*_fsm.c FSMs to set up stuff, I guess it's not?
Have no idea to be honest.
The general issue with Nokia specifically is that once you bootstrapped the OML you cant trigger the BCCH+SACCH part just yet even when the TRX itself initiates the RSL LAPD. For Insite it does work as the software load time is fast as its a one TRX integrated unit. With MetroSite it is already longer but most of the time the LAPD timers "saves the day" and it bootstraps eventually. On UltraSite the TRX SW load and conf takes a lot of time, that is how I noticed this issue. This is why I changed the RSL lapd logic to trigger on BTS_CONF_CMPL, which is not the final solution but a workaround. Also, more than 1 trx, more complex setups (more sectors, various hopping configs etc.) also makes the bootstrap and the TRX availability longer.
In a nuthsell: we need to let the RSL lapd (but only the lapd) to be connected (initiated by the BTS), but only start the BCCH+SACCH after the BTS_STATE_CHANGED OML message received (which is not yet implemented, but working on it). Likely no other BTS does this, hence there is no standard way to handle this is the code yet (or at least I am unaware).
To add more "fun" to this: the InSite is not even sending a BTS_STATE_CHANGED message likely due to we bootstrap it "too quickly" and there might be a bug in the FSM on the BTS side which prevents this message to be sent if the LAPD and RSL are set up too close to each other. Or it might need some more time to "settle" or sync.
But before we can take care of it, we need the object id and object current state OML messages decoded, so we can trigger on them. My issue with that is I cant address it as the object identity is not processed by the find_element() function as it only looks at 1 byte and that message has 4 bytes. THe reset_type and object_current_state are 1 byte, no problem there. But this object identity is killing me:
--ID = 0x40 (Object identity) length = 4 00 01 ff ff
And all the examples in the code only checks the first 00, while the second byte is the object type (01), the third byte is the object number (ff), and the 4th byte is just ff. How can I get this 4 bytes into a variable (or better: each byte into individual variable) with find_element() ?
Regards, Csaba
Pau Espin Pedrol pespin@sysmocom.de ezt írta (időpont: 2025. jan. 20., H, 16:32):
Hi Sipos,
Not sure if it is of help since I never used a Nokia BTS, but you could look at osmo_bsc_main.c inp_sig_cb() which is basically the one applying the config at least for osmo-bts types.
In there, have a look at: """ if (isd->link_type == E1INP_SIGN_RSL) { ... bootstrap_rsl(): } """
In there, the one preparing the BCCH info afair is gsm_bts_trx_set_system_infos().
For osmo-bts (ipaccess type) AFAIR the S_L_INP_TEI_UP event is triggered when the BSC accepts the TCP/IPA RSL conn from the BTS, which usually happens *after* the TRX has been configured (since basically we provide the osmo-bsc local IP address for RSL to the osmo-bts during TRX setup over OML). See bb_transc->mo.rsl_connect_sent and bb_transc->mo.rsl_connect_ack_received.
Not sure if osmo-bsc code to handle nokia bts is actually using any of the "new" nm_*_fsm.c FSMs to set up stuff, I guess it's not?
Regards,
- Pau Espin Pedrol pespin@sysmocom.de http://www.sysmocom.de/
=======================================================================
- sysmocom - systems for mobile communications GmbH
- Siemensstr. 26a
- 10551 Berlin, Germany
- Sitz / Registered office: Berlin, HRB 134158 B
- Geschaeftsfuehrer / Managing Director: Harald Welte