Project

General

Profile

Feature #4545

Automatic TTCN3 tests for frequency hopping support in BSC

Added by laforge 2 months ago. Updated 12 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
05/12/2020
Due date:
% Done:

20%

Spec Reference:

Description

We currently have no testing at all whether or not the BSC encodes the various "Channel Description IEs" as expected when frequency hopping is in use.

We know it worked once a decade ago when we first implemented it with Siemens BTS, but that's a long time ago.

tnt recently reported he had frequency hopping active on an Ericsson BTS driven by OsmoBSC, but only signalling up to Location Update, no voice channels in use. Also, that is just a single manual test and not an automatic test.

Let's try to cover this part of the BSC codebase with TTCN-3 tests.

History

#1 Updated by laforge 2 months ago

#2 Updated by fixeria about 1 month ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I did a quick test, and according to Wireshark (OML dialect is set to ip.access), osmo-bsc encodes a malformed ARFCN list in Set Channel Attributes message. At first glance, looks like a wrong endianness problem:

IPA protocol ip.access, type: OML
    DataLen: 27
    Protocol: OML (0xff)
GSM A-bis OML, Radio Channel(00,00,06) Set Channel Attributes 
    Message Discriminator: Formatted O&M (0x80)
    Placement Indicator: Only (0x80)
    Sequence Number: 0x00
    Length Indicator: 9
    FOM Message Type: Set Channel Attributes
        FOM Object Class: Radio Channel (0x03)
        FOM Object Instance BTS: 0
        FOM Object Instance TRX: 0
        FOM Object Instance TS: 6
        FOM Attribute ID: Channel Combination
            FOM Attribute Length: 1
            Channel Combination: SDCCH (0x03)
        FOM Attribute ID: HSN
            FOM Attribute Length: 1
            HSN: 1
        FOM Attribute ID: MAIO
            FOM Attribute Length: 1
            MAIO: 0
        FOM Attribute ID: ARFCN List
            FOM Attribute Length: 2051
            ARFCN: 26371
            ARFCN: 26883
            ARFCN: 27395
            ARFCN: 27968
[Malformed Packet: A-bis OML]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

#3 Updated by fixeria about 1 month ago

At first glance, looks like a wrong endianness problem

Actually, 3GPP TS 12.21 defines coding of 'ARFCN List' as TL16V, where where L16 is the length of V. However, BS-11 treats it as TLV, or rather TCV, where C is the amount of ARFCNs in V. I wrote a fix that makes 'ARFCN List' look good (as per 3GPP TS 12.21) in Wireshark. Unfortunately, I cannot test it against the real hardware, because neither I have a BS-11 nor any Ericsson BTS.

https://gerrit.osmocom.org/c/osmo-bsc/+/18565 abis_nm: fix ARFCN list encoding in Set Channel Attributes

tnt, if you have time, could you please test if it does not break your setup with hopping? Thanks in advance!

#4 Updated by tnt about 1 month ago

Ericsson BTS use OM2k, not OML.
Nokia BTS use their own stuff as well, not standard 12.21 OML either.

I just don't have any BTS using that code.

#5 Updated by fixeria about 1 month ago

Ericsson BTS use OM2k, not OML.

Ah, right. Now I see that osmo-bsc has a separate implementation for OM2k.

Nokia BTS use their own stuff as well, not standard 12.21 OML either.

Yep. And unlike OM2k, its implementation is mixed with generic 12.21 OML :/

Thanks for your feedback!

#6 Updated by fixeria 28 days ago

I just found another problem in osmo-bsc: the length value it indicates in the OML header is shorter than the actual length.
It was not easy to spot, because Wireshark does not warn about the message mismatch, so I wrote a small patch:

https://code.wireshark.org/review/37477 A-bis/OML: check indicated vs actual message length

Among with SET CHANnel ATTRibutes, the following messages are affected:

GSM A-bis OML, Baseband Transceiver(00,00,ff) IPA RSL Connect
    Message Discriminator: Manufacturer specific (0x10)
    Placement Indicator: Only (0x80)
    Sequence Number: 0x00
    Length Indicator: 15
    [Expert Info (Warning/Protocol): Indicated length (10) does not match the actual (24)]
        [Indicated length does not match the actual]
        [Severity level: Warning]
        [Group: Protocol]
    FOM Message Type: IPA RSL Connect
        ...

GSM A-bis OML, Baseband Transceiver(00,00,ff) IPA RSL Connect ACK
    Message Discriminator: Manufacturer specific (0x10)
    Placement Indicator: Only (0x80)
    Sequence Number: 0x00
    Length Indicator: 15
    [Expert Info (Warning/Protocol): Indicated length (10) does not match the actual (24)]
        [Indicated length does not match the actual]
        [Severity level: Warning]
        [Group: Protocol]
    FOM Message Type: IPA RSL Connect ACK
        ...

#7 Updated by fixeria 28 days ago

More affected messages:

GSM A-bis OML, GPRS NSE(00,ff,ff) IPA Set Attributes
    Message Discriminator: Manufacturer specific (0x10)
    Placement Indicator: Only (0x80)
    Sequence Number: 0x00
    Length Indicator: 34
    [Expert Info (Warning/Protocol): Indicated length (34) does not match the actual (48)]
        [Indicated length (34) does not match the actual (48)]
        [Severity level: Warning]
        [Group: Protocol]
    FOM Message Type: IPA Set Attributes
        ...

GSM A-bis OML, GPRS NSE(00,ff,ff) IPA Set Attributes ACK
    Message Discriminator: Manufacturer specific (0x10)
    Placement Indicator: Only (0x80)
    Sequence Number: 0x00
    Length Indicator: 34
    [Expert Info (Warning/Protocol): Indicated length (34) does not match the actual (48)]
        [Indicated length (34) does not match the actual (48)]
        [Severity level: Warning]
        [Group: Protocol]
    FOM Message Type: IPA Set Attributes ACK
        ...

#8 Updated by fixeria 27 days ago

Indicated length (10) does not match the actual (24)]
Indicated length (34) does not match the actual (48)]

Hmm,

// 24 - 10 == 13
// 48 - 34 == 13
sizeof(abis_nm_ipa_magic) == 13;
const char abis_nm_ipa_magic[13] = "com.ipaccess";

so this magic is located between abis_om_hdr and abis_om_fom_hdr.

Given that it's ipaccess specific, I am not sure if its length should be included. I'll leave it as is for now.

#9 Updated by fixeria 27 days ago

  • % Done changed from 10 to 20

I just found another problem in osmo-bsc: the length value it indicates in the OML header is shorter than the actual length.

https://gerrit.osmocom.org/c/osmo-bsc/+/18829 abis_nm: fix length indicator in Set Channel Attributes

#10 Updated by fixeria 13 days ago

3GPP TS 48.058 (version 15.0.0), section 9.3.5 "Channel Identification" states that
the 3GPP TS 44.018 "Mobile Allocation" IE shall for compatibility reasons be included
but empty, i.e. the length shall be zero.

https://code.wireshark.org/review/37575 A-bis/RSL: fix dissection of Mobile Allocation in CHANnel ACTIVation
https://gerrit.osmocom.org/c/osmo-bsc/+/19037 abis_rsl: Mobile Allocation IE in CHANnel ACTIVation shall be empty

#11 Updated by fixeria 12 days ago

As it turns out, OsmoBSC fails to encode RR Channel Assignment for a hopping channel properly. An old Nokia phone rejects this message by sending RR Status (cause=Conditional IE Error). This change makes the phone happy:

https://gerrit.osmocom.org/c/osmo-bsc/+/19063 gsm_04_08_rr: fix hopping parameters in RR Assignment Command

I would never guess this just looking at the specs., because the information about conditional elements is a bit fragmented.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)