## Bug #2329

### frequent "no space for uplink measurement" message

40%

**Description**

on current osmo-bts master (f4544573f84f2fbfd2f11b4c35274c304c05df4b) with osmo-bts-sysmo backend and TCH/H, I'm getting plenty of the below messages:

<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 <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 <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 <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 <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 <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 <0004> measurement.c:155 (bts=0,trx=0,ts=1,ss=0) no space for uplink measurement

so somehow, the measurement processing is **still** broken, which makes me quite uneasy. We should not be able to introduce such an easy-to-spot regression in the code.

### History

#### #1 Updated by laforge 7 days ago

**% Done**changed from*0*to*40*

On a TCH/H on TS1 SS0, I'm getting L1SAP MEAS IND at the following fn_mod104:

3 11 20 29 37 46 55 63 72 81 89 98

- we compute something like 107 % 104 = 3
- we actually should compute something like (107-4)%104 = 103

In that latter case we end up receiving a L1SAP MEAS IND at the correct fn104 that tchh0_meas_rep_fn104 expects

Not sure where that off-by-four might be coming from. We're generating a L1SAP MEAS IND every time we receive a PH-DATA.ind from the PHY, and we use exacty the frame number we receive from there.

Maybe the frame number in the PH-DATA.ind is the frame number of the last of the 4 bursts? But then, the first burst would be "-3", not "-4".

#### #2 Updated by laforge 7 days ago

what we could do is store the last frame number at which we had received a L1SAP MEAS IND for this lchan, and check if the spec-mentioned modulo value is anywhere in between the last number and the current number. This way it should be portable, no matter what kind of weird offsets there might be applied? Not sure if it's worth the extra uint32_t per each lchan,though

#### #3 Updated by laforge 7 days ago

ok, so the L1 of sysmobts (and lc15) resports the **frame number of the first burst of the block**

*Clause 7 Table 1 of 9: Mapping of logical channels onto physical channels*of TS 05.02 we will see the burst periods for the various blocks at the different channel types. For my example of having a TCH/H on TS1 SS0,

- SACCH is on B(12, 38, 64, 90) MOD 104
- VOICE is on B0, B1, B2 MOD 13, (i.e. repeating 8 times witin the MOD104 above)

so we should get voice on 0, 4, 8, 13+0=13, 13+4=17, 13+8=21, 26+0=26, 26+4=30, 26+8=32, ...

which luckily corresponds to the above-3, i.e. 3-3=0, 7=3=4, ... up to 15-3=12 for the SACCH

#### #4 Updated by laforge 7 days ago

Ok, so the problem is that even if we correct for the offset of 3 (and then get correct fn104 values for e.g. the SACCH/H first burst of 12), when the FACCH is stealing the bursts, there simply is no PH-DATA.ind on fn104=103.

The first burst number for TCH/H (TS1/SS0) are different than those of FACCH/H (TS1/SS0:- SACCH/H: 0, 4, 8, 13+0=13, 13+4=17, 13+8=21, 26+0=26, 26+4=30, 26+8=32, 39+0=39, 39+4=43,39+8=47, 52, 52+4=56, 52+8=60, 65, ...
- FACCH/H: 0, 8, 17, 26+0=26, 26+8=34, 26+17=43, 52+0=52, 52+8=60, 52+17=69, 78+0=78, 78+8=86, 78+17=95

So we definitely need to check for the end of the SACCH measurement period at any frame number, not just those where we by coincidence we actually receive a block whose start framenumber matches that fn104 value from ts 05.08

#### #5 Updated by laforge 7 days ago

actually, a hard one to tackle.

- the measurement period ends at a certain fn104 value
- this fn104 value is not guaranteed to be either the first or the last burst in a block
- our code only gets executed for th first FN in each block and not for intermediate ones
- our code currently has no knowledge about the specific fn104 values of all the bursts for a given block it receives

So actually we would need to determine if any of the bursts of the currently-processed block in the PH-DATA.ind crossed the fn104 boundary of the reporting interval, and then compute + store our measurement results until the next SACCH occurs, when we report the computed resultsto the BSC

Even then' it's not entirely correct, as we don't have the rssi/ber per individual burst, but only per block. So our reporting will inevitably always be granular to the block boundaries.

Now we "only" have to figure out how to compute + use a related table :/

#### #6 Updated by laforge 7 days ago

- frame number of the first burst in the block as reported by PHY
- channel type (facch/f, facch/s, sacch/f, sacch/h, tch/f, tch/h, sdcch, ...)
- timeslot number
- sub-slot number

(i.e. basically lchan + fn)

We should use as much as possible pre-computed tables based on the information in Clause 7 of TS 05.02.

Then, once we know the fn of the last burst, we can do the modulo 104 and compare if that last frame number is >= the mod104 for the end of the measurement period. And that's the trigger for computing the measurement result.