https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-02-23T15:03:19ZOpen Source Mobile CommunicationsOsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=77792018-02-23T15:03:19Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/2975">Bug #2975</a>: OsmoBTS doesn't generate measurement indications in absence of uplink bursts</i> added</li></ul> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=77812018-02-23T15:03:26Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-3 priority-high3 closed" href="/issues/2978">Bug #2978</a>: OsmoBTS rxlev/rxqual SUB computation completely broken [AMR DTX]</i> added</li></ul> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=78292018-02-25T23:03:42Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Note that the recent handover patches for osmo-bsc fix an issue that sounds just like this, in osmo-bsc.<br />see <a class="external" href="http://git.osmocom.org/osmo-bsc/commit?id=83594847a8fa8dee4011000747906f10a09bf652">http://git.osmocom.org/osmo-bsc/commit?id=83594847a8fa8dee4011000747906f10a09bf652</a><br />and maybe <a class="external" href="http://git.osmocom.org/osmo-bsc/commit?id=11e31c706663f586e78b531e401de562a07e0785">http://git.osmocom.org/osmo-bsc/commit?id=11e31c706663f586e78b531e401de562a07e0785</a></p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=78442018-02-26T08:50:10Zlaforge
<ul></ul><p>On Sun, Feb 25, 2018 at 11:03:42PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>Note that the recent handover patches for osmo-bsc fix an issue that sounds just like this, in osmo-bsc.</p>
</blockquote>
<p>Thanks, but I somehow fail to understand how something in OsmoBSC can fix / work around a problem in OsmoBTS?</p>
<p>If bursts from the PHY are missing in OsmoBTS, we fail to generate correct measurement results,<br />i.e. we still report them to the BSC, but the values in there appear valid but are in fact<br />incorrect (they show a too low BER). So the BSC's computations will be off by whatever<br />difference between the real BER and the BER reported by OsmoBSC.</p>
<p>It's not super-critical as in a "sane" setup, we shouldn't be missing any bursts/blocks<br />from the PHY. If we do this, the system running OsmoBTS is most probably overloaded in<br />terms of CPU resources.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=78582018-02-26T13:04:41Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>On Sun, Feb 25, 2018 at 11:03:42PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>Note that the recent handover patches for osmo-bsc fix an issue that sounds just like this, in osmo-bsc.</p>
</blockquote>
<p>Thanks, but I somehow fail to understand how something in OsmoBSC can fix / work around a problem in OsmoBTS?</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>If bursts from the PHY are missing in OsmoBTS, we fail to generate correct measurement results,<br />i.e. we still report them to the BSC, but the values in there appear valid but are in fact<br />incorrect (they show a too low BER). So the BSC's computations will be off by whatever<br />difference between the real BER and the BER reported by OsmoBSC.</p>
</blockquote>
<p>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.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=102332018-07-04T13:00:02Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>dexter</i></li></ul> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=104002018-07-23T10:12:54Zdexter
<ul></ul><p>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.</p>
<p>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.</p>
<p>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?.</p>
<p>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.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=104042018-07-23T12:10:07Zlaforge
<ul></ul><p>Hi dexter,</p>
<p>On Mon, Jul 23, 2018 at 10:12:54AM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>The interface between the bts-specific part and the common part works on blocks, not bursts.</p>
<p>A 26-multiframe has 26 slots. 24 are voice codec frames, one of them is<br />empty (for neighbor measurements), and one is SACCH, leaving 25/4=6.25<br />blocks per 26-multiframe.</p>
<p>The measurement reporting interval is 102 or 104 frames (depending on TCH vs. SDCCH).<br />That's basically 26*4 = 104 (TCH) or 51*2 = 102 (SDCCH).</p>
So during one measurement reporting period on a TCH/F, you will receive
<ul>
<li>4x24 tch bursts (= 24 blocks)</li>
<li>4x1 sacch bursts (= 1 block)<br />i.e. a total of 25 measurements.</li>
</ul>
<p>For TCH/H, you can do the computation yourself if you look at the definition of TCH/H.</p>
<blockquote>
<p>Also as far as I understand the measurement we get from the mobile always covers an interval of frames.</p>
</blockquote>
<p>measurement reports (whether uplink or downlink) always cover a measurement reporting period, which is the<br />102/104 frame period described above.</p>
<blockquote>
<p>How can we conclude 100%BER if we miss measurement frames?.</p>
</blockquote>
<p>hm?</p>
<blockquote>
<p>A missing measurement simply could mean that just the SDCCH frame was missing and the other frames were correct?.</p>
</blockquote>
<p>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?</p>
<blockquote>
<p>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.</p>
</blockquote>
<ul>
<li>we need to make sure the detection of "is a measurement period is<br />done" happens whether or not we received any data from L1, <strong>or</strong><br />somehow ensure we <strong>always</strong> receive a PH-DATA.ind even if no<br />burst/signal was received.</li>
</ul>
<ul>
<li>if we initialize the buffer/array of uplink measurements with 100% BER<br />instead of mem-setting it to zero, <strong>and</strong> use the <strong>specified</strong> number of<br />blocks/measurements (rather than the actually received count) during<br />the average/computation, then the result should be correct</li>
</ul> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=104122018-07-23T16:14:17Zfixeria
<ul><li><strong>Category</strong> set to <i>osmo-bts-trx</i></li></ul><p>It seems to be related to the problem, which most likely is the reason of OS#2700.<br />Pay your attention to this part of the scheduler implementation:</p>
<p><a class="external" href="https://git.osmocom.org/osmo-bts/tree/src/common/scheduler.c#n868">https://git.osmocom.org/osmo-bts/tree/src/common/scheduler.c#n868</a></p>
<p>where we calculate the amount of potentially lost ('elapsed') bursts since the last<br />received one. If the amount X is lower than 10, then we compensate the gap by<br />generating X zero-filled dummy (in this context) bursts before forwarding the<br />currently received one. Otherwise, <strong>we just jump</strong> through the lost bursts,<br />and <strong>ignore the gap</strong>.</p>
<p>In scope of measurements, we usually do calculate AVG, so if some amount<br />of bursts is lost, it wouldn't affect the results...</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=104142018-07-23T16:14:42Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-3 priority-high3 closed" href="/issues/2700">Bug #2700</a>: Odd RTP behavior in case of bad / missing speech frames</i> added</li></ul> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=104212018-07-24T04:50:19Zlaforge
<ul></ul><p>On Mon, Jul 23, 2018 at 04:14:17PM +0000, fixeria [REDMINE] wrote:</p>
<blockquote>
<p>In scope of measurements, we usually do calculate AVG, so if some amount<br />of bursts is lost, it wouldn't affect the results...</p>
</blockquote>
<p>we also do compute the min/max and standard-deviation since some patches I<br />implemented recently.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=107252018-08-11T13:27:40Zlaforge
<ul></ul><p><a class="user active" href="https://osmocom.org/users/15">dexter</a>: 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).</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=107322018-08-13T07:33:33Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><blockquote>
<p>I just re-read that for TCH/H...</p>
</blockquote>
<p>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.</p>
<p>It would be good if you could give me a pointer where you found it.</p>
<p>I am still not sure If I got it right now. Here is what I understand so far:</p>
<pre>
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
</pre>
<p>I fixed the calculation now that it matches the description above. I am currently writing unit-tests to check it.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=107422018-08-13T09:07:47Zfixeria
<ul></ul><p>Hi <a class="user active" href="https://osmocom.org/users/15">dexter</a>,</p>
<blockquote>
<p>Do you mean that a voice frame consists of 2 TDMA frames (a half-block so to say)?<br />I found that in the osmo-bts code but I was unable to confirm this with the spec.</p>
</blockquote>
<p>Please have a look at <a class="external" href="https://osmocom.org/issues/3419">https://osmocom.org/issues/3419</a>, there are some details about TCH/H.</p>
<p>In short, unlike xCCH (BCCH, CCCH, SDCCH, etc.), where an encoded L2 frame occupies the<br />whole 4 bursts, the 'block diagonal' interleaving is used for both TCH/F and TCH/H.</p>
<p>For TCH/F everything is more or less simple:</p>
<ul>
<li>Each TCH/F speech frame occupies 8 bursts, but not all bits: even bits of the first<br />4 bursts, and odd bits from the last 4 bursts. So, each burst carries 57 bits of the<br />current speech frame, and 57 bits of the previous one.</li>
</ul>
<ul>
<li>FACCH/F frame steals (i.e. replaces) one TCH/F speech frame, but being encoded same as given for TCH/F.</li>
</ul>
<ul>
<li>So, every 4th burst you decode either a FCH/F speech, or a FACCH/F frame.</li>
</ul>
<p><img src="http://www.teletopix.org/wp-content/uploads/2013/02/Diagonal-Interleaving-for-Speech-in-gsm.jpg" alt="" /></p>
<p>The world of TCH/H is a bit more complex, in particular that the way of FACCH/H interleaving<br />and mapping is different from TCH/H. Please see the issue I referenced above.</p>
<p>I think the measurements should take into account that we recover a new L2 frame e.g. every 2 bursts<br />(in case of TCH/H speech), but the frame itself was mapped over 4 bursts. So, the measurements for<br />each burst are actual for the last speech frame and the current at the same time.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=107492018-08-13T15:26:35Zdexter
<ul></ul><p>Hello fixeria,</p>
<p>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.</p>
<p>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.</p>
<p>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.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=107502018-08-13T15:42:54Zlaforge
<ul></ul><p>On Mon, Aug 13, 2018 at 03:26:35PM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>In osmo-bts-trx, this averaging is performed below l1sap, as we receive one measurement withe very burst.<br />Above L1SAP, all BTS models are unified.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=107622018-08-14T16:52:26Zdexter
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p>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:</p>
<pre>
=============
== 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
</pre>
<p>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.</p>
<pre>
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)
</pre>
<p>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?</p>
<p>I have updated my branch under pmaier/measurement_13082018</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=107632018-08-14T17:36:43Zlaforge
<ul></ul><p>On Tue, Aug 14, 2018 at 04:52:26PM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>This means that I should get 3 measurements per user in one interval.</p>
</blockquote>
<p>that is my understanding, too.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>this is odd.</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>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.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=107722018-08-16T09:08:27Zdexter
<ul></ul><p>I have now put the change to gerrit so we can do some review: <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bts/+/10476/">https://gerrit.osmocom.org/#/c/osmo-bts/+/10476/</a> However, there are still some open questions. I am confident that the intervals now work, but the computed results are now different of course.</p>
<p>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.</p>
<p>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.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=107752018-08-16T11:30:07Zlaforge
<ul></ul><p>On Thu, Aug 16, 2018 at 09:08:27AM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>That's a good point. Not sure what is "right" here. We simply don't know the timing.</p>
<p>It might make sense to simply exclude those missing bursts from computing the timing<br />min/max/avg. Not sure how easy this is in the current code structure.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=112442018-09-11T07:35:50Zdexter
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>90</i></li></ul><p>I have checked the status on how ta_offs_256bits is currently used in the computation.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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: <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: OsmoBTS doesn't generate measurement indications in absence of uplink bursts (Resolved)" href="https://osmocom.org/issues/2975">#2975</a></p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=123772018-10-25T09:40:10Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-2 priority-default closed" href="/issues/3665">Bug #3665</a>: TTCN3 BTS_Tests last SACCH burst received too late -> wrong fake uplink measurement report</i> added</li></ul> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=125102018-11-05T12:57:31Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=172552020-01-20T11:51:54Zdexter
<ul></ul><p>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.</p>
<p>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.</p> OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignhttps://osmocom.org/issues/2987?journal_id=182522020-05-12T09:56:27Zdexter
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>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.</p>