Project

General

Profile

Feature #1855

provide actual BER or C/I values from osmo-bts-trx into the PCU

Added by laforge over 4 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
osmo-bts-trx
Target version:
Start date:
11/18/2016
Due date:
% Done:

100%

Spec Reference:

Description

see fo rexample 4b76a323b3bb71f8d3f4dc7439ecd9bad0f13bcf which introduces various FIXMEs explaining what's missing.


Related issues

Related to OsmoPCU - Bug #3395: Uplink CS/MCS control is broken osmo-pcu is used with osmo-bts-trx/osmo-trxResolved07/14/2018

Related to OsmoBTS - Bug #1616: osmo-bts-trx / osmo-bts-octphy doesn't provide C/I information to PCU Resolved02/23/2016

Associated revisions

Revision 54e10449 (diff)
Added by Vadim Yanitskiy almost 2 years ago

osmo-bts/scheduler: provide actual C/I values to OsmoPCU

C/I (Carrier-to-Interference ratio) is a value in cB (centiBels),
computed from the training sequence of each received burst,
by comparing the "ideal" training sequence with the actual one.

So far, there was no way to expose more measurements from OsmoTRX,
excluding both RSSI and ToA. Since the new version of TRXD header,
we can receive C/I indications and send the averaged (per 4 bursts)
values to OsmoPCU (as a part of PCUIF_DATA.ind).

Please note that we also need to attach C/I measurements
to the following L1SAP primitives:

- PRIM_PH_RACH.ind,
- PRIM_PH_DATA.ind,
- PRIM_TCH.ind,

but this will be done in the follow up changes.

Change-Id: Ia58043bd2381a4d34d604522e02899ae64ee0d26
Fixes: OS#1855

History

#1 Updated by laforge almost 3 years ago

  • Related to Bug #3395: Uplink CS/MCS control is broken osmo-pcu is used with osmo-bts-trx/osmo-trx added

#2 Updated by laforge over 2 years ago

  • Related to Bug #1616: osmo-bts-trx / osmo-bts-octphy doesn't provide C/I information to PCU added

#3 Updated by laforge over 2 years ago

#4 Updated by laforge over 2 years ago

  • Priority changed from Normal to High

#5 Updated by laforge over 2 years ago

  • Assignee set to tnt

#6 Updated by laforge about 2 years ago

tnt, any news here?

I just re-investigated this topic with Lynxis. The C/I value can be computed from the training sequence of each burst, where we can compare the "ideal" training sequence with the actual training sequence and then express that in dB.

As osmo-trx is already doing the correlation againt the training sequence, it may make sense to do it there. In fact, detectBurst() appears to already return the complex normalized amplitude of the correlation of the training sequence, which is probably almost exactly the value we're interested in here? If this is true, we should probably extend the trx protocol to provide the data to osmo-bts-trx, rather than having osmo-bts-trx do another correlation against the training sequence...

#7 Updated by tnt almost 2 years ago

I got the math worked out that computes a value that might be the C/I ... (at least it seems to have the right properties and it's also in the right range of value).

http://git.osmocom.org/osmo-trx/commit/?h=tnt/ci&id=d40f11962a4d0e2c0ea9e3bde4c568c6c4b62a12

How/Where to actually pass it all the way to the PCU is TBD.

#8 Updated by ipse almost 2 years ago

tnt wrote:

I got the math worked out that computes a value that might be the C/I ... (at least it seems to have the right properties and it's also in the right range of value).

http://git.osmocom.org/osmo-trx/commit/?h=tnt/ci&id=d40f11962a4d0e2c0ea9e3bde4c568c6c4b62a12

How/Where to actually pass it all the way to the PCU is TBD.

Great to finally see some progress here :)

By "right properties" - have you tested increasing interference to check that it's correctly accounted?

Do you have test vectors which could be used as a test case when/if someone decides to write an optimized version of the code?

#9 Updated by tnt almost 2 years ago

I checked that :
- It's independent of scaling (so if you multiply the input vector by any value, it doesn't change the result, except for 'float' precision of course).
- Adding noise tends to decrease the value. I say "tends" because it's all based on only 16 samples ... which doesn't provide much averaging at all, so I ran it through thousands of runs, adding noise to some off the air captures and just looked at the shape of the graph.

#10 Updated by tnt almost 2 years ago

I think it was pespin and fixeria were discussing how to extend the TRX protocol ?
Just ping me when you came up with that extended protocol and where to plug that value ...

#11 Updated by fixeria almost 2 years ago

#12 Updated by fixeria almost 2 years ago

  • Tracker changed from Bug to Feature
  • Status changed from New to In Progress
  • Assignee changed from tnt to fixeria
  • Priority changed from High to Urgent
  • % Done changed from 0 to 80

#13 Updated by fixeria almost 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 80 to 90

I finally wrote a TTCN-3 test case:

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14660/

Waiting for all changes to be merged now...

#14 Updated by fixeria almost 2 years ago

  • % Done changed from 90 to 100

All required changed have been merged. The TTCN-3 test case passes.

P.S. I cannot mark it as resolved for some reason.

#15 Updated by fixeria almost 2 years ago

  • Blocked by deleted (Feature #4006: TRX protocol: wind of change)

#16 Updated by fixeria almost 2 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)