https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-11-09T09:46:02ZOpen Source Mobile CommunicationsOsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=23772016-11-09T09:46:02Zlaforge
<ul><li><strong>Assignee</strong> set to <i>msuraev</i></li><li><strong>Priority</strong> changed from <i>Low</i> to <i>Normal</i></li></ul> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=29212017-01-23T14:53:52Zmsuraev
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>Ref: 3GPP TS 48.058 § 8.4.8<br />The value range is [-63; 192] but manually setting it to -3 causes wireshark to display 253. That's because gsm_abis_rsl.timing_offset in packet-rsl.c is marked as FT_UINT8. Note: that marking it as FT_INT8 would result in values above 127 displaying incorrectly so I'm not sure if this should be corrected.</p>
<p>According to 3GPP TS 45.010 § 1.2:<br />MS_TO = P - T quantized to the nearest symbol, where T is TA set for MS (can be obtained from lapdm_entity) and P is round trip propagation delay in symbols (shall be somehow set by BTS' L1 to gsm_lchan).</p> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=29422017-01-26T11:10:49Zmsuraev
<ul><li><strong>File</strong> <a href="/attachments/2511">meas_nano.pcapng.gz</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2511/meas_nano.pcapng.gz">meas_nano.pcapng.gz</a> added</li><li><strong>File</strong> <a href="/attachments/2510">meas_sysmo.pcapng.gz</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2510/meas_sysmo.pcapng.gz">meas_sysmo.pcapng.gz</a> added</li><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><p>The implementation which acc_delay and ta_offs_qb to compute ms_to always report -1 or 0 in tests based on sysmobts. When using nanobts the results vary significantly (36-94): see attached files. Note that some measurements are marked as malformed by wireshark so I'm not sure yet if it's a bug in nanobts or in my interpretation of the spec. Also, actual TA sometimes reported as 8 and sometimes 0 with no obvious connection to ms_to.</p> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=29572017-01-27T18:46:35Zmsuraev
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul><p>Current implementation published in gerrit 1699 and 1700.</p> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=33532017-03-13T14:45:03Zmsuraev
<ul><li><strong>% Done</strong> changed from <i>10</i> to <i>20</i></li></ul><p>Gerrit 1699 has been merged, gerrit 1700 is under review. Is there a way to verify that we're sending the right thing besides relying on nanobts?</p> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=33552017-03-13T14:57:42Zlaforge
<ul></ul><p>msuraev wrote:</p>
<blockquote>
<p>Ref: 3GPP TS 48.058 § 8.4.8<br />The value range is [-63; 192] but manually setting it to -3 causes wireshark to display 253. That's because gsm_abis_rsl.timing_offset in packet-rsl.c is marked as FT_UINT8. Note: that marking it as FT_INT8 would result in values above 127 displaying incorrectly so I'm not sure if this should be corrected.</p>
</blockquote>
I don't understand you here:
<ul>
<li>the "RSL MS Timing Offset" IE Value is an uint8_t with range from 0..255</li>
<li>the actual offset (in symbol periods) is computed as that uint8_t field - 63.</li>
</ul>
<p>So a difference of '0' symbol periods offset would be encoded as "IE Value 63, resulting in 63-63 = 0.</p>
<p>I don't really see this reflected in your implementation, as the 'raw/absolute' value from the DSP/PHY is taken 1:1 and put in the RSL IE?</p> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=33562017-03-13T15:06:35Zlaforge
<ul></ul><p>msuraev wrote:</p>
<blockquote>
<p>The implementation which acc_delay and ta_offs_qb to compute ms_to always report -1 or 0 in tests based on sysmobts.</p>
</blockquote>
<p>How did you test? I mean, without a physically large distance between MS and BTS, or the capability to delay the RF signal somehow, how was this tested? If you're next to the BTS, I'm not surprised there's no timing offset ;)</p>
<p>OsmocomBB has the capability to pre-empt or delay its transmissions to fool the BTS about a smaller or larger distance to the BTS. This should make it possible to simulate?</p>
<p>When using nanobts the results vary significantly (36-94): see attached files.</p>
<p>36-63 = -27<br />94-63 = +32</p>
<p>The values are incredibly high, almost as if they're quantized not to symbol periods but a much higher resolution clock? At least they seem to center around the nominal zero value.</p>
<blockquote>
<p>Note that some measurements are marked as malformed by wireshark so I'm not sure yet if it's a bug in nanobts or in my interpretation of the spec. Also, actual TA sometimes reported as 8 and sometimes 0 with no obvious connection to ms_to.</p>
</blockquote>
<p>I wouldn't worry too much about what a nanoBTS or other device does, as long as we are convinced that we're doing what the relevant 3GPP spec says.</p> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=33702017-03-14T14:19:32Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=35412017-04-20T14:32:27Zmsuraev
<ul><li><strong>% Done</strong> changed from <i>20</i> to <i>30</i></li></ul><p>Gerrit 2391 was sent with fixes to displaying MS TO and clarifications related to MS TO vs TO field confusion.</p> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=36802017-04-26T10:48:26Zmsuraev
<ul><li><strong>% Done</strong> changed from <i>30</i> to <i>40</i></li></ul><p>Gerrit 2391 is merged, 1700 is under review.</p> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=37342017-04-27T09:56:46Zmsuraev
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>Resolved</i></li><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>laforge</i></li><li><strong>% Done</strong> changed from <i>40</i> to <i>100</i></li></ul><p>All patches are merged.</p> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=37562017-05-02T18:00:13Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>msuraev</i></li></ul> OsmoBTS - Bug #1574: Include MS TIMING OFFSET in RSL MEASUREMENT RESULThttps://osmocom.org/issues/1574?journal_id=38472017-05-14T11:09:17Zlaforge
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li></ul>