Cellular Network Infrastructure » Radio Access Network » OsmoBSC

system_information.c:707

    /* Set BA-IND depending on whether we're generating SI2 or SI5.
     * The point here is to be able to correlate whether a given MS
     * measurement report was using the neighbor cells advertised in
     * SI2 or in SI5, as those two could very well be different */
    if (si5)
        chan_list[0] |= 0x10;
    else
        chan_list[0] &= ~0x10;

is any of this relevant?

I see the above, but I don't see encoding of a "Neighbour Cell Description 2" anywhere.
10.5.2.22a.1

Bits 6 and 7 of Octet 2
Multiband reporting
Binary encoding of multiband reporting parameter as specified in 3GPP TS 45.008.
Range: 0 to 3

Also EXT-IND? Where do we set that in the SI2 when we have SI2ter? Seems like it should be set.

Table 10.5.2.22.1: Neighbour Cell Description information element
EXT-IND, Extension indication (octet 2, bit 6)
If received in System Information 2, 2bis, 5 or 5bis this bit indicates whether the information element carries the
complete information of a BCCH channel sub list or whether a complementary information element is sent in
another message.

Hi Keith,

can you attach a pcap?

keith wrote in #note-1:

Bits 6 and 7 of Octet 2
Multiband reporting

Not relevant, 00 is fine. It means report all neigh, regardless of band.

keith wrote in #note-5:

The only thing I note in this sample is that one MS has 3G-BA-USED: 0 and the other has 3G-BA-USED: 1

Actually that's not relevant as I remembered that the phone not reporting 3G-BA-USED doesn't have any 3G RF capabilities on the secondary SIM slot that is being used here, so it makes sense.

Table 10.5.2.20.1: Measurement Results Contents details

Report on GSM cells:

BCCH-FREQ-NCELL i, BCCH carrier of the i'th neighbour cell.
The BCCH-FREQ-NCELL i field is coded as the binary representation of the position, starting with 0, of the
i'th neighbour cells BCCH carrier in the BCCH channel list. The BCCH channel list is composed of one or
two BCCH channel sub lists, each sub list is derived from the set of frequencies defined by reference
neighbour cell description information element or elements. In the latter case the set is the union of the two
sets defined by the two neighbour cell description information elements.

In each BCCH channel sub list the absolute RF channel numbers are placed in increasing order of ARFCN,
except that ARFCN 0, if included in the set, is put in the last position in the sub list. The BCCH channel list
consists either of only the sub list derived from the neighbour cell description information element(s) in
System Information 2/5 (and possible 2bis/5bis) or of that sub list immediately followed by the sub list
derived from the neighbour cell description information element in System Information 2ter /5ter for the case
System Information 2ter/5ter is also received. If the set of ARFCNs defined by the reference neighbour cell
description information element or elements includes frequencies that the mobile station does not support
then these ARFCNs shall be included in the list.
The notation 2/5 etc. means that the rules above apply to the neighbour cell description information elements
received in System Information 2, 2bis and 2ter and to those received in System Information 5, 5bis and 5ter
separately.
Range: 0 to 31/30

So Index 1 should be ARFCN 11, right, as si2ter was received and the list is the concatenation of si2 and si2ter?

That's the way I understand the above.

so

0=>247
1=>11

So I think it's pretty obvious now what the problem is, and this:

bitvec_set_bit_pos(bv, cur_bts->c0->arfcn, 1);

and this:

mrc->arfcn = bitvec_get_nth_set_bit(nbv, mrc->neigh_idx + 1);

will not do.

I'm not sure if we are going to be able to retrieve the index correctly from a bitvec, I don't really understand it.

Thanks for the pcaps and additional information, Keith!

I think you have analyzed this right, the problem is that OsmoBSC uses one bitvec to basically store a list of index -> arfcn and it contains both si2 and si2ter entries.

It seems what we need instead is having two separate bitvecs, one for si2, one for si2ter. Then try to lookup the index in the si2 bitvec first, and if the index exceeds the entries in that list, then look in the si2ter bitvec.

I'll try to come up with a patch.

thanks osmith

just to say it, this is not really something that is in my way as I don't run any multi-band systems, but I noticed it as I wanted to test something that involved two bands.

It was kind of interesting though, and I just figured it might bite somebody some time so better to fix it, but for me, zero urgency, if you have higher priority tasks.