Project

General

Profile

Feature #3530

merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCH

Added by dexter over 1 year ago. Updated about 1 month ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/06/2018
Due date:
% Done:

0%

Spec Reference:

Description

At the moment measurement indication primitives are handed to the upper layers separately. However, they could also be integrated into the primitives that carry the actual data block to which the measurement belongs. This would make things a lot easier to handle and understand since whenever one gets data from the phy, there must be a measurement report attached to it.

When lookint into l1sap.c we can see that PRIM_INFO_MEAS is sent along in an PRIM_INFO_MEAS. PRIM_INFO_MEAS only carries the measurement indication and the time indication. We may decide to flatten this once the measurement indication is settled.

PRIM_PH_DATA and PRIM_TCH carry data and voice. Thats where we need to integrate the measurement indication.


Related issues

Related to OsmoBTS - Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with dataIn Progress02/21/2018

Related to OsmoBTS - Bug #3803: fix frame number calculation in scheduler_trxResolved02/15/2019

History

#1 Updated by fixeria over 1 year ago

The suggested approach is used in OsmocomBB/L1CTL. Makes sense for me.
But is there any reason/explanation why it was initially implemented in that way?

#2 Updated by laforge over 1 year ago

Hi fixeria,

On Thu, Sep 06, 2018 at 05:21:50PM +0000, fixeria [REDMINE] wrote:

But is there any reason/explanation why it was initially implemented in that way?

Only jolly would be able to answer that. I think initially it may not
have been clear if the measurements will be processed burst-by-burst on
osmo-bts-trx. But as osmo-bts-{sysmo,lc15,octphy} process measurements
per block, it made sense to use this a standard for all BTS models.

To my knowledge, the common code on top of L1SAP never supported
per-burst measurement processing.

#3 Updated by fixeria over 1 year ago

Hi Harald,

per-burst measurement processing

Actually, osmo-bts-trx also produces per-block (i.e. decoded L2 frame) measurements, not per-burst.
The problem is that such measurements are sent separately from the blocks they belong to...

#4 Updated by laforge over 1 year ago

On Fri, Sep 07, 2018 at 08:08:15AM +0000, fixeria [REDMINE] wrote:

per-burst measurement processing

Actually, osmo-bts-trx also produces per-block (i.e. decoded L2 frame) measurements, not per-burst.

yes, I know, it does today. But it may very well have been different in the very early days of osmo-bts,
or at least have been planned differently back then.

#5 Updated by fixeria about 1 year ago

  • Related to Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data added

#6 Updated by dexter about 2 months ago

The main blocker item here was that there were different ways used to calculate the frame number for the measurement indications and payload indications. This turned out to be a bug and is about being fixed. See also #3803. Once we have fixed the frame number calculation, we can move on with the merge.

#7 Updated by dexter about 2 months ago

  • Related to Bug #3803: fix frame number calculation in scheduler_trx added

#8 Updated by dexter about 1 month ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20

I have now investigated the relevant places where changes must be made. I also made sure that scheduler_trx.c now adds the values that are relevant for measuremet. I have commented out the sections that send the info indication up to the higher layers and made a test to confirm that no info indication with measurement data is arriving at higher layers anymore. The next step is to make use of the measurement data in the TCH/DATA indications and to confirm that measurement reports are working as before.

For the various phy based BTSs things are a little bit difficult. I have already checked how things should be changed for osmo-bts-sysmo. For all other phy based BTSs its basically the same, but we have to be very careful not to break anything here as we probably can not test each model manually. Especially osmo-bts-octphy has to be done blindly. However, I am confident that that the phy-based BTSs will not pose much of a problem. Osmo-bts-trx is by far the most complicated candidate.

#9 Updated by dexter about 1 month ago

  • Status changed from In Progress to Rejected
  • % Done changed from 20 to 0

This is a duplicate of #2977, so I reject this one. For updates see #2977 exclusively.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)