Hi Harald,

I think maybe it is the bootstrap_om_trx() point where we should do some extra checks:

case S_L_INP_TEI_UP: switch (isd->link_type) { case E1INP_SIGN_OML: if (isd->trx->bts->type != GSM_BTS_TYPE_NOKIA_SITE) break;

if (isd->tei == isd->trx->bts->oml_tei) bootstrap_om_bts(isd->trx->bts); else bootstrap_om_trx(isd->trx); <----- HERE ?? break; default: break; }

?

Can we reuse the 12.21 state and make a simple check if the TRX is unlocked already (triggered by the BTS_STATE_CHANGE (trx, enabled) OML message)?

The other problem I am having is that the Object Identity size is bigger than all the examples I can find in the code:

00 01 02 FF

00 is some leading zeroes (not specified actually). 01 is the object type (for example BCF, BTS, TRX etc.) 02 is the object number (mostly TRX, or TRE in some bigger installs on UltraSite for example) FF is mostly not relevant.

How to process this with the find_element() function? I can only read and check the first byte.

Regards, Csaba

Harald Welte laforge@osmocom.org ezt írta (időpont: 2025. jan. 16., Cs, 17:30):

Hi Csaba,

On Thu, Jan 16, 2025 at 01:15:08PM +0100, Sipos Csaba wrote:

...

At the moment setting up the RSL lapd link and start its bootstrap (BCCH info and SACCH filling) is done in one go (as much as I can see).

that's true. You would have to add that somehow. I don't recall the details of the code off my head, but it shouldn't be too hard to split that in two steps and let the bts model decide when to start the RSL bootstrap?

--

• Harald Welte laforge@osmocom.org https://laforge.gnumonks.org/

============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

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