Dear List,
With Domi we are working on some improvements on the Nokia Site E1 based BTS types, mainly focusing on the OML side.
Among many things (see the upcoming patches), one thing we would like to add is to lock all TRX-es at BSC shutdown. The OML command structures we already have, but when we added this part to the shutdown_om() function we noticed that only the first TRX receives the command, the rest does not. When we looked at the E1 capture even more surprise: the capture file lacks the OML command of the first TRX which we locked successfully (cross checked with BTS manager). Enabling LAPD debug also indicates that there is no graceful shutdown of the lapd links as well, which is my suspicion for the failing locking of TRXes except of TRX1: the connection is just cut before the last couple TRX lock commands can pass and we got just lucky with the first one timing-wise.
I think Harald or Pau mentioned a new FSM which is likely not implemented/backported for the Nokia BTS variant. The question is: does the new FSM does a graceful shutdown or maybe handles it better than the current code? I looked at the rbs2000 as an example also but I don't see that the shutdown part is handled any different/ better.
At this point I have no idea if this is the expected behavior, a bug or a missing feature? The fact we are missing an OML message in the PCAP which clearly passed the E1 line kind of indicates a bug at least there.
I am not sure but likely other BTS types might also benefit from a graceful shutdown (eg. at least lock all TRXes). The Nokia variants clearly do: without the TRXes locked, at the next BSC startup all the unlocked TRXes inadvertently start random RSL bootstraps, even in the middle of a site reset, filling the log with random errors.
Please let me know if there is any example code we should look at, and/or what your opinion is about this subject in general.
Regards, Csaba
Hi,
for ipaccess based BTS, like osmo-bts, we don't really care about the scenario you mention since the BTS is expected to lock the transceiver and reset state whenever it detects the underlaying tcp/ipa connections is closed, so that next time it re-conencts to BSC it should be in a "safe" state.
As per E1 BTS, I was not even aware of such a feature/requirement. I did a quick investigation. Shutdown in essence happens through signal_handler(), which will essentially do: 1- "bsc_shutdown_net(bsc_gsmnet);" sends signal S_GLOBAL_BTS_CLOSE_OM to each BTS, which is case of nokia calls shutdown_om() which should do whatever you want there. 2 - "osmo_signal_dispatch(SS_L_GLOBAL, S_L_GLOBAL_SHUTDOWN, NULL);" This actually does nothing afaiu because osmo-bsc nor libosmocore do any handling of this signal. 3- osmo_select_shutdown_request() This tells libosmocore main loop that we desire to shutdown. main() in osmo-bsc_main.c iterates on the mainloop based on condition osmo_select_shutdown_done().
Now, let's look further at point 3, see libosmocore select.c. Calling osmo_select_shutdown_request() (read the documentation on top of it) sets _osmo_select_shutdown_requested global variable.osmo_select_shutdown_done() checks _osmo_select_shutdown_done global variable. The logic for those variables is enclosed in poll_disp_fds(), one would probably need to debug over there after you send CTRL+C to figure out why isn't the message being sent.
Regards, Pau
-
Pau Espin Pedrol -
Sipos Csaba