https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092018-05-04T08:38:04ZOpen Source Mobile CommunicationsOsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=91232018-05-04T08:38:04Zfixeria
<ul></ul><p>Hi Harald,</p>
<blockquote>
<p>It seems like if a TCH is activated, trxcon assumes that<br />all bursts/blocks are voice, which is wrong.</p>
</blockquote>
<p>No.</p>
<blockquote>
<p>Some general rules about FACCH handling:<br />...</p>
</blockquote>
<p>Yep, this is how FACCH is implemented in trxcon.</p>
<p>Please have a look:</p>
<p><a class="external" href="https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_trx.c#n89">https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_trx.c#n89</a><br /><a class="external" href="https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_prim.c#n188">https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_prim.c#n188</a><br /><a class="external" href="https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_prim.c#n131">https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_prim.c#n131</a><br /><a class="external" href="https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_trx.h#n292">https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_trx.h#n292</a></p>
<blockquote>
<p>So I'm a bit at a loos how FACCH transmission<br />is supposed to work in trxcon?</p>
</blockquote>
<p>In short, you need to send an L1CTL message of type L1CTL_DATA_REQ<br />with desired 'chan_nr' and 'link_id'. Then the scheduler will itself<br />distinguish between voice frames and data, and prioritize FACCH.</p>
<p>When I have been implementing this, I followed the OsmoBTS approach.<br />But still I observe some strange behaviour, when FACH frames are<br />retransmitted a few times :/</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=91522018-05-04T14:24:45Zlaforge
<ul></ul><p>The problem can be reproduced by running <code>BTS_Tests.TC_rll_est_ind</code> from <code>laforge/bts-rll</code> branch of <code>osmo-ttcn3-hacks.git</code>.</p>
<p>The tests currently have testing TCH/F disabled (due to the bug described here). You'll need the following patch to re-enable it:<br /><pre>
- //valueof(ts_RslChanNr_Bm(1)),
+ valueof(ts_RslChanNr_Bm(1)) //,
</pre></p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=91552018-05-04T14:29:58Zlaforge
<ul><li><strong>File</strong> <a href="/attachments/3099">20180504-TC_rll_est_ind-FACCH.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3099/20180504-TC_rll_est_ind-FACCH.pcapng">20180504-TC_rll_est_ind-FACCH.pcapng</a> added</li><li><strong>File</strong> <a href="/attachments/3100">20180504-TC_rll_est_ind-SDCCH.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3100/20180504-TC_rll_est_ind-SDCCH.pcapng">20180504-TC_rll_est_ind-SDCCH.pcapng</a> added</li><li><strong>File</strong> <a href="/attachments/3101">TC_rll_est_ind-FACCH.log</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3101/TC_rll_est_ind-FACCH.log">TC_rll_est_ind-FACCH.log</a> added</li><li><strong>File</strong> <a href="/attachments/3102">TC_rll_est_ind-SDCCH.log</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3102/TC_rll_est_ind-SDCCH.log">TC_rll_est_ind-SDCCH.log</a> added</li></ul><p>I'm attaching pcap + log files. In the SDCCH case the BTS receives the SABM frames as expected. On FACCH, there are no SABM received by BTS.</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=91622018-05-04T19:36:39Zfixeria
<ul></ul><p>Do the attached logs contain the output of BTS_Tests.TC_rll_est_ind only?<br />Or all testcases together? Too much lines, hard to understand what's happening...</p>
<p>If possible, could you please attach the logs of trxcon with the following<br />debug mask: DAPP:DL1C:DL1D:DTRX:DSCH:DSCHD? Thanks!</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=91882018-05-06T19:49:25Zfixeria
<ul><li><strong>File</strong> <a href="/attachments/3114">facch_delay.pcapng.gz</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3114/facch_delay.pcapng.gz">facch_delay.pcapng.gz</a> added</li><li><strong>File</strong> <a href="/attachments/3115">disable_clock_reset.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3115/disable_clock_reset.patch">disable_clock_reset.patch</a> added</li></ul><blockquote>
<p>Do the attached logs contain the output of BTS_Tests.TC_rll_est_ind only?</p>
</blockquote>
<p>Ok, I've found the answer myself while reading the TTCN code.<br />The logs only related to BTS_Tests.TC_rll_est_ind. The testcase<br />fails due to `T := 3.0` timer is being expired...</p>
<p>I think the root problem is hidden somewhere in the channel<br />coding implementation (i.e. in libosmocoding). Please see<br />the attached trace, that was made using a regular phone.<br />LAPDm frames were captured exactly on the BTS side.</p>
<p>Please note that call establishment on TCH/FACCH takes much<br />more time (i.e. frames) that establishment on SDCCH. Both<br />OsmoBTS and OsmocomBB/trxcon are relying on libosmocoding.</p>
<p>A temporary solution to make the test pass would be to<br />increase the timer. And also, I am going to refactor the<br />reset (L1CTL_RESET_REQ) policy. Please also try to<br />apply the attached patch.</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=92702018-05-10T17:50:09Zlaforge
<ul></ul><p>FYI: Due to the problems with FACCH with the BTS_Tests/trxcon/fake_trx/osmo-bts-trx chain, I've disabled Bm and Lm channels in those tests that use <code>g_AllChanTypes</code> (RLL tests and encrption tests). If Bm and Lm are added to this list of channel types, then all related tests start to fail. Executing them only on SDCCH/4 and SDCCH/8 passes fine. See <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: BTS_Tests.ttcn: Encryption + RLL tests not executed on Lm channels (TCH/H) (Resolved)" href="https://projects.osmocom.org/issues/3256">#3256</a></p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=92712018-05-10T17:50:18Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/3256">Bug #3256</a>: BTS_Tests.ttcn: Encryption + RLL tests not executed on Lm channels (TCH/H)</i> added</li></ul> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=92732018-05-10T17:55:46Zlaforge
<ul></ul><p>fixeria wrote:</p>
<blockquote>
<p>A temporary solution to make the test pass would be to<br />increase the timer.</p>
</blockquote>
<p>I will try, but I so far haven't seen the tests pass even once.</p>
<blockquote>
<p>And also, I am going to refactor the<br />reset (L1CTL_RESET_REQ) policy. Please also try to<br />apply the attached patch.</p>
</blockquote>
<p>unfortunately the patch doesn't change the test result / behavior, sorry.</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=92742018-05-10T17:57:36Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul><p>I have some higher priority issues at the moment, but I think it's rather important that we figoure out the cause of this.</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=100072018-06-23T18:31:42Zlaforge
<ul></ul><p><a class="user active" href="https://projects.osmocom.org/users/67">fixeria</a> any news about this one? It significantly decreases our test coverage, so it would be great to make some progress here...</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=100562018-06-25T07:06:48Zfixeria
<ul></ul><blockquote>
<p>any news about this one? It significantly decreases our test coverage,<br />so it would be great to make some progress here...</p>
</blockquote>
<p>Not yet, Harald. I will try to do something today.<br />Lots of trxcon related tasks are paused now, because of OS#1597.</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=100652018-06-25T14:48:48Zfixeria
<ul><li><strong>File</strong> <a href="/attachments/3245">facch_looong.pcapng.gz</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3245/facch_looong.pcapng.gz">facch_looong.pcapng.gz</a> added</li><li><strong>Project</strong> changed from <i>OsmocomBB</i> to <i>OsmoBTS</i></li><li><strong>Subject</strong> changed from <i>trxcon doesn't seem to support FACCH?</i> to <i>Extremely slow FACCH processing</i></li><li><strong>Category</strong> changed from <i>trxcon</i> to <i>osmo-bts-trx</i></li><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>Hmm, looks like this is not a problem of OsmocomBB/trxcon. This is a problem of OsmoBTS.<br />I just managed to reproduce the problem with RF-based setup: with OsmoTRX and a regular phone.</p>
<p>Please see the trace attached.</p>
<p>I am moving this issue to OsmoBTS, and will continue further debugging...</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=100992018-06-26T19:31:05Zlaforge
<ul></ul><pre>
20:59 < fixeria> LaF0rge: it's still unclean to me: are LAPDm fill frames (0x03?, 0x01, 0x01, 0x2b...)
generated in OsmoBTS or in OsmoBSC, when there is nothing to transmit...
21:02 < fixeria> I think it's somehow related to this slow FACCH processing...
</pre>
<p>The "030101" is a LAPDm fill UI frame with zero length payload. It's padded with 2b... at th end.</p>
LAPDm Fill frames are sent whenever there's nothing else to send on almost all channels, except
<ul>
<li>downlink PCH (there's a "paging no identity") instead</li>
<li>downlink SACCH (I think one always substitues a SI5/SI6 instead of an idle frame here)</li>
<li>downlink BCCH (you simply repeat any of the system information)</li>
</ul>
In terms of the use on FACCH, I think the following rules apply if you don't have anything to transmit:
<ul>
<li>if the channel is in "traffic/voice" mode, send codec frames</li>
<li>if the channel is in "signaling" mode, send a LAPDm fill frame</li>
</ul>
<p>I think those rules apply in both UL and DL direction as long as DTXu/DTXd is not enabled. Once DTX is enabled for the respective direction, no fill frames are transmitted, but only SACCH frames are sent.</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=101572018-06-30T20:54:20Zfixeria
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>The "030101" is a LAPDm fill UI frame with zero length payload. It's padded with 2b... at th end.</p>
In terms of the use on FACCH, I think the following rules apply if you don't have anything to transmit:
<ul>
<li>if the channel is in "traffic/voice" mode, send codec frames</li>
<li>if the channel is in "signaling" mode, send a LAPDm fill frame</li>
</ul>
</blockquote>
<p>The trxcon's scheduler implementation follows these rules. For each active logical<br />channel (e.g. SDCCH, FACCH, etc.) there is a dedicated TX queue. The L2&3 applications<br />are sending payload frames only (i.e. they don't care about LAPDm fill frames), so if<br />there is nothing in a particular TX queue, the trxcon's scheduler generates:</p>
<ul>
<li>a LAPDm fill frame on SDCCH and FACCH (during signalling mode),</li>
<li>a Measurement Report on SACCH (WIP <a class="external" href="https://gerrit.osmocom.org/7470/">https://gerrit.osmocom.org/7470/</a>),</li>
<li>a BFI (Bad Frame Indication) on TCH.</li>
</ul>
<p>In case of OsmoBTS, it looks like the LAPDm fill frames are being generated<br />by OsmoBSC/OsmoNiTB and not by OsmoBTS itself...</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=103402018-07-16T20:39:18Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li><li><strong>Assignee</strong> deleted (<del><i>fixeria</i></del>)</li><li><strong>Target version</strong> set to <i>osmo-bts-trx refresh</i></li></ul><p>I am not sure I can do any progress in short term here. So, I release this task for now.<br />It would be great to get some feedback, in particular:</p>
<ul>
<li>can anyone else reproduce this bug with a normal phone?</li>
<li>is osmo-bts-trx the only BTS variant affected by this problem?</li>
</ul>
<p>And additionally, we should make sure that OsmocomBB/trxcon does work correctly.<br />There is still no Dockerfile for SDR PHY, but we are working on it...</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=104632018-07-25T22:44:40Zfixeria
<ul></ul><p>It seems, the initial problem of 'FACCH is not working' (BTS_Tests.TC_rll_est_ind) is related to OS#3418:</p>
<pre>
<0006> sched_lchan_xcch.c:147 Primitive has odd length 7 (expected 23), so dropping...
</pre> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=104652018-07-25T22:59:09Zfixeria
<ul><li><strong>Related to</strong> deleted (<i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/3256">Bug #3256</a>: BTS_Tests.ttcn: Encryption + RLL tests not executed on Lm channels (TCH/H)</i>)</li></ul> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=107132018-08-09T20:14:15Zfixeria
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul><p>I would be happy if someone could confirm that OsmocomBB/trxcon does handle FACCH properly with some<br />non SDR-based BTS implementation (e.g. nanoBTS or sysmoBTS).</p>
<p>There is a Docker build script for GR-GSM TRX now:</p>
<p><a class="external" href="https://git.osmocom.org/docker-playground/commit/?id=b642b8688d510f8de4c21f58a9dd3c9d68c387a5">https://git.osmocom.org/docker-playground/commit/?id=b642b8688d510f8de4c21f58a9dd3c9d68c387a5</a></p>
<p>All you need to do is to get an USRP (B2X0 should work), and follow the guide:</p>
<p><a class="external" href="https://osmocom.org/projects/baseband/wiki/SDR_PHY#Docker-images">https://osmocom.org/projects/baseband/wiki/SDR_PHY#Docker-images</a></p>
<p>I would appreciate LAPDm/A-bis traces of a TCH/F call.</p>
<p>Please note that the container requires privileged access to the host's USB devices (not merged yet):</p>
<p><a class="external" href="https://gerrit.osmocom.org/10412/">https://gerrit.osmocom.org/10412/</a></p>
<p>I am open for any questions, and can help with setting up the HW/SW.</p> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=107142018-08-09T20:14:29Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li></ul> OsmoBTS - Bug #3233: Extremely slow FACCH processinghttps://projects.osmocom.org/issues/3233?journal_id=117492018-09-30T10:58:36Zlaforge
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>The Bm channels have been enabled in the test suite in Change-Id I7c0f9f9f695e089e4a30f63ec362d1e6c18abff0 related to <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: BTS_Tests.ttcn: Encryption + RLL tests not executed on Lm channels (TCH/H) (Resolved)" href="https://projects.osmocom.org/issues/3256">#3256</a> on July 27.</p>
<p>The Lm channels have been enabled in the test suite in Change-Id I78f82a5f2a7b21d91692b1c99a9ff125e65cab64 related to <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: BTS_Tests.ttcn: Encryption + RLL tests not executed on Lm channels (TCH/H) (Resolved)" href="https://projects.osmocom.org/issues/3256">#3256</a> on September 16.</p>
<p>I've seen Vadim's request at the end of this ticket, but this kind of request is better suited for the mailing list, and not something that should be in this bug report, which I believe has been fully resolved already. Please reopen if I'm wrong.</p>