Project

General

Profile

Bug #2300

problems processing measurement reports

Added by laforge about 1 year ago. Updated 11 months ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
osmo-bts-sysmo
Target version:
-
Start date:
05/28/2017
Due date:
% Done:

100%

Estimated time:
Spec Reference:

Description

scenario:
  • Using current 201310-nightly builds on a sysmobts-v2 (1002) hardware
  • OsmoBTS 0.4.0.446-e0fb is the osmo-bts version according to 'show version'
  • NITB (non onboard) configured to use tch-h only traffic channels
  • MO-to-MT call between two phones
Problems:
  • no measurement reports seen on Abis towards BSC!
  • osmo-bts floods following messages to the console:
    <0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
    <0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
    <0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
    <0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
    <0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
    <0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
    

I suspect that something was broken with the recent patches changing the exact time when the measurements would be processed. The "no space" strongly indicates that the computation/processing never happens, and thus there's no more space for raw uplink rxlev/rxqual samples.

History

#1 Updated by laforge about 1 year ago

even after committing the fix, please think about how his can be tested in an automatic fashion

I'm thinking about establishing a dedicated radio channel in osmo-gsm-tester and then
  • verifying that measurement reports are received in the expected frequency (e.g. by enabling DMEAS logging and counting the number of reports over time
  • verifying that the uplink rxlev values reported from the BTS are plausible (within a certain specified dBm range configuable by the test case). in coaxial cabled setup, there should be little variance.
  • verifying that the downlink rxlev values are reported by the MS, and are plausible. see above.

#2 Updated by dexter about 1 year ago

  • % Done changed from 0 to 90

The problem is caused by the phy depandant code. The function process_meas_res() (all bts model have a static functions like this in their l1 interface code) in l1_if.c assembles the struct (struct osmo_phsap_prim l1sap) that gets sent to higher layers. The member l1sap.u.info.u.meas_ind.fn is not filled out with a value, so the higher layers will always get fn=0 here. The logic that processes the measurement results in measurement.c expects the frame number to be correctly set. Otherwise it is not possible to decide when a measurement period ends. lchan_meas_check_compute() checks if the measurement is complete and then tags the result as valid, which eventually causes the RSL message to be sent and the buffer reset. If the end is never detected the buffer quickly overruns and the log is flooded with the "no space for uplink measurement" message.

I have put a fix on gerrit for that:
https://gerrit.osmocom.org/2789

When I get the situation correctly, osmo-bts-litecell15 and osmo-bts-trx suffer from the same problem. We should fix that as well. However, I need reliable information how the physical layer is representing the downlink frame number. osmo-bts-sysmo seems have a physical frame number (3 fames delayed). But I do not know how osmo-bts-litecell15 or osmo-bts-trx represents it.

I think automated testing is very important here. Not only for the measurement, there are a lot of things that may fail silently and nobody notices. I would try to avoid to do the analysis in real time. As far as I know, the tester is capturing pcap files anyway. A test module could scan the pcap file for measurement messages afterwards. While we run the test we will execute a certain attenuation profile on the attenuators. This will leave a fingerprint in the measurement report which we can detect afterwards. However, I thing we would have to perform a calibration run for each BTS model to get a fingerprint to work with.

#3 Updated by laforge about 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 90 to 50

please mark tickets "In progress" when they are being worked on.

How was this fix verified/tested? Did you actually see the messages disappear?

I applied your fix, cross-compiled osmo-bts-sysmo and executed it on my sysmoBTS 1002 here.

OsmoBTS> show version 
OsmoBTS 0.4.0.446-e0fb (OsmoBTS).

where "e0fb" is the exact git commit version you introudced as fix.

The result is unfortunately not good:

<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=1) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement
<0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement

#4 Updated by dexter about 1 year ago

For testing I have verified that the error message does not appear in the log. I also checked if the measurement reports are present in the RSL during a call. Unfortunately I did only test with full rate last time. By comparing the modulo values I get from the phy with the values listed in the table I found out that the tables for half rate were off by one. This is now fixed with https://gerrit.osmocom.org/2795

#5 Updated by dexter about 1 year ago

  • % Done changed from 50 to 70

The problem is now fixed for osmo-trx (tested with full and half-rate): https://gerrit.osmocom.org/2813

#6 Updated by dexter about 1 year ago

  • % Done changed from 70 to 90

The problem should now be fixed properly for osmo-bts-sysmo, osmo-bts-trx and osmo-bts-octphy. All three are tested with full and halfrate. I can not make any assumptions so far for osmo-bts-litecell15, this still needs to be tested.

https://gerrit.osmocom.org/#/c/2862/ Revert "measurement: exclude idle channels from uplink measurement" (merged)
https://gerrit.osmocom.org/#/c/2863/ normalize frame number in measurement indication (merged)
https://gerrit.osmocom.org/#/c/2813/ pick de58ab6 osmo-bts-trx: fix missing frame number in MEAS IND (Needs Code-Review)
https://gerrit.osmocom.org/#/c/2861/ pick 49d335d osmo-bts-litecell15: Fix missing frame number in MEAS IND (Needs Code-Review)
https://gerrit.osmocom.org/#/c/2867/ pick cd0afc6 osmo-bts-octphy: normalize frame number in MEAS IND (Needs Code-Review)

#7 Updated by dexter about 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

The problem is now also fixed for litecell. Patches are still in review but the problem can be considered as fixed by now.

#8 Updated by laforge 11 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)