https://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-10-20T20:08:46ZOpen Source Mobile CommunicationsOsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=200592020-10-20T20:08:46Zfixeria
<ul></ul><blockquote>
<p>I would expect the BTS to send Bad Frame Indications instead.</p>
</blockquote>
<p>Alternatively, a) the BTS may send dummy FACCH frames ('0303012B2B2B...'O), so the MS would substitute them with BFIs itself; or b) we can run additional ECU instance for the Downlink path (we already have it on the Uplink direction), so the missing frames would not cause unpleasant sound effects.</p>
<p><a class="user active" href="https://osmocom.org/users/7">laforge</a> what do you think?</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=200602020-10-20T21:17:22Zfixeria
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>I've submitted two TTCN-3 test cases demonstrating the problem:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20810">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20810</a> BTS_Tests: introduce TC_speech_no_rtp_{tchf,tchh}</p>
<p>At least for now, we can verify that whatever is sent by the BTS can be decoded on the MS side without CRC errors.</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=200612020-10-20T21:20:09Zlaforge
<ul></ul><p>On Tue, Oct 20, 2020 at 08:08:51PM +0000, fixeria [REDMINE] wrote:</p>
<blockquote>
<p>Alternatively, a) the BTS may send dummy FACCH frames ('0303012B2B2B...'O), so the MS would substitute them with BFIs itself; or b) we can run additional ECU instance for the Downlink path (we already have it on the Uplink direction), so the missing frames would not cause unpleasant sound effects.</p>
</blockquote>
<ul>
<li>FACCH sounds like a hack</li>
<li>ECU instance or actively sending BFI makes more sense, IMHO</li>
</ul>
<p>Would be interesting so see what proprietary BTSs do in these situations. For Abis/IP,<br />that would be nanoBTS. But the same situation can of coruse happen in Abis/E1 with classic<br />BTS: Some TRAU Frames can also be missing in downlink, and the BTS still must be transmitting<br />something on the downlink.</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=206052020-12-14T20:45:11Zfixeria
<ul></ul><blockquote>
<p>Would be interesting so see what proprietary BTSs do in these situations. For Abis/IP, that would be nanoBTS.</p>
</blockquote>
<p>A quick experiment shows that nanoBTS is sending a dummy FACCH frame in all cases, except when AMR is in use.<br />In the later case I see some speech frames that all look like BFIs, not sure though.</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=213272021-02-17T14:16:47Zfixeria
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Stalled</i></li></ul> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=223462021-07-04T18:07:36Zfixeria
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=223472021-07-04T18:28:30Zfixeria
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>40</i></li></ul><p>Here is a quick and simple solution (better than nothing):</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/24846">https://gerrit.osmocom.org/c/osmo-bts/+/24846</a> osmo-bts-trx: send dummy FACCH in the absense of RTP frames [NEW]</p>
<p>Unfortunately, this is not enough to make BTS_Tests.TC_speech_no_rtp_{tchf,tchh} happy. The problem is that trxcon generates Bad Frame Indications in place of frames stolen by FACCH, and the test logic interprets this as decoding errors. So we still need to fix trxcon and/or the test expectations.</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=224582021-08-13T12:56:03Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul><p>As was requested during code review, I updated the commit message.</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=239342022-04-14T15:47:16Zfixeria
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=239362022-04-16T00:08:44Zfixeria
<ul></ul><p>Dummy FACCH/H scheduling was not implemented correctly, fixed in this patchset:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27802">https://gerrit.osmocom.org/c/osmo-bts/+/27802</a> osmo-bts-trx: move tx_tch_common() into a separate file [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27803">https://gerrit.osmocom.org/c/osmo-bts/+/27803</a> osmo-bts-trx: de-duplicate generation of BFI TCH frames [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27804">https://gerrit.osmocom.org/c/osmo-bts/+/27804</a> osmo-bts-trx: prioritize FACCH in s/tx_tch_common()/tch_dl_dequeue()/s [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27805">https://gerrit.osmocom.org/c/osmo-bts/+/27805</a> osmo-bts-trx: fix scheduling of dummy FACCH/H and FACCH/F [NEW]</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=239682022-04-19T20:45:29Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>40</i> to <i>80</i></li></ul><p>After getting some useful feedback, I decided to abandon the following patches:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27802">https://gerrit.osmocom.org/c/osmo-bts/+/27802</a> osmo-bts-trx: move tx_tch_common() into a separate file<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27803">https://gerrit.osmocom.org/c/osmo-bts/+/27803</a> osmo-bts-trx: de-duplicate generation of BFI TCH frames</p>
<p>updated the old patches and submitted a new patchset:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27804">https://gerrit.osmocom.org/c/osmo-bts/+/27804</a> osmo-bts-trx: prioritize FACCH in s/tx_tch_common()/tch_dl_dequeue()/s<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27835">https://gerrit.osmocom.org/c/osmo-bts/+/27835</a> osmo-bts-trx: tx_tchh_fn(): make handling of FACCH/H cleaner [NEW] <br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27805">https://gerrit.osmocom.org/c/osmo-bts/+/27805</a> osmo-bts-trx: fix scheduling of dummy FACCH/H and FACCH/F<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27836">https://gerrit.osmocom.org/c/osmo-bts/+/27836</a> osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed [NEW]</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=240242022-04-29T19:15:14Zfixeria
<ul><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27986">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27986</a> BTS_Tests: fix expectations in TC_speech_no_rtp_tch[fh] [NEW]</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=269992023-05-29T18:14:19Zfalconia
<ul></ul><p>In the classic E1-based GSM architecture the counterpart condition to OsmoBTS lacking RTP input for DL would be the E1-based BTS receiving an idle speech frame of TS 48.060 section 5.4 (further detail in section 5.5.5) in the place of a valid speech frame (section 5.1) on Abis DL. TRAUs normally don't allow this condition to happen, even in TFO, at least per the spec. In the case of TFO (the codec frame stream ultimately comes from UL of call leg A that will contain BFIs) TS 28.062 section C.3.2.1.1 tells TRAU implementors to essentially replicate the logic of the Rx DTX handler, including both ECU and comfort noise generator parts, but I am very uncertain if real TRAU implementations actually do what that spec section says. (I repeat my solicitation for someone to connect a real historical T1/E1 TRAU to OCTOI so I can experiment with it remotely.) I am so uncertain about real TRAUs implementing the rules of C.3.2.1.1 in their entirety because although they are relatively easy to implement for FR and HR, doing the same for EFR seems insanely difficult to me. Hence I wonder if perhaps real implementations relax those rules a little at least for EFR, or maybe even for all 3 codecs. My idea of "relaxed" implementation is to forward non-DTX-related (not after SID) BFIs to call leg B by inducing a deliberate BFI condition on the DL (send an idle speech frame of TS 48.060 section 5.4), and in the case of SIDs in input do what I did in just-merged I924ab21952dcf8bb03ba7ccef790474bf66fc9e5. The advantage of this approach is that it's very easy to implement and works exactly the same for all 3 non-AMR codecs.</p>
<p>OK, so what does the BTS part of E1-based GSM architecture do when it receives an idle speech frame (missing frame indicator) on Abis DL? The answer to this question is also what our BTS models should do when they receive empty TCH.req from l1sap - our l1sap-to-model internal interface is logically equivalent to E1 Abis. Not having any E1 BTS hw to experiment with, I'll go with my intuition, which tells me that we should transmit a bit pattern that will <strong>not</strong> cause any errors in the MS at the level of convolutional decoding, but <strong>will</strong> induce a BFI condition in the Rx DTX handler. In the case of FR, HR and EFR codecs the easiest way to do so is to transmit a speech frame with inverted CRC3 at the GSM 05.03 encoding level, and this approach is also what sysmoBTS PHY does. I have a patch in review that implements this behavior in osmo-bts-trx:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/33069">https://gerrit.osmocom.org/c/osmo-bts/+/33069</a></p>
<p>I will be updating that patch to resolve the recently arisen merge conflict and to address review suggestions from <a class="user active" href="https://osmocom.org/users/67">fixeria</a>, but the principal idea remains the same.</p>
<p>Please note, however, that my solution addresses FR, HR and EFR codecs <strong>only</strong>. What is the correct solution for AMR? Answer: I don't know. In case you haven't already figured out, I am the kind of developer who believes in doing things right, not a quick hack, and my current thorough understanding of FR, HR and EFR codecs is a result of having spent <em>months</em> studying the subject and getting hands-on experience implementing codec libraries, debug tools and a network edge transcoder to G.711 PSTN. I do not currently have the cycles to study AMR to the same level of depth, and thus my stance on AMR specifics will, for now, be to not initiate any behavioral changes to any Osmocom components in AMR modes and abstain from comment on AMR-specific parts of changes proposed by other developers.</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=273252023-07-12T20:19:52Zfixeria
<ul></ul><p>fixeria wrote in <a href="#note-7">#note-7</a>:</p>
<blockquote>
<p>[...] The problem is that trxcon generates Bad Frame Indications in place of frames stolen by FACCH, and the test logic interprets this as decoding errors. So we still need to fix trxcon and/or the test expectations.</p>
</blockquote>
<p>trxcon has meanwhile been fixed, so that it does not craft dummy TCH frames on its own, but send empty TRAFFIC.ind:</p>
<p><a class="external" href="https://cgit.osmocom.org/osmocom-bb/commit/?id=fd8962e89144fb0af4b99199589d9f9768804640">https://cgit.osmocom.org/osmocom-bb/commit/?id=fd8962e89144fb0af4b99199589d9f9768804640</a></p>
<p>I also replicated the behavior of sending invalid speech frames with inverted CRC3, like in osmo-bts:</p>
<p><a class="external" href="https://cgit.osmocom.org/osmocom-bb/commit/?id=0cfd0bbe801d86e1a3cbc08b228f9ad2521ebd08">https://cgit.osmocom.org/osmocom-bb/commit/?id=0cfd0bbe801d86e1a3cbc08b228f9ad2521ebd08</a></p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=273262023-07-12T20:28:46Zfixeria
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>fixeria wrote in <a href="#note-12">#note-12</a>:</p>
<blockquote>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27986">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27986</a> BTS_Tests: fix expectations in TC_speech_no_rtp_tch[fh] [NEW]</p>
</blockquote>
<p>These two testcases are currently passing due to a bug in the BFI template definition. They would be passing even if the IUT would be sending dummy bursts or sending nothing at all, because they were designed to fail on receipt of a never-matching TRAFFIC.ind template. This patch fixes the problem and aligns their expectations with the current behavior of osmo-bts:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27986">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27986</a> BTS_Tests: fix expectations in TC_speech_no_rtp_tch[fh]</p>
<p>Additionally I extended TC_speech_no_rtp_tchf to verify TCH/EFS and added some TODOs about TCH/A[FH]S:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33725">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33725</a> BTS_Tests: also test TCH/EFS (EFR) in TC_speech_no_rtp_tchf</p>
<p>The updated testcases are passing: we're getting empty TRAFFIC.ind with bad CRC but no bit errors, as expected. I think we can close this ticket and create a separate one for tracking the state of TCH/A[FH]S. Thanks for your contributions, <a class="user active" href="https://osmocom.org/users/308579">falconia</a>!</p> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=273322023-07-12T21:04:22Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/6049">Bug #6049</a>: TRX version transmits dummy FACCH instead of proper downlink BFIs</i> added</li></ul> OsmoBTS - Bug #4823: osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frameshttps://osmocom.org/issues/4823?journal_id=273342023-07-12T21:05:34Zfixeria
<ul></ul><p>fixeria wrote in <a href="#note-15">#note-15</a>:</p>
<blockquote>
<p>I think we can close this ticket and create a separate one for tracking the state of TCH/A[FH]S.</p>
</blockquote>
<p>Oh, I didn't notice there was another ticket about this problem <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: TRX version transmits dummy FACCH instead of proper downlink BFIs (Resolved)" href="https://osmocom.org/issues/6049">#6049</a>. Let's then track the AMR problem there.</p>