Bug #6191


osmo-pcu from OBS latest feeds transmits Dummy blocks a few more FNs after last TBF in TS was freed

Added by pespin 5 months ago. Updated 2 months ago.

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


Spec Reference:


After new release 1.3.0/1.3.1, it was spotted that the following tests pass in ttcn3-pcu-test (nightly) but not in ttcn3-pcu-test-latest (running1.3.1).


I can reproduce this locally using the docker setup with TC_n3105_max_t3195. Using default IMAGE_SUFFIX=master, the test passes. However, using IMAGE_SUFFIX=latest, the test fails.

This is strange since current master has no real big changes over latest release 1.3.1, only a commit modifying a bit a log message.
In fact, I tried running with IMAGE_SUFFIX=master and OSMO_PCU_BRANCH pointing to commit in 1.3.1, and then it passes too. So that means it has something to do with how osmo-pcu binary in the OBS package was built.

I attach a successful pcap and a failing pcap as reference.

Among other thing, the test expects that after T_3195 times out it should receive an empty dl data block from the PCU because there's no more TBFs active in that TS. This seems to work as expected when running against master or 1.3.1 compiled by the docket container, as seen in the good pcap. After the last DUMMY dl block is sent, one can see how the MS and TBF is freed and hence no more DUMMY dl blocks are sent.

However, when running against the package from OBS ("latest"), one can see that after the TBF and MS is freed, the PCU still submits DUMMY DL DATA blocks for a few (3-4) more FN rounds, which is wrong.

The following patch was submitted in the ttcn3 test to more clearly show the problem: pcu: Fail immediately in TC_n3105_max_t3195

So all in all, it looks like:
1- Bug in the compiler used in OBS
2- Some bug of ours only appeareing when compiled against specific compile flags or compiler version

The logic on whether to submit a DL Dummy block or an empty one, is done in osmo-pcu at gprs_rlcmac_rcv_rts_block():

    /* Prio 3: send dummy control message if need to poll or USF */
    else {
        /* If there's no TBF attached to this PDCH, we can submit an empty
         * data_req since there's nothing to transmit nor to poll/USF. This
         * way we help BTS energy saving (on TRX!=C0) by sending nothing
         * instead of a dummy block. The early return is done here and
         * not at the start of the function because the condition below
         * (num_tbfs==0) may not be enough, because temporary dummy TBFs
         * created to send Imm Ass Rej (see handle_tbf_reject()) don't
         * have a TFI assigned and hence are not attached to the PDCH
         * TS, so they don't show up in the count below.
        const unsigned num_tbfs = pdch->num_tbfs(GPRS_RLCMAC_DL_TBF)
                    + pdch->num_tbfs(GPRS_RLCMAC_UL_TBF);
        bool skip_idle = (num_tbfs == 0);
        /* In DIRECT_PHY mode we want to always submit something to L1 in
         * TRX0, since BTS is not preparing dummy bursts on idle TS for us */
        skip_idle = skip_idle && trx != 0;
        if (!skip_idle && (msg = sched_dummy())) {
            /* increase counter */
            gsmtap_cat = PCU_GSMTAP_C_DL_DUMMY;
        } else {
            msg = NULL; /* submit empty frame */

In theory ENABLE_DIRECT_PHY should not be enabled in the OBS build, so in summary, the dummy message should only be generated based on:

        const unsigned num_tbfs = pdch->num_tbfs(GPRS_RLCMAC_DL_TBF)
                    + pdch->num_tbfs(GPRS_RLCMAC_UL_TBF);
        bool skip_idle = (num_tbfs == 0);
                if (!skip_idle)
                     msg = sched_dummy()



Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)