https://osmocom.org/https://osmocom.org/favicon.ico?16647414092019-06-21T17:36:06ZOpen Source Mobile Communicationslibosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=149442019-06-21T17:36:06Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-4 priority-high2 closed" href="/issues/4066">Bug #4066</a>: osmo-bts: sending BSC an ERROR Indication with "unsolicited UA response" in "sms:sysmo" osmo-gsm-tester test</i> added</li></ul> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=196592020-09-17T15:12:57Zlaforge
<ul><li><strong>Spec Reference</strong> set to <i>TS 48.006 Sec. 8.9</i></li></ul><p>One idea that came up recently was to not use system timers (tied to "real time") in osmo-bts, but to use frame numbers as a time base. So if a LAPDm frame is encoded into bursts of a given frame number, we can then express the "n" milliseconds as frame count and check the uplink frame numbers. Once they exceed the timeout, the timer expires. This way it doesn't really matter how much fn-advance or the like we use: The time-out would always automatically scale with that.</p>
<p>Still, what we would need is to start timers when L1 pulls a L2 frame, which is quite different from the current architecture.</p>
<p>3GPP TS 48.006 Section 8.9 contains some nice tables and explanations on what kind of requirements a "good" T200 setting must fulfill. If it is too short (for our overall processing + propagation delay), we will get plenty of useless retransmissions that reduce our throughput. And if it is too long, we equally loose thorughput as lost frames are detected too late.</p> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=196602020-09-17T15:50:06Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/4487">Bug #4487</a>: revisit fn-advance / rts-advance default settings</i> added</li></ul> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=196622020-09-17T15:57:20Zlaforge
<ul></ul><p>I'm wondering how we can make progress here. Ideally, I would want to make the T200 timers scale automatically as configuration parameters like fn-advance change.</p>
What we would need to understand is the amount of processing delay between the time of
<ol>
<li>Tx Delay: pulling a frame from LAPDm, encoding, interleaving it and sending (the last sample of) its last burst over the Um interface, ideally in terms of when it hits the antenna, but I guess when sending the samples to the SDR driver is good enough</li>
<li>Rx Delay: time between receiving the (first? last? sample of) I/Q samples of the first burst of a frame and sending it into LAPDm.</li>
</ol>
<p>The question is, how to determine those values, ideally at runtime, or at the very least once during start-up, so we can use it to configure the various timers.</p>
<p>The precision doesn't have to be very high, but more in the milli-second domain, as that's the basis for T200. If it simplifies things, we can also normalize it to units of frame durations (4.6ms).</p> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=196632020-09-17T16:00:07Zlaforge
<ul></ul><p>Note: I don't think we really need the separate Rx/Tx delay, but the sum would be sufficient.</p>
<p>Can we learn that sum of rx+tx delay (at least quantized to FN granularity) by comparing the FN received in uplink bursts with the FN we use for generating downlink data (i.e. CLOCK IND plus fn-advance)?</p> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=196642020-09-17T16:34:55Zfixeria
<ul></ul><p>Hi Harald,</p>
<blockquote>
<p>One idea that came up recently was to not use system timers (tied to "real time") in osmo-bts, but to use frame numbers as a time base.</p>
</blockquote>
<p>nice idea!</p>
<blockquote>
<p>Can we learn that sum of rx+tx delay (at least quantized to FN granularity) by comparing the FN received in uplink bursts with the FN we use for generating downlink data (i.e. CLOCK IND plus fn-advance)?</p>
</blockquote>
<p>Yep, for sure we can. I think this is the easiest way.</p> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=210082021-01-30T21:58:51Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=244292022-07-22T06:33:59Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>118</i> to <i>msuraev</i></li><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li></ul> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=254832022-11-20T16:22:23Zmsuraev
<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>10</i></li></ul><p>The spec reference seems wrong. The T200 is discussed in 04.06, for example: "The task set T200 shall be performed at the instant right before transmitting a frame, when the PH-READY-TO-SEND primitive is received from the physical layer."</p>
<p>The timer itself is defined in 3GPP TS 04.06 Sec. 5.8.1</p> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=254982022-11-20T16:51:50Zmsuraev
<ul></ul><p>There's interesting idea which came up during discussion with Vadim: the <code>l1sap_info_time_ind()</code> in BTS gives us constantly updated FN in the Uplink direction which is stored in <code>struct gsm_time</code>. Although T200 is the timer which we set before BTS is sending the frame to L1 to be transmitted on Downlink, we can still re-use the Uplink counter - for us it's a raw tick value so the only thing which matter is the duration (in GSM_TDMA_FN_DURATION_uS steps) between 2 points in time.</p> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=255022022-11-20T17:46:03Zlaforge
<ul></ul><p>44.006 if it was 04.06</p> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=255032022-11-20T17:46:08Zlaforge
<ul></ul><p>Or 24.006</p> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=257102022-12-05T17:06:57Zmsuraev
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=283692023-10-31T09:35:07Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>jolly</i></li></ul> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=284042023-11-01T12:45:56Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-1 priority-lowest closed" href="/issues/5969">Bug #5969</a>: BTS_Tests_LAPDm.TC_ns_seq_error fails</i> added</li></ul> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=284112023-11-02T11:10:22Zjolly
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=284762023-11-13T14:05:42Zjolly
<ul><li><strong>% Done</strong> changed from <i>10</i> to <i>80</i></li></ul><p>Patches are made for frame based LAPDm polling and T200 timer. The patches apply to libosmogsm, as well as libosmoisdn. Another patch applies to osmo-bts, that uses the frame based polling. They are pushed to Gerrit.</p> libosmocore - Bug #4074: LAPD timers completely brokenhttps://osmocom.org/issues/4074?journal_id=287382023-12-04T08:38:28Zjolly
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p>Patches are merged. Still the osmo-bts patch needs to be merged, to use the new LAPDm code.</p>