Project

General

Profile

Bug #4799

Both TC_meas_res_sign_tchh and TC_meas_res_sign_tchh_toa256 are failing

Added by laforge 10 days ago. Updated 2 days ago.

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

40%

Spec Reference:

Description

The test verifying measurement results for TCH/H is failing consistently at all time.

MTC@nataraja: Local verdict of PTC TC_meas_res_sign_tchh(6): fail (none -> fail) reason: ""BTS_Tests.ttcn:1945 : Received unspecific MEAS RES { msg_disc := { msg_group := RSL_MDISC_DCHAN (4), transparent := false }, msg_type := RSL_MT_MEAS_RES (40), ies := { { iei := RSL_IE_CHAN_NR (1), body := { chan_nr := { u := { lm := { tag := '0001'B, sub_chan := 0 } }, tn := 5 } } }, { iei := RSL_IE_MEAS_RES_NR (27), body := { meas_res_nr := 1 } }, { iei := RSL_IE_UPLINK_MEAS (25), body := { uplink_meas := { len := 3, rfu := '0'B, dtx_d := false, rxlev_f_u := 10, reserved1 := '00'B, rxlev_s_u := 10, reserved2 := '00'B, rxq_f_u := 7, rxq_s_u := 7, supp_meas_info := omit } } }, { iei := RSL_IE_BS_POWER (4), body := { bs_power := { reserved := 0, epc := false, fpc := false, power_level := 0 } } }, { iei := RSL_IE_L1_INFO (10), body := { l1_info := { ms_power_lvl := 7, fpc := false, reserved := 0, actual_ta := 0 } } }, { iei := RSL_IE_L3_INFO (11), body := { l3_info := { len := 6, payload := '061539390000'O } } }, { iei := RSL_IE_MS_TIMING_OFFSET (37), body := { ms_timing_offset := 65 } } } }"" 

What seems odd is that RxQual=7 for the uplink measurement report generated by the BTS. Note this is not the first measurement report after channel activation, but already the second, where we would normally expect all bursts to arrive with perfect quality.

invalid_channel_mode_IE.png View invalid_channel_mode_IE.png 81.2 KB dexter, 10/14/2020 06:35 PM
4314

History

#1 Updated by dexter 9 days ago

  • Status changed from New to In Progress

#2 Updated by dexter 8 days ago

  • % Done changed from 0 to 20

I think I have now found out what causes the problem. TC_meas_res_sign_tchh activates the TCH/H as signalling channel SDCCH. This seems to change the measurement reporting interval.

To my understanding the measurement interval for SDCCH/SACCH would look like:

                                                                                                    1
          1         2         3         4         5         6         7         8         9         0
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
            v            v            v            v            v            v            v            v
MEASUREMENT REPORTING TCH/H TS4/TS5.0
---------------------------------------------------||---------------------------------------------------
DdDdDdDdDdDdSDdDdDdDdDdDdsDdDdDdDdDdDdSDdDdDdDdDdDdsDdDdDdDdDdDdSDdDdDdDdDdDdsDdDdDdDdDdDdSDdDdDdDdDdDds
M       M        M        M       M        M        M       M   M    M        M       M        M      
                                      A                         .
                                      |______remaps to__________|

From this we can expect 13 measurements instead of 25. Since the number of the measurements is included into the rxqual calculation the we get values that are far of here. This is why the TTCN3 test fails.

Unfortunately I am not sure if this is correct. In GSM 04.03 I find in chapter 6 Channel configurations that SDCCH + SACCH is a valid configuration. So I think technically this is just a FACCH that is permanently present. I assume that allocating an SDCCH on was tested/used (was it?) in real life setups before, so we can be sure that the signalling data that is decoded from here makes sense.

Given that my assumptions are correct I would ajust the expected number of measurements (this number is used to check if measurements are missing and replaces the missing ones => wrong rxqual) to 13 when the channel is in signalling mode (3).

#3 Updated by fixeria 8 days ago

Hi Philipp,

I think I have now found out what causes the problem. TC_meas_res_sign_tchh activates the TCH/H as signalling channel SDCCH.

I am sorry, but this is incorrect. TCH in signalling mode is still a TCH (i.e. traffic channel), not an SDCCH (i.e. dedicated control channel). The only difference from 'speech' mode is that both sides always send FACCH frames instead of speech frames. The multi-frame layout and thus the measurement reporting interval remain the same.

Best regards,
Vadim.

#4 Updated by laforge 8 days ago

Hi Philipp,

On Tue, Oct 13, 2020 at 09:15:55PM +0000, dexter [REDMINE] wrote:

I think I have now found out what causes the problem. TC_meas_res_sign_tchh activates the TCH/H as signalling channel SDCCH.

this is clearly invalid. The TCH/H must be activated as TCH/H in signaling mode, and nothing else.

#5 Updated by dexter 7 days ago

4314

this is clearly invalid. The TCH/H must be activated as TCH/H in signaling mode, and nothing else.

I see, makes also more sense to me. I have fixed that now in the tests:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20645 BTS_Tests: fix CHANnel ACTIVation message in TC_meas_res_sign_tchX

#6 Updated by dexter 7 days ago

The Fix above will not make the test pass. It just fixes the odd CHANnel ACTIVation message. There is a wired problem in osmo-bts-trx for signalling channels the measurement reporting is definetly broken, for normal TCH/H/FACCH+SACCH usage things should be fine, but this seems to be more by chance as the logic around this is not obvious. I can fix this, but I think we need a bit more test coverage. (there is also still #3780)

I wonder if f_TC_meas_res_periodic could be modified so that it tests real TCH/H and not only the signalling case. For sure it is easily possible to activate the channel as TCH/H in GSM V1 speech mode for example but this still does not change the fact that only FACCH (L1CTL_DATA_IND) are sent by the testcase (are they really or is this generated by TRXCON because the testcase does not send any traffic). I would need L1CTL_TRAFFIC_IND to be send to TRXCON which contain GSM V1 voice frames.

There is this f_TC_meas_res_periodic() that uses as_l1_dcch(), I tried to make an as_l1_tch()

private altstep as_l1_tch() runs on ConnHdlr {
    var L1ctlDlMessage l1_dl;
    [] L1CTL.receive(tr_L1CTL_TRAFFIC_IND(g_chan_nr, tr_RslLinkID_DCCH(?))) -> value l1_dl {
        log("TCH received: ", l1_dl.payload.traffic_ind.data);
        var octetstring pl := '010301'O;
        log("=====================> I AM SENDING TO L1CTL:");
        log(ts_L1CTL_TRAFFIC_REQ(g_chan_nr, ts_RslLinkID_DCCH(0),
            f_pad_oct(pl, 23, '2B'O)));

        L1CTL.send(ts_L1CTL_TRAFFIC_REQ(g_chan_nr, ts_RslLinkID_DCCH(0),
            f_pad_oct(pl, 23, '2B'O)));
        repeat;
        }
}
<pre>

But that did not work, which might be because there is never an tr_L1CTL_TRAFFIC_IND comming from TRXCON, shouldn't I receive something as soon as the channel is activated?

#7 Updated by fixeria 3 days ago

Hi Philipp,

The Fix above will not make the test pass. It just fixes the odd CHANnel ACTIVation message.

I am wondering whether this 'Channel Rate and Type' IE is even considered in osmo-bts...

There is a wired problem in osmo-bts-trx for signalling channels the measurement reporting is definetly broken, for normal TCH/H/FACCH+SACCH usage things should be fine,

For measurement reporting on TCH/F or TCH/H there is no difference whether the channel is activated in signalling or in traffic mode - TCH is a separate channel, SACCH is a separate channel. Why do you think it should be fine for traffic?

I wonder if f_TC_meas_res_periodic could be modified so that it tests real TCH/H and not only the signalling case.

I don't think the 'traffic' mode would change anything (see above).

[] L1CTL.receive(tr_L1CTL_TRAFFIC_IND(g_chan_nr, tr_RslLinkID_DCCH(?))) -> value l1_dl
[...] shouldn't I receive something as soon as the channel is activated?

The problem is that you're not sending any RTP frames to the BTS, so you should see lots of:

DL1P INFO sched_lchan_tchf.c:539 001477/01/21/49/41 (bts=0,trx=0,ts=1) TCH/F: No TCH or FACCH prim for transmit.
DL1P INFO sched_lchan_tchf.c:539 001482/01/00/03/46 (bts=0,trx=0,ts=1) TCH/F: No TCH or FACCH prim for transmit.
DL1P INFO sched_lchan_tchf.c:539 001486/01/04/07/50 (bts=0,trx=0,ts=1) TCH/F: No TCH or FACCH prim for transmit.
DL1P INFO sched_lchan_tchf.c:539 001490/01/08/11/02 (bts=0,trx=0,ts=1) TCH/F: No TCH or FACCH prim for transmit.

Most likely, it's just sending dummy bursts (I would expect BFIs instead?), so trxcon fails to decode TCH/F blocks:

20201019024408686 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1788 for TCH/F
20201019024408704 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1792 for TCH/F
20201019024408727 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1797 for TCH/F
20201019024408746 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1801 for TCH/F
20201019024408764 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1805 for TCH/F
20201019024408787 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1810 for TCH/F
20201019024408806 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1814 for TCH/F
20201019024408824 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1818 for TCH/F
20201019024408847 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1823 for TCH/F
20201019024408866 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1827 for TCH/F
20201019024408884 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1831 for TCH/F

Best regards,
Vadim.

#8 Updated by fixeria 3 days ago

  • % Done changed from 30 to 40

Hi Philipp,

The problem is that you're not sending any RTP frames to the BTS, so you should see lots of:

this still applies, but regardless of that trxcon must be sending BFIs to the test case. I did a quick investigation, and found out that the test suite does not send the correct TCH mode to trxcon, so trxcon always works in signalling mode and sends empty DATA.ind (indicating bad xCCCH frames) instead. Moreover, I found out that the 'L1ctlDmEstReq' definition in L1CTL_Types is incorrect:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20753 library/L1CTL_PortType: fix indention in alt() statements [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20754 library/L1CTL_Types: turn L1ctlTchMode into an enumerated type [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20755 library/L1CTL_Types: fix definition of L1ctlDmEstReq [NEW]

I don't think the 'traffic' mode would change anything (see above).

I submitted an incomplete patch set (still need to fix some things):

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20756 BTS_Tests: cosmetic: rename 'as_l1_dcch' to 'as_l1_dcch_loop' [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20757 BTS_Tests: introduce and use TCH loop - as_l1_tch_loop() [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20758 BTS_Tests: introduce TC_meas_res_speech_tch{f,h} [NEW]

and indeed, you were right: both TC_meas_res_speech_tchf and TC_meas_res_speech_tchh pass. I am surprised.
Does it mean that the measurement processing logic in osmo-bts-trx is somehow wrong?

Best regards,
Vadim.

#9 Updated by fixeria 2 days ago

  • Subject changed from TC_meas_res_sign_tchh failing to Both TC_meas_res_sign_tchh and TC_meas_res_sign_tchh_toa256 are failing

I also had a quick look at TC_meas_res_sign_tchh_toa256(), which currently aborts due to a DTE:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20796 BTS_Tests: fix DTE in TC_meas_res_sign_tchh_toa256()

with this patch applied, it still does not pass, but it's 'speech' variant does:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20797 BTS_Tests: introduce TC_meas_res_speech_tchh_toa256()

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)