Bug #5986


PAGING impossible until CCCH LOAD IND is received from the BTS

Added by keith 8 months ago. Updated 8 months ago.

Ericsson BTS
Target version:
Start date:
Due date:
% Done:


Spec Reference:


I noticed this with the RBS unit, that does not seem to be sending CCCH LOAD ind.

At we fully delay all paging requests and log "Paging delayed: waiting for available slots at BTS" until such a LOAD ind has been received.

Maybe this check should be removed/relaxed if the vty param "paging load -1" is set?

Maybe the check for (bts_pag_st->free_chans_need != -1) and the above can be reordered?


Actions #1

Updated by laforge 8 months ago

  • Category set to Ericsson BTS

some related comments from IRC:

21:41 < LaF0rge> whytek: the CCCH LOAD IND may not be supported by RBS6k, or we may no enable it properly 
                 via OM2000 as we don't know how
21:42 < LaF0rge> whytek: for OML according to TS 12.21 (Siemens, ip.acess, osmo, ...) there are OML 
                 attributes for the load indication threshold and load indication period
21:51 < LaF0rge> whytek: I couldn't find anything related to load indications in the information I have on 
21:54 < LaF0rge> whytek: according to 
        it does seem to 
                 support CCCH LOAD IND, though
21:58 < LaF0rge> regarding load-ind-threshold: I think it's likely just set at a very high level (80%) and 
                 we never get those messages until the threshold is hit
22:00 < LaF0rge> whytek: please file an issue about the paging trouble and assign it to pespin, it's likely 
                 that his november 2022 code on paging queue might have impacted the behavior
22:05 < whytek> OK. I did check those threshold/period params on my osmo-bsc config. Still now LOAD IND 
                from the DUG
22:05 < whytek> *no
22:06 < LaF0rge> whytek: we don't know how to tell the BTS the thresholds in case of OM2000
22:06 < LaF0rge> so whatever you configure in osmo-bsc cannot be sent to the BTS and it will use whatever 
                 defaults ericsson may have
22:07 < LaF0rge> dexter just stated in private chat (before going to bed) that he occasionally saw some 
                 paging issues with GPRS, but that just *some* pagings don't appear at the MS.  But maybe 
                 the PCU->BSC->BTS path for paging is differnt than the CS one.
22:12 < whytek> I had also seen "lost" pagings on site with the RBS for CS. b-leg callee MS just not 
                reponding something like 1/10 tries.
22:13 < whytek> I never checked off the air if the paging was actually getting TX'd

Actions #2

Updated by pespin 8 months ago

I think the best solution would be to have an extra timer on RBS bts type in osmo-bsc which triggers every bts->ccch_load_ind_period the same code path as RSL Rx BCCH Load Ind until we know how to enable them.
Maybe even forge the RSL CCCH Load ind from within the timer and call rsl_rx_ccch_load() in it.

/* current load on the CCCH */
static int rsl_rx_ccch_load(struct msgb *msg)
    struct e1inp_sign_link *sign_link = msg->dst;
    struct abis_rsl_dchan_hdr *rslh = msgb_l2(msg);
    struct ccch_signal_data sd;

    sd.bts = sign_link->trx->bts;
    sd.rach_slot_count = UINT16_MAX;
    sd.rach_busy_count = UINT16_MAX;
    sd.rach_access_count = UINT16_MAX;

    switch (rslh->data[0]) {
        sd.pg_buf_space = rslh->data[1] << 8 | rslh->data[2];
        if (is_ipaccess_bts(sign_link->trx->bts) && sd.pg_buf_space == UINT16_MAX) {
            sd.pg_buf_space = paging_estimate_available_slots(sd.bts, sd.bts->ccch_load_ind_period);
        paging_update_buffer_space(sign_link->trx->bts, sd.pg_buf_space);
        osmo_signal_dispatch(SS_CCCH, S_CCCH_PAGING_LOAD, &sd);
Actions #3

Updated by laforge 8 months ago

On Thu, Mar 30, 2023 at 01:46:26PM +0000, pespin wrote:

I think the best solution would be to have an extra timer on RBS bts type in osmo-bsc which triggers every bts->ccch_load_ind_period the same code path as RSL Rx BCCH Load Ind until we know how to enable them.

Note that I would almost bet the load indications are already enabled. From the 3GPP Abis protocol specs it
is clear that the idea was in general to only receive them once the load gets rather critical. We could of
couse test that assumption by spaming a RBS with tons of paging and see if we eventually receive them.

The general idea of the 3GPP specs AFAICT is that the BSC can estimate the number of paging slots roughly baed
on CCCH configuratio and starts sending paging to the BTS. At some point the threshold is reached, and the
load indications are used to fine-tune / throttle the rate of paging until at some point the load is low
enough again to stop sending load indications.

In general, the idea of the specs is to conserve Abis transmission capacity by sending messges only when

So the fact that we expect the load indications even at zero load is hence already somewhat unconventional.

So what I'm trying to say: Rather than an RBS specific exception, I would prefer to see a generic solution
which breaks the assumption that load indications will arrive even at negligable low load.

If you introduce a RBS specific exception now, then I'm sure we will have to revisit the topic next time
somebody uses a Nokia or Siemens BTS, for example.

Actions #4

Updated by pespin 8 months ago

I remember now after looking at the code that we actualyl already implement refilling the credit if no CCCH Load Ind arrives.
See paging.c:

/* If no CCCH Lod Ind is received before this time period, the BTS is considered
 * to have stopped sending CCCH Load Indication, probaby due to being under Load
 * Threshold: */
#define bts_no_ccch_load_ind_timeout_sec(bts) ((bts)->ccch_load_ind_period * 2)

That's controlled by bts->paging.credit_timer, which is armed upon:
1- when TRX0 (C0) becomes available for paging (paging.c nm_sig_cb() with signal==S_NM_RUNNING_CHG):

if (nsd->running) {
        if (trx_is_usable(trx)) {
            LOG_BTS(bts, DPAG, LOGL_INFO, "C0 becomes available for paging\n");
            /* Fill in initial credit */
            load_ind_timeout = bts_no_ccch_load_ind_timeout_sec(bts);
            estimated_slots = paging_estimate_available_slots(bts, load_ind_timeout);
            paging_set_available_slots(bts, estimated_slots);
            /* Start scheduling credit_timer */
                        bts_no_ccch_load_ind_timeout_sec(bts), 0);
            /* work_timer will be started when new paging requests arrive. */

2- Rx CCCH Load Ind (which calls paging_update_buffer_space()):

void paging_update_buffer_space(struct gsm_bts *bts, uint16_t free_slots)
    LOG_BTS(bts, DPAG, LOGL_DEBUG, "Rx CCCH Load Indication from BTS (available_slots %u -> %u)\n",
        bts->paging.available_slots, free_slots);
    paging_set_available_slots(bts, free_slots);
    /* Re-arm credit_timer if needed */
    if (trx_is_usable(bts->c0)) {
                    bts_no_ccch_load_ind_timeout_sec(bts), 0);

Once starting by either 1 or 2 above, the credit_timer keeps rearming itself providing credit (paging_give_credit() is the timer_cb function):

static void paging_give_credit(void *data)
    struct gsm_bts_paging_state *paging_bts_st = data;
    struct gsm_bts *bts = paging_bts_st->bts;
    unsigned int load_ind_timeout = bts_no_ccch_load_ind_timeout_sec(bts);
    uint16_t estimated_slots = paging_estimate_available_slots(bts, load_ind_timeout);
        "Timeout waiting for CCCH Load Indication, assuming BTS is below Load Threshold (available_slots %u -> %u)\n",
        paging_bts_st->available_slots, estimated_slots);
    paging_set_available_slots(bts, estimated_slots);
    osmo_timer_schedule(&bts->paging.credit_timer, load_ind_timeout, 0);

So, if we are not receiving CCCH Load ind, it means the code path "1" (C= becomes available for paging) should be the one triggering the timer. It seems it's not the case here. I think it's due to some abis_om2000 FSMs specific implementation not triggering the required signals (S_NM_RUNNING_CHG with nsd->running=true). dexter I recall you already run into something similar in the past too, in case you can provide feedback or test it.

It would be great to have some pcap with OML+RSL+logs during startup of that BTS.

Actions #5

Updated by dexter 8 months ago

For reference I have done a test with our Ericsson RBS setup (RUS 02 B3 + DUG 20 01). I have had no problems establishing a voice call and the Pagings in the trace look good as well. I also do not see a CCCH LOAD INDICATION. The trace was made with nightly packages from today.

Actions #6

Updated by pespin 8 months ago

dexter apparently you already fixed exactly the problem I described here:

commit 99262fd4477503fe5232ccee86fc376e28958263
Author: Philipp Maier <>
Date:   Fri Jul 29 13:35:09 2022 +0200

    abis_om2000: fix missing signal

    The normal abis nm FSMs are sending S_NM_RUNNING_CHG signals that
    include an object class to notify other entities about state changes.
    This also includes paging.c, which only starts paging services when it
    sees NM_OC_RADIO_CARRIER becoming enabled.

    Change-Id: I305df5b2f962473e33e32484c42a79ff96e53e1a
    Fixes: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
    Related: OS#5634

keith , I think we'll need you to send us a pcap :/

Actions #7

Updated by pespin 8 months ago

  • Assignee changed from pespin to keith
Actions #8

Updated by dexter 8 months ago

I vastly remember there was some paging related problem some time ago. As far as I remember the problem was related to the status of MO objects (paging won't start until everything is ready). Ericsson RBS miss some of the OM objects other BTSs have so we worked around this emulating the missing MO objects so that the FSMs work again. However, I think it would help to have a log from the BSC and a trace from the E1 traffic.

keith Do you use a recent BSC version?


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)