Project

General

Profile

Bug #4799

Both TC_meas_res_sign_tchh and TC_meas_res_sign_tchh_toa256 are failing

Added by laforge 18 days ago. Updated 6 days ago.

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

60%

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
FACCH_H-1.jpg View FACCH_H-1.jpg 810 KB fixeria, 10/23/2020 08:05 PM
4314
4323

History

#1 Updated by dexter 18 days ago

  • Status changed from New to In Progress

#2 Updated by dexter 16 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 16 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 16 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 15 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 15 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 11 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 11 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 10 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()

#10 Updated by dexter 8 days ago

I have found out that the remaining reasons why TC_meas_res_sign_tchh_ are failing is a mishandling of the FACCH in sched_lchan_tchh.c. The signalling mode can be seen as a permanent FACCH transmission but without TCH indications (l1sap.c). Since the FACCH is spreaded over 6 bursts the amount of measurement values is halved. In order to correct the amount we could add each measurement we get from a FACCH twice. This is for sure debateable, but it corrects the amount of measurements. See also:

https://gerrit.osmocom.org/c/osmo-bts/+/20840 measurement: count measurements for FACCH/H twice.

For FACCH/F we have the opposite issue. Here it is actually simple to correct the problem. We just make sure that the TCH/F indication that is generated as a replacement for the missing speech block. Since FACCH/F blocks are exactly the same size as speech blocks everything mahctes up again. See also:

https://gerrit.osmocom.org/c/osmo-bts/+/20841 sched_lchan_tchf: count measurements for FACCH/F only once

In order to have a testbed for the FACCH debugging I have added tests that open the channel in speech mode while ocassionally injecting FACCH blocks. For TCH/F everything looks fine here, but even when the test passes for TCH/H it still looks very messy from inside of osmo-bts. Unfortunately there is no easy way to check if osmo-bts gets the right amount of upling measurements. A rate counter that is quieried from TTCN3 might help here.

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20839 BTS_Tests: add FAACH to TC_meas_res_speech_tchX

So far now all tests should pass, even when I am not happy with the result. I have studied the specs and the FACCH behavior of osmo-bts but unfortunately I can not align the theory with the actual implementation. This was also the case when I was doing the AMR DTX implementation. However, here is the theory I currently know:


=============
== FACCH/F ==
=============

FACCH = F
SACCH = S

          1         2         3         4         5         6         7         8         9         0
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
            v            v            v            v            v            v            v            v

MEASUREMENT REPORTING TCH/F TS1 (SIGNALLING)
------------||------------------------------------------------------------------------------------------
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
FFFFFFFFFFFFIFFFFFFFFFFFFSFFFFFFFFFFFFIFFFFFFFFFFFFSFFFFFFFFFFFFIFFFFFFFFFFFFSFFFFFFFFFFFFIFFFFFFFFFFFFS
M   M   M    M   M   M   MM   M   M    M   M   M    M   M   M    M   M   M    M   M   M    M   M   M    

MEASUREMENT REPORTING TCH/F TS1 (SPEECH)
------------||------------------------------------------------------------------------------------------
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
TTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTS
M   M   M    M   M   M   MM   M   M    M   M   M    M   M   M    M   M   M    M   M   M    M   M   M    

Possible slots to transmit a FACCH (same as for TCH)
M-------M--- ----M------- M-------M--- ----M------- M-------M--- ----M------- M-------M--- ----M-------
----M------- M-------M--- ----M------- M-------M--- ----M------- M-------M--- ----M------- M-------M---

EXAMPLE: FACCH/F

------------||------------------------------------------------------------------------------------------
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
TTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTFFFFIFFFFTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTS
M   M   M    M   M   M   MM   M   M    M   M   M    M   M   M    M   M   M    M   M   M    M   M   M

                  (FACCH)
                                  M        M
                       ...TTTTTTTTFFFFIFFFFTTTTTTTT...
                           ...TTTTTTTTITTTTTTTT...
                              M        M              
                       Note: The FACCH transmission is fully symmetric, which means
                     that one FACCH frame exactly replaces one voice frame.
                 The number of blocks and measurement results generated
                 for the higher layers remains constant.

=============
== FACCH/H ==
=============

FACCH = F for subchannel 0
FACCH = f for subchannel 1
SACCH = S

          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 (SIGNALLING)
---------------------------------------------------||---------------------------------------------------
FfFfFfFfFfFfSFfFfFfFfFfFfsFfFfFfFfFfFfSFfFfFfFfFfFfsFfFfFfFfFfFfSFfFfFfFfFfFfsFfFfFfFfFfFfSFfFfFfFfFfFfs
M       M        M        M       M        M        M       M   M    M        M       M        M      

MEASUREMENT REPORTING TCH/H TS4/TS5.0 (SPEECH)
---------------------------------------------------||---------------------------------------------------
TtTtTtTtTtTtSTtTtTtTtTtTtsTtTtTtTtTtTtSTtTtTtTtTtTtsTtTtTtTtTtTtSTtTtTtTtTtTtsTtTtTtTtTtTtSTtTtTtTtTtTts
M   M   M    M   M   M    M   M   M    M   M   M    M   M   M   MM   M   M    M   M   M    M   M   M

Possible slots to transmit a FACCH on subchannel 0
M - - - - -      M - - -  - -     M -  - - - -      M - - - - -      M - - -  - -     M -  - - - -
- -     M -  - - - -      M - - - - -      M - - -  - -     M -  - - - -      M - - - - -      M - - -

Possible slots to transmit a FACCH on subchannel 1
 M - - - - -      M - - -  - -     M -  - - - -      M - - - - -      M - - -  - -     M -  - - - -
 - -     M -  - - - -      M - - - - -      M - - -  - -     M -  - - - -      M - - - - -      M - - -

EXAMPLE: FACCH/H on SS0
MEASUREMENT REPORTING TCH/H TS4/TS5.0 (TRAFFIC)
---------------------------------------------------||---------------------------------------------------
TtTtTtTtTtTtSTtTtFtFtFtFtsFtFtTtTtTtTtSTtTtTtTtTtTtsTtTtTtTtTtTtSTtTtTtTtTtTtsTtTtTtTtTtTtSTtTtTtTtTtTts
M   M   M    M   M        M   M   M    M   M   M    M   M   M   MM   M   M    M   M   M    M   M   M

             (FACCH)         
        M        M            M
     ...T T  T T F F F F  T T T T...
          ...T T T T F F  F F T T T T...
             M            M       M
     (measurement values positioned by frame number)

     Note: The FACCH gets the same bandwith (8 half bursts) as in TCH/F, in the
           middle of the transmission the bandwith doubles so only 6 bursts are
       needed. In this scheme, the FACCH replaces two TCH/H speech frames,
       which also means that one block less is generated for higher layers.
       This eventually leads also to one measurement result less.

               m       x        m
     ...T T  T T F F F F  T T T T...
          ...T T T T F F  F F T T T T...
                   m        m       m
     (measurement values positioned by point in time)

What confuses me the most in osmo-bts is that the ongoing_facch flag is set after the FACCH is
generated. I would expect this condition somewehere in between. But maybe I am overlooking
something here.

There also a completely different question that came up: Is it even allowed to replace a SUB frame
with a FACCH?

However, maybe its better to review the patches first to see what makes sense here and how it can
be improved. It would also good to know if the above is correct. (important: the "M" markers
indicate the location of the frame number from the beginning of the frame.)

#11 Updated by fixeria 6 days ago

4323

Hi Philipp,

as promised, I am attaching my old paintings that I used while working on TCH/H support for trxcon. They're quite draftish and inaccurate, but should shed some light on how FACCH/H decoding is done in both osmo-bts-trx and trxcon. The problem is that in osmo-bts-trx we're still sending only one BFI (see step 'f'). An additional BFI needs to be sent (in speech mode) when the buffer contains a complete FACCH/H frame (see steps 'c' or 'd'). This way we keep the frame rate: one frame on each 2nd received burst. I can write a patch quickly.

Kind regards,
Vadim.

#12 Updated by dexter 6 days ago

  • % Done changed from 40 to 60

fixeria and me have discussed some of the problems of the TCH/H and the measurement processing (thanks for the scan of your notes!) We decided not to use the approach proposed in #20840 (count FACCH blocks twice.) We think that measurement.c should detect and handle measurements coming from FACCH.

The patch that prevents measurement (RSSI) values attached to the BFI (fake TCH) indication is still in review:
https://gerrit.osmocom.org/c/osmo-bts/+/20841 sched_lchan_tchf: count measurements for FACCH/F only once

Then there was a small bug in the SUB frame detection logic, which I corrected now:
https://gerrit.osmocom.org/c/osmo-bts/+/20852 measurement: count all blocks as SUB for TCH/F in signalling mode

Since the amount of measuremnt values and sub frames is indeed different depending on the channel mode, I fixed this as well.
https://gerrit.osmocom.org/c/osmo-bts/+/20853 measurement: fix expected number of measurements

Not yet fixed is the problem we have when a FACCH is injected into an TCH/H channel. If this happens, and a sub frame is hit the results get messed up. This is why TC_meas_res_speech_tchh_facch does not yet pass. I still wonder if it is even legal to take out a voice frame for a FACCH frame. I wouln't be surprised if this would be forbidden.

I would now do the following: If a FACCH is received, the two BFI indications will not carry RSSI values and because of this only the FACCH measurement value is in the list. When the measurement logic counts out the measurements it will detect that there were FACCH frames and make sure that this taken into account properly (expect less sub measurements, expect less measurements in total, don't compensate missing measurements.)

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)