Feature #3530
closedmerge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCH
0%
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
Updated by fixeria over 5 years 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?
Updated by laforge over 5 years 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.
Updated by fixeria over 5 years 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...
Updated by laforge over 5 years 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.
Updated by fixeria over 5 years ago
- Related to Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data added
Updated by dexter over 4 years 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.
Updated by dexter over 4 years ago
- Related to Bug #3803: fix frame number calculation in scheduler_trx added
Updated by dexter over 4 years 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.