Bug #5634


Paging broken (at least) for E1 BTSs

Added by dexter 19 days ago. Updated 10 days ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Spec Reference:


The change with the ID I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44 introduces a new way to handle nm signgals in paging.c. This seems to break the paging for E1 based BTSs.

For some reason the right signal / nsd->obj_class combination never occurs and so the line "bts->paging.available_slots = paging_estimate_available_slots(bts, load_ind_timeout);" is never executed. This results into 0 free paging slots, which means paging requests will never find a free slot to get executed. Also the VTY shows 0 free paging slots. When one commit below the change above is checked out and osmo-bsc is compiled in that state, then the paging is fine again.

A solution might be to find out what signal and object class combinations occur in the E1 world and to see how that is different from the ipacces world. At least the signal S_NM_RUNNING_CHG never occurrs, when the line that filters on this signal is commented out it drops out in the default section of the case below because the expected object class never occurs.

Actions #1

Updated by laforge 19 days ago

Hi Philipp,

when creating such an issue, the most important part, IMHO, is to add the author of said patch
I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44 as watcher right from the beginning, before you press

This way you make sure that the author receives a notification e-mail with the complete bug

I've now added pespin to the ticket, but now he'll just get this update without
your original bug report.

If the ticket relates to a known user (here rhizomatica) it also makes sense to add
keith right from the beginning. This way you can prevent him from running into the
same problem again, and he knows there's a known issue with recent osmo-bsc.

Actions #2

Updated by laforge 19 days ago

In general, the OM2000 object model is very different from TS 11.11 OML we're used to,
so it's not a big surprise that not the same events are generated unless somebody explicitly
adds those into the OM2000 code paths.

We should have the osmo-gsm-tester setup with TTCN3 for catching such issues, but
it seems we are consistently overloaded with other tasks before ever getting to fix that.

Actions #3

Updated by pespin 18 days ago

Hi dexter ,
as you mention, I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44 [1] makes the paging code start only when the TRX C0 is actually operative and running. This is done by listening on signal S_NM_RUNNING_CHG, which is a special signal I added in I206d4c7863a77fbab6a600126742a6a6b8fc3614 which in turn only triggers when several TS 12.21 conditions are met for each object type (so far only BB_TRANSC and RCARRIER are implemented, those were the only ones required so far).
The conditions are basically that the object moves from any other state to {operative=Enabled availability=OK adminsitrative=Unlock} (then signal's bool running=true), or back to any other state (then signal's bool running=false). This allows easily enabling/disabling services based on a given TRX being operative or not, as done in [1] for paging, and done in other modules too like ACC or CBCH.

So, in order to fix the issue, somebody knowing the OM2000 internals would need to implement triggering of S_NM_RUNNING_CHG in the OM2000 specific parts (if it's not using the TS 12.21 FSMs).
I don't have any of those BTS at hand afaik, so I'm not able to fix it myself directly. I can have a look at the code and provide some hints or some support debugging if required, or I can somehow get one of those BTS to give it a try.


Actions #4

Updated by dexter 18 days ago

  • Status changed from New to In Progress
Actions #5

Updated by dexter 18 days ago

  • % Done changed from 0 to 30

Hello Pau,

thanks for your input. I think I get now how it works. In bts_trx.c there is a comment "The OM2000 -> 12.21 mapping we do doesn't have separate bb_transc MO" so we should only have a single place where the signals are generated. I am now sending the S_NM_RUNNING_CHG signal from abis_om2000.c. There is a child FSM that controls the TRXs, When the TRX is done the signal is generated. Unfortunately that is too early. It happens while the TRX is still unusable. Sending the signal once more for C0 when the parent FSM is done works, but thats not yet what I want. I will look into this again tomorrow. I think I can fix this.

best regards.

Actions #6

Updated by pespin 18 days ago

Probably the best would be to emulate the BBTRANSC object from within OM200 specific code so that it keeps the same OM state as the RCARRIER object, and send signals for BBTRANSC at the same time they are also sent for RCARRIER.

Bear in mind the usual osmocom nm_sig_cb() functions (eg. in paging.c) waiting for S_NM_RUNNING_CHG listen for both RCARRIER and BBTRANSC objects, since they expect both to be operative in order to start the services. This is actually tested by the function "trx_is_usable(trx)", that's the key function you need to verify returns true at some point for services to be started.

Actions #7

Updated by dexter 16 days ago

  • % Done changed from 30 to 70

I have now fixed the problem, see:

The function trx_is_usable() ignores the bb_transc MO, so we do not need to send the signals. If we decide to emulate the bb_transc MO anyway I think that all we need to do is to add a line to the the
abis_om2000_fsm_becomes_enabled/disabled functions like:

    nm_obj_fsm_becomes_enabled_disabled(trx->bts, &trx->bb_transc, NM_OC_BASEB_TRANSC, true/false);

We also have to set availability/operational struct members in the bb_transc MO as well. I can do that if you think that it is necessary. I would also rework trx_is_usable() then since then it does not need to make a difference for ericsson BTSs anymore.

Actions #8

Updated by pespin 16 days ago

Hi dexter ,
you know better the OM2000 part, letting you decide about it. For me having all lower layers acting the same on NM objects would be preferable, to avoid checking backend specific stuff in different places.
SO I'd vote +1 to updating BBTRANSC in OM2000 to, but as I said I don't know much details regarding OM2000 so letting you decide.

Actions #9

Updated by keith 15 days ago

I wonder does this also fix #5101 ?

Actions #10

Updated by dexter 13 days ago

Hello Keith,

I think yes, #5101 would be fixed if we update the bb BBTRANSC MO accordingly. I will try out to see how well it works.

Best regards.

Actions #11

Updated by dexter 10 days ago

Hello Keith,

the patch that fixes the missing signal is now in master, so paging should now work again. However, we noticed that there are some other signals are also missing, those are not relevant for paging but to ensure compatibility we need to fix those as well.

Best regards.


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)