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(a)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(a)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
>