https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-09-06T17:21:50ZOpen Source Mobile CommunicationsOsmoBTS - Feature #3530: merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/3530?journal_id=111802018-09-06T17:21:50Zfixeria
<ul></ul><p>The suggested approach is used in OsmocomBB/L1CTL. Makes sense for me.<br />But is there any reason/explanation why it was initially implemented in that way?</p> OsmoBTS - Feature #3530: merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/3530?journal_id=111832018-09-07T07:20:08Zlaforge
<ul></ul><p>Hi fixeria,</p>
<p>On Thu, Sep 06, 2018 at 05:21:50PM +0000, fixeria [REDMINE] wrote:</p>
<blockquote>
<p>But is there any reason/explanation why it was initially implemented in that way?</p>
</blockquote>
<p>Only jolly would be able to answer that. I think initially it may not<br />have been clear if the measurements will be processed burst-by-burst on<br />osmo-bts-trx. But as osmo-bts-{sysmo,lc15,octphy} process measurements<br />per block, it made sense to use this a standard for all BTS models.</p>
<p>To my knowledge, the common code on top of L1SAP never supported<br />per-burst measurement processing.</p> OsmoBTS - Feature #3530: merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/3530?journal_id=111852018-09-07T08:08:15Zfixeria
<ul></ul><p>Hi Harald,</p>
<blockquote>
<p>per-burst measurement processing</p>
</blockquote>
<p>Actually, osmo-bts-trx also produces per-block (i.e. decoded L2 frame) measurements, not per-burst.<br />The problem is that such measurements are sent separately from the blocks they belong to...</p> OsmoBTS - Feature #3530: merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/3530?journal_id=111862018-09-07T08:40:06Zlaforge
<ul></ul><p>On Fri, Sep 07, 2018 at 08:08:15AM +0000, fixeria [REDMINE] wrote:</p>
<blockquote><blockquote>
<p>per-burst measurement processing</p>
</blockquote>
<p>Actually, osmo-bts-trx also produces per-block (i.e. decoded L2 frame) measurements, not per-burst.</p>
</blockquote>
<p>yes, I know, it does today. But it may very well have been different in the very early days of osmo-bts,<br />or at least have been planned differently back then.</p> OsmoBTS - Feature #3530: merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/3530?journal_id=116192018-09-25T20:19:26Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-7 priority-2 priority-default" href="/issues/2977">Feature #2977</a>: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data</i> added</li></ul> OsmoBTS - Feature #3530: merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/3530?journal_id=162362019-10-17T09:18:22Zdexter
<ul></ul><p>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 <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: fix frame number calculation in scheduler_trx (Resolved)" href="https://osmocom.org/issues/3803">#3803</a>. Once we have fixed the frame number calculation, we can move on with the merge.</p> OsmoBTS - Feature #3530: merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/3530?journal_id=162372019-10-17T09:18:45Zdexter
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/3803">Bug #3803</a>: fix frame number calculation in scheduler_trx</i> added</li></ul> OsmoBTS - Feature #3530: merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/3530?journal_id=163232019-10-29T08:26:50Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>20</i></li></ul><p>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.</p>
<p>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.</p> OsmoBTS - Feature #3530: merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/3530?journal_id=163262019-10-29T08:40:40Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Rejected</i></li><li><strong>% Done</strong> changed from <i>20</i> to <i>0</i></li></ul><p>This is a duplicate of <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data (Stalled)" href="https://osmocom.org/issues/2977">#2977</a>, so I reject this one. For updates see <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data (Stalled)" href="https://osmocom.org/issues/2977">#2977</a> exclusively.</p>