Cellular Network Infrastructure » Radio Access Network » OsmoBSC

this is likely due to one of https://gerrit.osmocom.org/q/topic:%2522amr_startmode%2522+project:osmo-bsc
will fix

hmm, the test expects MR config of

'2b15208820'O

but gets

'2A15208820'O

The ICMI and start mode are in the first octet:

xxxx1x11
    |  \__ start mode bits
   ICMI=1

The test sets start-mode = 4, which translates to startmode bits of 3 = 0b11

So the expected 0xb should be correct.
Need to find out why osmo-bsc apparently flips one of the startmode bits and sends 0xa instead.

Hi Neels,

The test sets start-mode = 4, which translates to startmode bits of 3 = 0b11
Need to find out why osmo-bsc apparently flips one of the startmode bits and sends 0xa instead.

I think I found out why. By default, osmo-bsc has the following configuration:

network
 bts 0
  amr tch-f modes 0 2 4 7
  amr tch-h modes 0 2 4
! Same for bts 1, 2, and 3

so only three AMR modes are available for TCH/H. This is reflected in the MultiRate configuration IE:

    MultiRate configuration
        Element ID: 0x03
        Length: 5
        001. .... = Multirate speech version: Adaptive Multirate speech version 1 (1)
        ...0 .... = NSCB: Noise Suppression Control Bit: Noise Suppression can be used (default) (0)
        .... 1... = ICMI: Initial Codec Mode Indicator: The initial codec mode is defined by the Start Mode field (1)
        .... ..10 = Start Mode: 2
        0... .... = 12,2 kbit/s codec rate: is not part of the subset  <-- (!) This mode is not valid for TCH/H
        .0.. .... = 10,2 kbit/s codec rate: is not part of the subset
        ..0. .... = 7,95 kbit/s codec rate: is not part of the subset
        ...1 .... = 7,40 kbit/s codec rate: is part of the subset
        .... 0... = 6,70 kbit/s codec rate: is not part of the subset
        .... .1.. = 5,90 kbit/s codec rate: is part of the subset
        .... ..0. = 5,15 kbit/s codec rate: is not part of the subset
        .... ...1 = 4,75 kbit/s codec rate: is part of the subset
        ..10 0000 = AMR Threshold: 16.0 dB (32)
        1000 .... = AMR Hysteresis: 4.0 dB (8)
        .... 1000  00.. .... = AMR Threshold: 16.0 dB (32)
        ..10 00.. = AMR Hysteresis: 4.0 dB (8)

so here is an extract from the source code:

static void get_amr_start_from_arg(struct vty *vty, const char *argv[], int full)
{
        struct gsm_bts *bts = vty->index;
        struct amr_multirate_conf *mr = (full) ? &bts->mr_full: &bts->mr_half;
        struct gsm48_multi_rate_conf *mr_conf =
                                (struct gsm48_multi_rate_conf *) mr->gsm48_ie;
        int num = 0, i;

        /* After this calculation, num is 3 */
        for (i = 0; i < ((full) ? 8 : 6); i++) {
                if ((mr->gsm48_ie[1] & (1 << i))) {
                        num++;
                }
        }

        /* argv: { "4" }, so taking false branch */
        if (argv[0][0] == 'a' || num == 0) { 
                mr_conf->icmi = 0; 
                mr_conf->smod = 0; 
        } else {
                mr_conf->icmi = 1;

                /* 3 < 4, so taking true branch */
                if (num < atoi(argv[0]))
                        mr_conf->smod = num - 1; /* <-- (!) this is where 3 - 1 == 2 comes from */
                else
                        mr_conf->smod = atoi(argv[0]) - 1; 
        }
}

This is why the test case does pass for TCH/F, but not for TCH/H. I think the best way would be to correct our expectations?

Best regards,
Vadim.

Please see:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/21931 BSC_Tests: fix expectations in TC_assignment_codec_amr_h_start_mode_4 [NEW]

The test case is passing now:

https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-bsc-test/227/
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1238/