https://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-04-06T18:36:46ZOpen Source Mobile CommunicationsOsmoBTS - Bug #5996: DTXd and SID logic is broken for non-AMR codecshttps://osmocom.org/issues/5996?journal_id=266752023-04-06T18:36:46Zfalconia
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/26675/diff?detail_id=41929">diff</a>)</li></ul> OsmoBTS - Bug #5996: DTXd and SID logic is broken for non-AMR codecshttps://osmocom.org/issues/5996?journal_id=266762023-04-07T00:44:03Zfalconia
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> set to <i>falconia</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>30</i></li></ul><p>I have a partial fix for this bug on branch falconia/os5996. This fix should be correct and complete for osmo-bts-trx, but I don't have a solution yet for osmo-bts-sysmo. For the sysmo version, my difficulty is that I don't understand how the proprietary PHY handles the step of combining TCH with FACCH on the DL. With osmo-bts-trx it is obvious: we have code in tch_dl_dequeue() that explicitly prioritizes FACCH over speech traffic, we know when we are transmitting one or the other, and we can handle any corner cases that may arise. But in the sysmo version I can only assume that this combining must be happening in the PHY - is that the case? Does that femtobts PHY likewise prioritize FACCH over speech traffic? Does it mean that some TCH frames sent to the PHY won't actually be transmitted on the air because the PHY decides to schedule FACCH there instead?</p>
<p>Why does this FACCH business matter? The rules of section 5.1.2 in GSM 06.31 & 06.81 say that only one SID frame is to be transmitted after a talkspurt (after speech frames), plus one SID frame in each SACCH-aligned position every 480 ms. But what if that position (whether SACCH-aligned or right after a talkspurt) is taken up by FACCH? In that case the specs say that the next SID frame should be transmitted in the place of the FACCH-stolen one. Implementing this logic requires knowing when a FACCH frame has been transmitted - easy for osmo-bts-trx - but how would we implement the same logic in the sysmo version? Help and ideas will be appreciated.</p> OsmoBTS - Bug #5996: DTXd and SID logic is broken for non-AMR codecshttps://osmocom.org/issues/5996?journal_id=268872023-05-14T22:27:19Zfalconia
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>30</i> to <i>80</i></li></ul><p>I have a new solution for this bug:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/32714">https://gerrit.osmocom.org/c/osmo-bts/+/32714</a></p>
<p>Unlike my previous solution on falconia/os5996 branch, this new solution is fully contained in the common part and thus independent of BTS model. It works as intended on my sysmoBTS.</p> OsmoBTS - Bug #5996: DTXd and SID logic is broken for non-AMR codecshttps://osmocom.org/issues/5996?journal_id=269162023-05-17T21:49:56Zfalconia
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-2 priority-default" href="/issues/6036">Feature #6036</a>: Implement ternary SID classification for HR1 uplink</i> added</li></ul> OsmoBTS - Bug #5996: DTXd and SID logic is broken for non-AMR codecshttps://osmocom.org/issues/5996?journal_id=270002023-05-29T19:34:16Zfalconia
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p>A complete fix has now been merged into osmo-bts master:</p>
<p><a class="external" href="https://cgit.osmocom.org/osmo-bts/commit/?id=a84b9a02610448be60de40f8ea490d4e5fa7ac60">https://cgit.osmocom.org/osmo-bts/commit/?id=a84b9a02610448be60de40f8ea490d4e5fa7ac60</a></p>