Project

General

Profile

Actions

Feature #4545

closed

Automatic TTCN3 tests for frequency hopping support in BSC

Added by laforge almost 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
05/12/2020
Due date:
% Done:

100%

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.


Checklist

  • RSL CHANnel ACTIVation message
  • RSL IMMEDIATE ASSIGN COMMAND
  • SYSTEM INFORMATION Type 4 (CBCH)
  • ASSIGNMENT COMMAND
  • HANDOVER COMMAND
  • Fix wrong IEs and their order in Handover Command
  • Fix missing Channel Allocation IE in SI4 CBCH Channel Description
  • Fix Mobile Allocation bit-mask composition (wrong bits, padding) added
  • Verify encoding of ARFCN 0 in MA bit-mask
  • Fix encoding of ARFCN 0 in MA bit-mask
Actions #1

Updated by laforge almost 4 years ago

Actions #2

Updated by fixeria almost 4 years 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]
Actions #3

Updated by fixeria almost 4 years 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!

Actions #4

Updated by tnt almost 4 years 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.

Actions #5

Updated by fixeria almost 4 years 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!

Actions #6

Updated by fixeria almost 4 years 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
        ...
Actions #7

Updated by fixeria almost 4 years 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
        ...
Actions #8

Updated by fixeria almost 4 years 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.

Actions #9

Updated by fixeria almost 4 years 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

Actions #10

Updated by fixeria over 3 years 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

Actions #11

Updated by fixeria over 3 years 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.

Actions #12

Updated by fixeria over 3 years ago

  • Status changed from In Progress to Stalled
Actions #13

Updated by fixeria over 3 years ago

  • Status changed from Stalled to In Progress
  • Priority changed from Normal to High
Actions #14

Updated by fixeria over 3 years ago

  • Checklist item RSL CHANnel ACTIVation message added
  • Checklist item RSL IMMEDIATE ASSIGN COMMAND added
  • Checklist item SYSTEM INFORMATION Type 4 (CBCH) added
  • Checklist item ASSIGNMENT COMMAND added
  • Checklist item HANDOVER COMMAND added
Actions #15

Updated by fixeria over 3 years ago

  • Checklist item RSL CHANnel ACTIVation message set to Done
  • Checklist item RSL IMMEDIATE ASSIGN COMMAND set to Done
  • % Done changed from 20 to 60

Please see:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19909 library/RSL_Types: add missing Channel Identification IE
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19910 BSC_Tests/hopping: add TC_fh_params_{chan_activ,imm_ass}

The TC_fh_params_imm_ass uncovers a non-critical problem in osmo-bsc: the Mobile Allocation IE may contain redundant zero-octets.

Actions #16

Updated by fixeria over 3 years ago

  • Checklist item ASSIGNMENT COMMAND set to Done
  • % Done changed from 60 to 70

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19926 BSC_Tests/hopping: add TC_fh_params_assignment_cmd

Actions #17

Updated by fixeria over 3 years ago

  • Checklist item SYSTEM INFORMATION Type 4 (CBCH) set to Done
  • % Done changed from 70 to 80

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19927 BSC_Tests/hopping: add TC_fh_params_si4_cbch

Actions #18

Updated by fixeria over 3 years ago

  • Checklist item HANDOVER COMMAND set to Done
  • % Done changed from 80 to 90

Please see:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19939 library/GSM_RR_Types: add minimalistic HandoverCommand
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19943 BSC_Tests/hopping: add TC_fh_params_handover_cmd

submitted together with a bunch of misc changes and fixes:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19940 BSC_Tests/hopping: fix error message in TC_fh_params_assignment_cmd
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19941 BSC_Tests/hopping: fix bit-mask reduction in f_TC_fh_params_gen_tr_ma()
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19942 BSC_Tests/hopping: make f_vty_{handover,ss_action}() more flexible

Actions #19

Updated by fixeria over 3 years ago

  • Checklist item Fix wrong IEs and their order in Handover Command added
  • Checklist item Fix missing Channel Allocation IE in SI4 CBCH Channel Description added
  • Checklist item Fix Mobile Allocation bit-mask composition (wrong bits, padding) added
  • % Done changed from 90 to 80

The test cases uncover several problems in osmo-bsc, they need to be fixed ASAP.

Actions #20

Updated by fixeria over 3 years ago

  • Checklist item Fix wrong IEs and their order in Handover Command set to Done

This change makes BSC_Tests.TC_fh_params_handover_cmd pass:

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

Actions #21

Updated by fixeria over 3 years ago

  • Checklist item Fix missing Channel Allocation IE in SI4 CBCH Channel Description set to Done

https://gerrit.osmocom.org/c/osmo-bsc/+/19950 SI Type 4: fix missing CBCH Mobile Allocation IE

Actions #22

Updated by fixeria over 3 years ago

  • Checklist item deleted (Fix Mobile Allocation bit-mask composition (wrong bits, padding))
  • % Done changed from 80 to 90

[] Fix Mobile Allocation bit-mask composition (wrong bits, padding) added

Actually, the test case expectations were wrong, see:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19995 BSC_Tests/hopping: fix: do not reduce Mobile Allocation bit-mask

Some test case failures were caused by a bug in TITAN that has been fixed in the recent version:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=566516

I managed to work it around, but we should consider upgrading to 7.1.pl1.

Actions #23

Updated by fixeria over 3 years ago

  • Checklist item Fix Mobile Allocation bit-mask composition (wrong bits, padding) added added
  • Status changed from In Progress to Feedback
  • % Done changed from 90 to 100

I've also fixed a regression caused by Ibc3b73697a1d2c8dbb27274e48f5e5ba21fdd540:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19993 BSC_Tests/hopping: fixup TC_fh_params_si4_cbch: bring CBCH back

and added missing calls to f_shutdown_helper(), so we should not see sporadic DTEs anymore:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19994 BSC_Tests/hopping: call f_shutdown_helper() in all TC_fh_params_*

As soon as we merge the remaining changes, this ticket can be closed.

Actions #24

Updated by fixeria over 3 years ago

  • Checklist item Verify encoding of ARFCN 0 in MA bit-mask added
  • Status changed from Feedback to In Progress

According to 3GPP TS 44.018, table 10.5.2.21.1 "Mobile Allocation information element", in the cell allocation frequency 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 list. We need to make sure that osmo-bsc handles ARFCN 0 as described.

Actions #25

Updated by fixeria over 3 years ago

  • Checklist item Fix Mobile Allocation bit-mask composition (wrong bits, padding) added set to Not done
  • % Done changed from 100 to 80

Some test case failures that need to be investigated:

Mobile Allocation IE does not match (tn := 5): { len := 2, ma := '1111111111000000'B } vs expected: { len := 2, ma := '0101010101000000'B }, fhp := { { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 11, maio := 19, ma := { 4, 8, 12, 16, 20 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 16, maio := 17, ma := { 4, 8, 12, 16, 20, 24, 28, 32, 36, 40 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 5, maio := 63, ma := { 6, 12, 18, 24, 30 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } } }

Expected: 0101010101000000
Received: 1111111111000000

ALL: 04, 06, 08, 12, 16, 18, 20, 24, 28, 30, 32, 36, 40  => len 13 + padding => 16
TS5: xx, 06, xx, 12, xx, 18, xx, 24, xx, 30, xx, xx, xx  => 0101010101000

Mobile Allocation IE does not match (tn := 1): { len := 2, ma := '1100101010000000'B } vs expected: { len := 2, ma := '1011010000100000'B }, fhp := { { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 49, maio := 24, ma := { 3, 6, 9, 12, 0 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 57, maio := 1, ma := { 5, 10, 15, 0 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 23, maio := 33, ma := { 5, 10, 15, 20, 25, 30, 0 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } } }

Expected: 1011010000100000
Received: 1100101010000000

ALL: 03, 05, 06, 09, 10, 12, 15, 20, 25, 30, 00  => len 11 + padding => 16
TS1: 03, xx, 06, 09, xx, 12, xx, xx, xx, xx, 00  => 10110100001

Mobile Allocation IE does not match (tn := 1): { len := 2, ma := '1101011101010000'B } vs expected: { len := 2, ma := '1010111010100010'B }, fhp := { { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 1, maio := 14, ma := { 3, 6, 9, 12, 15, 18, 21, 0 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 27, maio := 7, ma := { 3, 6, 0 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 27, maio := 52, ma := { 4, 8, 12, 16, 20, 24, 28, 32 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } } }

Expected: 1010111010100010
Received: 1101011101010000

ALL: 03, 04, 06, 08, 09, 12, 15, 16, 18, 20, 21, 24, 28, 32, 00  => len 15 + padding => 16
TS1: 03, xx, 06, xx, 09, 12, 15, xx, 18, xx, 21, xx, xx, xx, 00  => 101011101010001
Actions #26

Updated by fixeria over 3 years ago

  • Checklist item Verify encoding of ARFCN 0 in MA bit-mask set to Done

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19996 BSC_Tests/hopping: also verify handling of ARFCN 0 in MA

Mobile Allocation IE does not match (tn := 5): { len := 2, ma := '1010111010100010'B } vs expected: { len := 2, ma := '1010111010100 100'B }, fhp := { { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 26, maio := 48, ma := { 4, 8, 12, 16, 20, 24, 28 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 28, maio := 59, ma := { 4, 8, 12, 16, 20, 24 } }, { en abled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := true, hsn := 2, maio := 58, ma := { 3, 6, 9, 12, 15, 18, 21, 0 } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } }, { enabled := false, hsn := <unbound>, maio := <unbound>, ma := { } } }

Expected: 10101100
Received: 10101001

ALL: 05, 06, 10, 12, 15, 00  => len 6 + padding => 8
TS1: 05, xx, 10, xx, 15, 00  => 101011
Actions #27

Updated by fixeria over 3 years ago

  • Checklist item Fix encoding of ARFCN 0 in MA bit-mask added
  • % Done changed from 80 to 90

https://gerrit.osmocom.org/c/osmo-bsc/+/19998 generate_ma_for_ts(): fix: properly encode ARFCN 0 (corner case)

Actions #28

Updated by fixeria over 3 years ago

  • Checklist item Fix Mobile Allocation bit-mask composition (wrong bits, padding) added set to Done
  • Status changed from In Progress to Feedback
  • % Done changed from 90 to 100

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20108 BSC_Tests/hopping: fix ArfcnList: use GsmArfcn instead of integer
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20109 BSC_Tests/hopping: turn FHParamsTrx into a record, add ARFCN field
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20110 BSC_Tests/hopping: fix: consider ARFCN of the transceiver itself

NEW: PASS BSC_Tests.TC_fh_params_chan_activ
NEW: PASS BSC_Tests.TC_fh_params_imm_ass
NEW: PASS BSC_Tests.TC_fh_params_assignment_cmd
NEW: PASS BSC_Tests.TC_fh_params_handover_cmd
NEW: PASS BSC_Tests.TC_fh_params_si4_cbch

Summary:
  NEW: PASS: 5
Actions #29

Updated by fixeria over 3 years ago

  • Status changed from Feedback to Resolved

Finally, all changes have been merged.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)