Project

General

Profile

Bug #2975

OsmoBTS doesn't generate measurement indications in absence of uplink bursts

Added by laforge 6 months ago. Updated about 10 hours ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
02/21/2018
Due date:
% Done:

50%

Estimated time:
Spec Reference:

Description

If there are no uplink bursts received (but timestamp indications sent) from OsmoTRX, osmo-bts-trx doesn't appear to generate RSL MEAS REP messages at every SACCH multiframe (103 frames), as expected. Odd.


Related issues

Related to OsmoBTS - Bug #2965: No measurement reports sent for channels other than TCHResolved2018-02-19

Related to OsmoBTS - Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missignIn Progress2018-02-23

History

#1 Updated by laforge 6 months ago

  • Related to Bug #2965: No measurement reports sent for channels other than TCH added

#2 Updated by laforge 6 months ago

The entire measurement computation + reporting process is driven by lchan_meas_check_compute(), which is only called from the l1sap whenever a PRIM_INFO_MEAS is reported up. In absence of bursts/blocks, this primitive is not reported and subsequently no measurement reports are generated.

What we should do instead is track the frame number and whenever the SACCH multiframe ends, we should trigger a RSL MEAS REP. the missing uplink bursts all have to count as erroneous, i.e. 100% bit errors.

The entire dualism of PH_DATA.ind / PH_TCH.ind containg (unsued) measurement data, but then having a separate PRIM_INFO_MEAS is odd to begin with. The measurements should always accompany the PH-DATA.ind / PH-TCH.ind and PRIM_INFO_MEAS should be abandoned.

#3 Updated by laforge 6 months ago

  • Status changed from New to In Progress

#4 Updated by laforge 6 months ago

#5 Updated by laforge 6 months ago

#6 Updated by laforge 6 months ago

  • Related to Bug #2987: OsmoBTS RxQual/RxLev averaging broken if bursts are missign added

#7 Updated by laforge 14 days ago

  • Assignee set to dexter

#8 Updated by dexter 4 days ago

  • % Done changed from 0 to 50

One of the most sensitive parts here is when the SACCH block drops out because then the measurement computation process is not triggered. As we receive measurement indications we need to compare the frame number from the currently received one against the frame number of the previous one in order to check if we already crossed the boundary of a SACCH interval. I have now added a patch that does exactly that. Now a dropout of the SACCH interval will not supress the measurement computation anymore.

See also: https://gerrit.osmocom.org/#/c/osmo-bts/+/10492

However, we are not done yet. When we get a complete dropout with no measurements at all (battery died, tunnel etc...) then we have a problem. For this I would propose to use the time indication to implement a timeout. When lets say a quarter of a SACCH interval has passed without executing the computation/measurement report we could forcefully trigger the computation to generate a report. Unfortunately we are still not good in handling intervals with no measurements so I think its better to wait until that is fixed. See also #2987

#9 Updated by dexter 1 day ago

The patch mentioned above is still in review. I have fixed the review issues now.

I also found out that we not really resetting the measurement states. Since the lchans are statically allocated (i think so, correct me if I am wrong) the states are not reset when the channel is re-opened by another subscriber. I now added a centralized function that resets everything and that is called from rsl.c when the channel is acknowledged.

See also: https://gerrit.osmocom.org/#/c/osmo-bts/+/10554/

#10 Updated by dexter about 10 hours ago

Unfortunately change Gerrit change 10554 causes problems with TTCN3 tests TC_meas_res_sign_sdcch4 and TC_meas_res_sign_sdcch8. The test complains ("No MEAS RES received at all") that there were no measurement reports received but when checking the pcap files one can see that there are indeed measurement reports. Presumably there is (also) a problem with the test expectation.

While trying to fix the problems with the TTCN3 tests I still found some remaining problems that need to be fixed, see also:
https://gerrit.osmocom.org/10564

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)