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