Bug #2987
closedOsmoBTS RxQual/RxLev averaging broken if bursts are missign
Added by laforge about 6 years ago. Updated almost 4 years ago.
100%
Description
The way how the current measurement processing code is implemented, it simply counts the amount of reported measurements during the measurement period and then builds the average.
This misses the fact that there should always be a well-defined number of measurements within each measurement period (SACCH multiframe). If there are any measurements missing, it means that bursts were missing, and hence those missing bursts should be substituted with 100% BER. As a result, we want to report the average bit error over all bursts/blocks, not just over those that we have received on L1SAP.
lower layers may for whatever reason drop bursts/blocks (e.g. CPU overload).
Related issues
Updated by laforge about 6 years ago
- Related to Bug #2975: OsmoBTS doesn't generate measurement indications in absence of uplink bursts added
Updated by laforge about 6 years ago
- Related to Bug #2978: OsmoBTS rxlev/rxqual SUB computation completely broken [AMR DTX] added
Updated by neels about 6 years ago
Note that the recent handover patches for osmo-bsc fix an issue that sounds just like this, in osmo-bsc.
see http://git.osmocom.org/osmo-bsc/commit?id=83594847a8fa8dee4011000747906f10a09bf652
and maybe http://git.osmocom.org/osmo-bsc/commit?id=11e31c706663f586e78b531e401de562a07e0785
Updated by laforge about 6 years ago
On Sun, Feb 25, 2018 at 11:03:42PM +0000, neels [REDMINE] wrote:
Note that the recent handover patches for osmo-bsc fix an issue that sounds just like this, in osmo-bsc.
Thanks, but I somehow fail to understand how something in OsmoBSC can fix / work around a problem in OsmoBTS?
If bursts from the PHY are missing in OsmoBTS, we fail to generate correct measurement results,
i.e. we still report them to the BSC, but the values in there appear valid but are in fact
incorrect (they show a too low BER). So the BSC's computations will be off by whatever
difference between the real BER and the BER reported by OsmoBSC.
It's not super-critical as in a "sane" setup, we shouldn't be missing any bursts/blocks
from the PHY. If we do this, the system running OsmoBTS is most probably overloaded in
terms of CPU resources.
Updated by neels about 6 years ago
laforge wrote:
On Sun, Feb 25, 2018 at 11:03:42PM +0000, neels [REDMINE] wrote:
Note that the recent handover patches for osmo-bsc fix an issue that sounds just like this, in osmo-bsc.
Thanks, but I somehow fail to understand how something in OsmoBSC can fix / work around a problem in OsmoBTS?
Not per se of course, just as a reference how the averaging was broken and fixed in the BSC until recently. Maybe the BTS code has similar errors. All I'm saying is, maybe it helps to compare the BSC patch to the BTS code base.
If bursts from the PHY are missing in OsmoBTS, we fail to generate correct measurement results,
i.e. we still report them to the BSC, but the values in there appear valid but are in fact
incorrect (they show a too low BER). So the BSC's computations will be off by whatever
difference between the real BER and the BER reported by OsmoBSC.
Sounds like it is a similar bug as in BSC, where invalid measurement reports were still counted as N, so that dividing by N later gives a too low average.
Updated by dexter almost 6 years ago
I had now a look at the source code and also did some experiments (USRP was not available, so I used OCTBTS). There are a couple of open questions, which I have difficulties with.
My main problem is to understand how many measurements we do expect at all. For a TCH/F this should be 26 and for a TCH/H we should get 13 (?). However it should be a fixed number, which is always the same for each channel type. My experiments with OCTBTS give me measurement counts of 13, 24, 25, 23. At least during the call when I am on TCH/H i would have expected to see 26 measurements.
Also as far as I understand the measurement we get from the mobile always covers an interval of frames. How can we conclude 100%BER if we miss measurement frames?. A missing measurement simply could mean that just the SDCCH frame was missing and the other frames were correct?.
My idea is as follows: When a measurement period done and the RSL measurement result is computed, then we check how many measurements were collected. If measurements are missing we pad them with 100%BER measurements and proceed with the computation.
Updated by laforge almost 6 years ago
Hi dexter,
On Mon, Jul 23, 2018 at 10:12:54AM +0000, dexter [REDMINE] wrote:
My main problem is to understand how many measurements we do expect at all. For a TCH/F this should be 26 and for a TCH/H we should get 13 (?). However it should be a fixed number, which is always the same for each channel type. My experiments with OCTBTS give me measurement counts of 13, 24, 25, 23. At least during the call when I am on TCH/H i would have expected to see 26 measurements.
The interface between the bts-specific part and the common part works on blocks, not bursts.
A 26-multiframe has 26 slots. 24 are voice codec frames, one of them is
empty (for neighbor measurements), and one is SACCH, leaving 25/4=6.25
blocks per 26-multiframe.
The measurement reporting interval is 102 or 104 frames (depending on TCH vs. SDCCH).
That's basically 26*4 = 104 (TCH) or 51*2 = 102 (SDCCH).
- 4x24 tch bursts (= 24 blocks)
- 4x1 sacch bursts (= 1 block)
i.e. a total of 25 measurements.
For TCH/H, you can do the computation yourself if you look at the definition of TCH/H.
Also as far as I understand the measurement we get from the mobile always covers an interval of frames.
measurement reports (whether uplink or downlink) always cover a measurement reporting period, which is the
102/104 frame period described above.
How can we conclude 100%BER if we miss measurement frames?.
hm?
A missing measurement simply could mean that just the SDCCH frame was missing and the other frames were correct?.
I'm not following you. Are you referring to uplink or downlink measurements? Are you referring to SACCH (/H, /F) or SDCCH as you wrote?
My idea is as follows: When a measurement period done and the RSL measurement result is computed, then we check how many measurements were collected. If measurements are missing we pad them with 100%BER measurements and proceed with the computation.
- we need to make sure the detection of "is a measurement period is
done" happens whether or not we received any data from L1, or
somehow ensure we always receive a PH-DATA.ind even if no
burst/signal was received.
- if we initialize the buffer/array of uplink measurements with 100% BER
instead of mem-setting it to zero, and use the specified number of
blocks/measurements (rather than the actually received count) during
the average/computation, then the result should be correct
Updated by fixeria almost 6 years ago
- Category set to osmo-bts-trx
It seems to be related to the problem, which most likely is the reason of OS#2700.
Pay your attention to this part of the scheduler implementation:
https://git.osmocom.org/osmo-bts/tree/src/common/scheduler.c#n868
where we calculate the amount of potentially lost ('elapsed') bursts since the last
received one. If the amount X is lower than 10, then we compensate the gap by
generating X zero-filled dummy (in this context) bursts before forwarding the
currently received one. Otherwise, we just jump through the lost bursts,
and ignore the gap.
In scope of measurements, we usually do calculate AVG, so if some amount
of bursts is lost, it wouldn't affect the results...
Updated by fixeria almost 6 years ago
- Related to Bug #2700: Odd RTP behavior in case of bad / missing speech frames added
Updated by laforge almost 6 years ago
On Mon, Jul 23, 2018 at 04:14:17PM +0000, fixeria [REDMINE] wrote:
In scope of measurements, we usually do calculate AVG, so if some amount
of bursts is lost, it wouldn't affect the results...
we also do compute the min/max and standard-deviation since some patches I
implemented recently.
Updated by laforge over 5 years ago
dexter: Following up on our conversation on Thursday: I just re-read that for TCH/H, a voice block (codec frame) is produced every two blocks, while a FACCH frame will take four blocks, i.e. silence/drop two voice blocks (codec frame).
Updated by dexter over 5 years ago
- Status changed from New to In Progress
I just re-read that for TCH/H...
Do you mean that a voice frame consists of 2 TDMA frames (a half-block so to say)? I found that in the osmo-bts code but I was unable to confirm this with the spec.
It would be good if you could give me a pointer where you found it.
I am still not sure If I got it right now. Here is what I understand so far:
Timeslot number (TN) TDMA frame number (FN) modulo 104
Half rate, Half rate, Reporting SACCH
Full Rate subch.0 subch.1 period Message block
0 0 and 1 0 to 103 12, 38, 64, 90
1 0 and 1 13 to 12 25, 51, 77, 103
2 2 and 3 26 to 25 38, 64, 90, 12
3 2 and 3 39 to 38 51, 77, 103, 25
4 4 and 5 52 to 51 64, 90, 12, 38
5 4 and 5 65 to 64 77, 103, 25, 51
6 6 and 7 78 to 77 90, 12, 38, 64
7 6 and 7 91 to 90 103, 25, 51, 77
SACCH FN remap table:
25 => 103
38 => 12
51 => 25
64 => 38
77 => 51
90 => 64
103 => 77
12 => 90
Also see 3GPP TS 05.02 Clause 7 Table 1 of 9 (version 8.11.0 Release 1999, page 41)
===========
== TCH/F ==
===========
T = Single traffic channel burst
S = SACCH
I = Idle
M = Measurement report
1
1 2 3 4 5 6 7 8 9 0
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
v v v v v v v v
MEASUREMENT REPORTING TCH/F TS0
interval start interval end
|------------------------------------------------------------------------------------------------------|
TTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTI
M M M MM M M M M M M M M M M M M M M M M M M M M
. A
____________| |___remaps to_
MEASUREMENT REPORTING TCH/F TS1
interval end interval start
------------||------------------------------------------------------------------------------------------
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
. A
______remaps to__________| |
MEASUREMENT REPORTING TCH/F TS2
interval end interval start
-------------------------||-----------------------------------------------------------------------------
TTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTI (verified)
M M M M M M M M M MM M M M M M M M M M M M M M M
A .
|______remaps to__________|
MEASUREMENT REPORTING TCH/F TS3
interval end interval start
--------------------------------------||----------------------------------------------------------------
TTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTS (verified)
M M M M M M M M M M M M MM M M M M M M M M M M M
A .
|______remaps to__________|
MEASUREMENT REPORTING TCH/F TS4
---------------------------------------------------||---------------------------------------------------
TTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTI
M M M M M M M M M M M M M M M MM M M M M M M M M
A .
|______remaps to__________|
MEASUREMENT REPORTING TCH/F TS5
interval end interval start
----------------------------------------------------------------||--------------------------------------
TTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTS
M M M M M M M M M M M M M M M M M M MM M M M M M
A .
|______remaps to__________|
MEASUREMENT REPORTING TCH/F TS6
interval end interval start
-----------------------------------------------------------------------------||-------------------------
TTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTI
M M M M M M M M M M M M M M M M M M M M M MM M M
A .
|______remaps to__________|
MEASUREMENT REPORTING TCH/F TS7
interval end interval start
------------------------------------------------------------------------------------------||------------
TTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTS
M M M M M M M M M M M M M M M M M M M M M M M M M
A .
|______remaps to__________|
* 104 Frames in total (96 TCH Frames)
* 24+1 Measuements in total
* In DTX the following frames must exist: (52,53,54,55) + (56,57,58,59) + SDCCH = 3 Blocks
===========
== TCH/H ==
===========
T = Single traffic channel burst for subchannel 0
t = Single traffic channel burst for subchannel 1
S = SACCH for subchannel 0
s = SACCH for subchannel 1
M = Measurement report for subchannel 0
m = Measurement report for subchannel 1
1
1 2 3 4 5 6 7 8 9 0
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
v v v v v v v v
MEASUREMENT REPORTING TCH/H TS2.0
interval end interval start
-------------------------||-----------------------------------------------------------------------------
TtTtTtTtTtTtSTtTtTtTtTtTtsTtTtTtTtTtTtSTtTtTtTtTtTtsTtTtTtTtTtTtSTtTtTtTtTtTtsTtTtTtTtTtTtSTtTtTtTtTtTts
M M M M M M M M M MM M M M M M M M M M M M M M M
A .
|______remaps to__________|
* In TCH/H a voice block is only half the size (2 frames instead of 4)
* 104 Frames in total (96 TCH Frames => 48 TCH Frames per subchannel)
* 24+1 Measuements in total per subchannel
* In DTX the following frames must exist:
Subchannel 0: (0,2) + (4,6) + (52,54) + (56,58) + SDCC = 5 blocks
Subchannel 1: (14,16) + (18,20) + (66,68) + (70,72) + SDCCH = 5 blocks
I fixed the calculation now that it matches the description above. I am currently writing unit-tests to check it.
Updated by fixeria over 5 years ago
Hi dexter,
Do you mean that a voice frame consists of 2 TDMA frames (a half-block so to say)?
I found that in the osmo-bts code but I was unable to confirm this with the spec.
Please have a look at https://osmocom.org/issues/3419, there are some details about TCH/H.
In short, unlike xCCH (BCCH, CCCH, SDCCH, etc.), where an encoded L2 frame occupies the
whole 4 bursts, the 'block diagonal' interleaving is used for both TCH/F and TCH/H.
For TCH/F everything is more or less simple:
- Each TCH/F speech frame occupies 8 bursts, but not all bits: even bits of the first
4 bursts, and odd bits from the last 4 bursts. So, each burst carries 57 bits of the
current speech frame, and 57 bits of the previous one.
- FACCH/F frame steals (i.e. replaces) one TCH/F speech frame, but being encoded same as given for TCH/F.
- So, every 4th burst you decode either a FCH/F speech, or a FACCH/F frame.
The world of TCH/H is a bit more complex, in particular that the way of FACCH/H interleaving
and mapping is different from TCH/H. Please see the issue I referenced above.
I think the measurements should take into account that we recover a new L2 frame e.g. every 2 bursts
(in case of TCH/H speech), but the frame itself was mapped over 4 bursts. So, the measurements for
each burst are actual for the last speech frame and the current at the same time.
Updated by dexter over 5 years ago
Hello fixeria,
thanks for pointing that out. Now the interleaved block mapping that is described in Also see 3GPP TS 05.02 Clause 7 Table 1 of 9 makes sense to me.
So in a TCH/F every four TDMA frames we finish one voice frame and in TCH/H we finish one every two TDMA frames. Thats exactly what is in scheduler.c of osmo-bts. But I still don't know if this also means that the measurement results come in the same intervals. It would make sense, same amount of measurement points for both channel types, but I am still not sure.
I have pushed my current state to pmaier/measurement_13082018 To me it looks quite right, but I still have to get my head around the STDCCH4/8. I probably should also check if the calculation is right. At the moment I just trust the code that is there.
Updated by laforge over 5 years ago
On Mon, Aug 13, 2018 at 03:26:35PM +0000, dexter [REDMINE] wrote:
But I still don't know if this also means that the measurement results come in the same intervals. It would make sense, same amount of measurement points for both channel types, but I am still not sure.
THe way our L1SAP interface is structured (and the way the sysmobts, lc15, octphy PHYs are structured), you get one (average) measurement over all the bursts comprising one block reported together with the PH-DATA.ind.
In osmo-bts-trx, this averaging is performed below l1sap, as we receive one measurement withe very burst.
Above L1SAP, all BTS models are unified.
Updated by dexter over 5 years ago
- % Done changed from 0 to 50
I am now confident that my understanding of the measurement intervals on TCH/F and TCH/H are correct. However, for SDCCH/4 and SDCCH/8 I am not so sure. This is what I understand so far:
=============
== SDCCH/8 ==
=============
SDCCH = D
SACCH = S
FCCH = F
1
1 2 3 4 5 6 7 8 9 0
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901
SSSSSSSSSSSS DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDSSSSSSSSSSSSSSSS DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDSSSS (channel)
555566667777 000011112222333344445555666677770000111122223333 000011112222333344445555666677774444 (subchannel)
5 6 7 0 1 2 3 4 (Reporting interval end)
* For each subchannel we get measurement reports for 2x SDCCH + 1x SACCH
=============
== SDCCH/4 ==
=============
SDCCH = D
SACCH = S
FCCH = F
1
1 2 3 4 5 6 7 8 9 0
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901
DDDD SSSSSSSS DDDDDDDD DDDDDDDD SSSSSSSS DDDDDDDD DDDD (channel)
3333 22223333 00001111 22223333 00001111 00001111 2222 (subchannel)
2 3 0 1 (Reporting interval end)
* For each subchannel we get measurement reports for 2x SDCCH + 1x SACCH
This means that I should get 3 measurements per user in one interval. When I try it out on osmo-bts this seems to match but I also see intervals that only get back with 2 or even only 1 measurements.
Tue Aug 14 18:02:53 2018 <0007> scheduler.c:877 236473/178/03/37/29 Too many contiguous elapsed fn, dropping 567 Tue Aug 14 18:02:53 2018 <0007> scheduler.c:877 236565/178/17/27/21 Too many contiguous elapsed fn, dropping 512 Tue Aug 14 18:02:53 2018 <0007> scheduler.c:877 236591/178/17/02/47 Too many contiguous elapsed fn, dropping 1341 Tue Aug 14 18:02:53 2018 <0007> scheduler.c:877 236634/178/08/45/38 Too many contiguous elapsed fn, dropping 161 Tue Aug 14 18:02:54 2018 <0007> scheduler.c:877 236668/178/16/28/20 Too many contiguous elapsed fn, dropping 103 Tue Aug 14 18:02:54 2018 <0000> rsl.c:2709 (bts=0,trx=0,ts=0,ss=4) Fwd RLL msg CHAN_RQD from LAPDm to A-bis Tue Aug 14 18:02:54 2018 <0000> rsl.c:2796 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) ss=0 Rx RSL CHAN_ACTIV Tue Aug 14 18:02:54 2018 <0000> rsl.c:1036 (bts=0,trx=0,ts=0,ss=0): rx Channel Activation in state: NONE. Tue Aug 14 18:02:54 2018 <0000> rsl.c:1158 chan_nr=0x20 type=0x00 mode=0x00 Tue Aug 14 18:02:54 2018 <0006> scheduler.c:621 Activating SDCCH/4(0) on trx=0 ts=0 Tue Aug 14 18:02:54 2018 <0006> scheduler.c:621 Activating SACCH/4(0) on trx=0 ts=0 Tue Aug 14 18:02:54 2018 <0006> scheduler.c:670 Set mode 3, 0, handover 0 on SDCCH/4(0) of trx=0 ts=0 Tue Aug 14 18:02:54 2018 <0006> scheduler.c:735 Set a5/0 uplink for SDCCH/4(0) on trx=0 ts=0 Tue Aug 14 18:02:54 2018 <0006> scheduler.c:735 Set a5/0 uplink for SACCH/4(0) on trx=0 ts=0 Tue Aug 14 18:02:54 2018 <0006> scheduler.c:735 Set a5/0 downlink for SDCCH/4(0) on trx=0 ts=0 Tue Aug 14 18:02:54 2018 <0006> scheduler.c:735 Set a5/0 downlink for SACCH/4(0) on trx=0 ts=0 Tue Aug 14 18:02:54 2018 <0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Tue Aug 14 18:02:54 2018 <0000> rsl.c:2739 (bts=0,trx=0,ts=0,ss=0) Rx RSL IMM_ASS_CMD Tue Aug 14 18:02:54 2018 <0007> scheduler.c:877 236685/178/07/45/37 Too many contiguous elapsed fn, dropping 323 Tue Aug 14 18:02:54 2018 <0007> scheduler.c:877 236728/178/24/37/28 Too many contiguous elapsed fn, dropping 60 Tue Aug 14 18:02:54 2018 <0004> l1_if.c:515 236728/178/24/37/28 RX L1 frame (bts=0,trx=0,ts=0,ss=0) fn=236728 chan_nr=0x20 MS pwr=16dBm rssi=-21.0 dBFS ber=0.00% (0/456 bits) L1_ta=0 rqd_ta=0 toa256=20 Tue Aug 14 18:02:54 2018 <0004> measurement.c:297 236728/178/24/37/28 (bts=0,trx=0,ts=0,ss=0) adding measurement (is_sub=1), num_ul_meas=0 Tue Aug 14 18:02:54 2018 <0004> measurement.c:268 (bts=0,trx=0,ts=0,ss=0) meas period end fn:236728, fn_mod:88, status:1, pchan:CCCH+SDCCH4 Tue Aug 14 18:02:54 2018 <0004> measurement.c:481 (bts=0,trx=0,ts=0,ss=0) Calculating measurement results for physical channel:CCCH+SDCCH4 Tue Aug 14 18:02:54 2018 <0004> measurement.c:491 (bts=0,trx=0,ts=0,ss=0) Number of UL measurements (1) is less than expected (3), will add 2 dummy measurements Tue Aug 14 18:02:54 2018 <0004> measurement.c:562 (bts=0,trx=0,ts=0,ss=0) Number of SUB measurements (1) is less than expected (3), added 2 dummy SUB measurements Tue Aug 14 18:02:54 2018 <0004> measurement.c:602 (bts=0,trx=0,ts=0,ss=0) Computed TA256( 6) BER-FULL(66.66%), RSSI-FULL(- 79dBm), BER-SUB(66.66%), RSSI-SUB(- 79dBm) Tue Aug 14 18:02:54 2018 <0004> measurement.c:618 (bts=0,trx=0,ts=0,ss=0) UL MEAS RXLEV_FULL(31), RXLEV_SUB(31),RXQUAL_FULL(7), RXQUAL_SUB(7), num_meas_sub(3), num_ul_meas(3) Tue Aug 14 18:02:54 2018 <0011> lapd_core.c:920 Store content res. (dl=0x7f75f94ba6d8) Tue Aug 14 18:02:54 2018 <0000> rsl.c:2709 (bts=0,trx=0,ts=0,ss=0) Fwd RLL msg EST_IND from LAPDm to A-bis Tue Aug 14 18:02:54 2018 <0007> scheduler.c:877 236779/178/23/37/27 Too many contiguous elapsed fn, dropping 48 Tue Aug 14 18:02:54 2018 <0004> l1_if.c:515 236779/178/23/37/27 RX L1 frame (bts=0,trx=0,ts=0,ss=0) fn=236779 chan_nr=0x20 MS pwr=16dBm rssi=-21.0 dBFS ber=0.00% (0/456 bits) L1_ta=0 rqd_ta=0 toa256=21 Tue Aug 14 18:02:54 2018 <0004> measurement.c:297 236779/178/23/37/27 (bts=0,trx=0,ts=0,ss=0) adding measurement (is_sub=1), num_ul_meas=0 Tue Aug 14 18:02:54 2018 <0007> scheduler.c:877 236799/178/17/06/47 Too many contiguous elapsed fn, dropping 17 Tue Aug 14 18:02:54 2018 <0004> l1_if.c:515 236799/178/17/06/47 RX L1 frame (bts=0,trx=0,ts=0,ss=0) fn=236799 chan_nr=0x20 MS pwr=16dBm rssi=-21.0 dBFS ber=0.00% (0/456 bits) L1_ta=0 rqd_ta=0 toa256=20 Tue Aug 14 18:02:54 2018 <0004> measurement.c:297 236799/178/17/06/47 (bts=0,trx=0,ts=0,ss=0) adding measurement (is_sub=1), num_ul_meas=1 Tue Aug 14 18:02:54 2018 <0000> rsl.c:2686 (bts=0,trx=0,ts=0,ss=0) Handing RLL msg UNIT_DATA_IND from LAPDm to MEAS REP Tue Aug 14 18:02:54 2018 <0000> rsl.c:2596 (bts=0,trx=0,ts=0,ss=0) chan_num:32 Tx MEAS RES valid(2), flags(07) Tue Aug 14 18:02:54 2018 <0000> rsl.c:2614 (bts=0,trx=0,ts=0,ss=0) Send Meas RES: NUM:0, RXLEV_FULL:31, RXLEV_SUB:31, RXQUAL_FULL:7, RXQUAL_SUB:7, MS_PWR:56, UL_TA:0, L3_LEN:18, TimingOff:0 Tue Aug 14 18:02:54 2018 <0007> scheduler.c:877 236818/178/10/25/18 Too many contiguous elapsed fn, dropping 16 Tue Aug 14 18:02:54 2018 <0007> scheduler.c:877 236830/178/22/37/30 Too many contiguous elapsed fn, dropping 12 Tue Aug 14 18:02:54 2018 <0007> scheduler.c:877 236830/178/22/37/30 Too many contiguous elapsed fn, dropping 470 Tue Aug 14 18:02:54 2018 <0004> l1_if.c:515 236830/178/22/37/30 RX L1 frame (bts=0,trx=0,ts=0,ss=0) fn=236830 chan_nr=0x20 MS pwr=16dBm rssi=-21.0 dBFS ber=0.00% (0/456 bits) L1_ta=0 rqd_ta=0 toa256=19 Tue Aug 14 18:02:54 2018 <0004> measurement.c:297 236830/178/22/37/30 (bts=0,trx=0,ts=0,ss=0) adding measurement (is_sub=1), num_ul_meas=2 Tue Aug 14 18:02:54 2018 <0004> measurement.c:268 (bts=0,trx=0,ts=0,ss=0) meas period end fn:236830, fn_mod:88, status:1, pchan:CCCH+SDCCH4 Tue Aug 14 18:02:54 2018 <0004> measurement.c:481 (bts=0,trx=0,ts=0,ss=0) Calculating measurement results for physical channel:CCCH+SDCCH4 Tue Aug 14 18:02:54 2018 <0004> measurement.c:500 (bts=0,trx=0,ts=0,ss=0) Number of UL measurements (3) Tue Aug 14 18:02:54 2018 <0004> measurement.c:569 (bts=0,trx=0,ts=0,ss=0) Number of measurements for SUB (3) Tue Aug 14 18:02:54 2018 <0004> measurement.c:602 (bts=0,trx=0,ts=0,ss=0) Computed TA256( 20) BER-FULL( 0.00%), RSSI-FULL(- 21dBm), BER-SUB( 0.00%), RSSI-SUB(- 21dBm) Tue Aug 14 18:02:54 2018 <0004> measurement.c:618 (bts=0,trx=0,ts=0,ss=0) UL MEAS RXLEV_FULL(63), RXLEV_SUB(63),RXQUAL_FULL(0), RXQUAL_SUB(0), num_meas_sub(3), num_ul_meas(3) Tue Aug 14 18:02:55 2018 <0007> scheduler.c:877 236881/178/21/37/29 Too many contiguous elapsed fn, dropping 48 Tue Aug 14 18:02:55 2018 <0004> l1_if.c:515 236881/178/21/37/29 RX L1 frame (bts=0,trx=0,ts=0,ss=0) fn=236881 chan_nr=0x20 MS pwr=16dBm rssi=-22.0 dBFS ber=0.00% (0/456 bits) L1_ta=0 rqd_ta=0 toa256=19 Tue Aug 14 18:02:55 2018 <0004> measurement.c:297 236881/178/21/37/29 (bts=0,trx=0,ts=0,ss=0) adding measurement (is_sub=1), num_ul_meas=0 Tue Aug 14 18:02:55 2018 <0000> rsl.c:2709 (bts=0,trx=0,ts=0,ss=0) Fwd RLL msg DATA_IND from LAPDm to A-bis Tue Aug 14 18:02:55 2018 <0000> rsl.c:2796 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) ss=0 Rx RSL DEACTIVATE_SACCH Tue Aug 14 18:02:55 2018 <0006> scheduler.c:621 Deactivating SACCH/4(0) on trx=0 ts=0 Tue Aug 14 18:02:55 2018 <0007> scheduler.c:877 236901/178/15/06/49 Too many contiguous elapsed fn, dropping 17 Tue Aug 14 18:02:55 2018 <0007> scheduler.c:877 236932/178/20/37/28 Too many contiguous elapsed fn, dropping 28 Tue Aug 14 18:02:55 2018 <0004> l1_if.c:515 236932/178/20/37/28 RX L1 frame (bts=0,trx=0,ts=0,ss=0) fn=236932 chan_nr=0x20 MS pwr=16dBm rssi=-22.0 dBFS ber=0.00% (0/456 bits) L1_ta=0 rqd_ta=0 toa256=19 Tue Aug 14 18:02:55 2018 <0004> measurement.c:297 236932/178/20/37/28 (bts=0,trx=0,ts=0,ss=0) adding measurement (is_sub=1), num_ul_meas=1 Tue Aug 14 18:02:55 2018 <0004> measurement.c:268 (bts=0,trx=0,ts=0,ss=0) meas period end fn:236932, fn_mod:88, status:1, pchan:CCCH+SDCCH4 Tue Aug 14 18:02:55 2018 <0004> measurement.c:481 (bts=0,trx=0,ts=0,ss=0) Calculating measurement results for physical channel:CCCH+SDCCH4 Tue Aug 14 18:02:55 2018 <0004> measurement.c:491 (bts=0,trx=0,ts=0,ss=0) Number of UL measurements (2) is less than expected (3), will add 1 dummy measurements Tue Aug 14 18:02:55 2018 <0004> measurement.c:562 (bts=0,trx=0,ts=0,ss=0) Number of SUB measurements (2) is less than expected (3), added 1 dummy SUB measurements Tue Aug 14 18:02:55 2018 <0004> measurement.c:602 (bts=0,trx=0,ts=0,ss=0) Computed TA256( 12) BER-FULL(33.33%), RSSI-FULL(- 51dBm), BER-SUB(33.33%), RSSI-SUB(- 51dBm) Tue Aug 14 18:02:55 2018 <0004> measurement.c:618 (bts=0,trx=0,ts=0,ss=0) UL MEAS RXLEV_FULL(59), RXLEV_SUB(59),RXQUAL_FULL(7), RXQUAL_SUB(7), num_meas_sub(3), num_ul_meas(3) Tue Aug 14 18:02:55 2018 <0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0x7f75f94ba6d8 state LAPD_STATE_MF_EST)
Are there also some DTX rules to apply to SDCCH channels? I think no, the amount of measurement data would be a bit low. We only have 3 blocks there and reducing it even more seems not to be desirable, but I am not sure. So probably those missing blocks are just lost?
I have updated my branch under pmaier/measurement_13082018
Updated by laforge over 5 years ago
On Tue, Aug 14, 2018 at 04:52:26PM +0000, dexter [REDMINE] wrote:
This means that I should get 3 measurements per user in one interval.
that is my understanding, too.
When I try it out on osmo-bts this seems to match but I also see intervals that only get back with 2 or even only 1 measurements.
this is odd.
Are there also some DTX rules to apply to SDCCH channels? I think no, the amount of measurement data would be a bit low. We only have 3 blocks there and reducing it even more seems not to be desirable, but I am not sure. So probably those missing blocks are just lost?
I think DTX is not permitted on SDCCH. I think this was explicitly mentioned in one of the related 05.02 / 05.03 or so specs.
Updated by dexter over 5 years ago
I have now put the change to gerrit so we can do some review: https://gerrit.osmocom.org/#/c/osmo-bts/+/10476/ However, there are still some open questions. I am confident that the intervals now work, but the computed results are now different of course.
The TOA256 stuff should yield correct results, but I am not sure. I have changed the unit-tests for that a bit so that it gets full measurements. Otherwise the results would look odd and it is probably not a realistic testcase when there are only three measurement samples.
When we miss a measurement sample, we set .ta_offs_256bits = 0. Is this correct? To me it looks like if we were messing up the average with this.
Updated by laforge over 5 years ago
On Thu, Aug 16, 2018 at 09:08:27AM +0000, dexter [REDMINE] wrote:
When we miss a measurement sample, we set .ta_offs_256bits = 0. Is this correct? To me it looks like if we were messing up the average with this.
That's a good point. Not sure what is "right" here. We simply don't know the timing.
It might make sense to simply exclude those missing bursts from computing the timing
min/max/avg. Not sure how easy this is in the current code structure.
Updated by dexter over 5 years ago
- % Done changed from 50 to 90
I have checked the status on how ta_offs_256bits is currently used in the computation.
In measurement.c:lchan_meas_check_compute() one can see that ta256b_sum += m->ta_offs_256bits; is only executed when i < lchan->meas.num_ul_meas. This means only real ta_offs_256bits go into the computation. So from that perspective we should be fine now.
We also decided only to use the m->inv_rssi from the real measurements at some point. The code currently computes ta256b_sum += m->ta_offs_256bits; i < lchan->meas.num_ul_meas. I wonder if this was a good idea since this again messes up the average. If many measurements are missing we still would get a good rssi value. This is probably not right and we should move ta256b_sum += m->ta_offs_256bits; a few lines below that it is executed for all computation rounds.
The computation of ber_full_sum += m->ber10k; looks good. Here we also include the made up measurements with 100% BER. This should give a realistic average. Also the following code if (is_sub)... looks ok to me.
When we are done with the above questions we can close this ticket. There are still problems with the measurement for cases where bursts are missing, but those are handled on another ticket: See also: #2975
Updated by pespin over 5 years ago
- Related to Bug #3665: TTCN3 BTS_Tests last SACCH burst received too late -> wrong fake uplink measurement report added
Updated by dexter over 4 years ago
I have revisited that now. No me the calculation of the measurement results looks ok. I found one bug that might occur when no measurements are in buffer. This is tested by the unit-tests but in reality this should not happen.
I wonder whats left to be done. At the moment on recent osmo-bts-trx/osmo-trx versions we can not loose any SACCH frames, that means the computation is triggered reliably, however we can still loose measurement results from the TCH channels but this would be compensated by the current code.
Updated by dexter almost 4 years ago
- Status changed from Stalled to Resolved
- % Done changed from 90 to 100
We recently upgraded scheduler.c so that nope indications for TCH channels would also trigger the rx_tchf_fn and rx_tchh_fn functions, so we now also can not loose any bursts for TCH channels as well. I think we are good now and we can close this.
