https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-09-30T10:47:29ZOpen Source Mobile CommunicationsOsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=117452018-09-30T10:47:29Zlaforge
<ul><li><strong>Assignee</strong> set to <i>dexter</i></li></ul><p>I know <a class="user active" href="https://osmocom.org/users/15">dexter</a> has been working in this area recently. In any case, it needs to be fixed, if it's still present.</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=121202018-10-09T16:28:33Zdexter
<ul></ul><p>I have now analyzed the problem and I think that lchan_select.c is not behaving correctly.</p>
<p>Basically what happens is the following: The MSC offers a lot of unsolicited codecs, which I think is not exactly forbidden, but it could have respected what we already told it in the L3 complete message. However, the logic that selects the codec does select FR1, which is exactly what we configured (BTS implicitly has no codec limitation configured, the MSC is restricted to FR1). Until that point everything works.</p>
<p>But when the BSC is looking for an lchan the function lchan_select_by_type() does not find a TCH/F (since we only configured TCH/H). But instead of failing the function tries again with TCH/H, and succeeds. This leads into a TCH/H lchan to be selected and eventually leads into the wired ASSIGNMENT COMPLETE that happily tells the MSC that a GSM-HR has been selected as codec, even though this codec has never been allowed by the configuration.</p>
<p>I think The function lchan_select_by_type() should not implement such a fallback. The fallback is definetly intended as there is a comment /* If we don't have TCH/F available, fall-back to TCH/H */ in there, but I think this should not be. Lower layers must not jump over what the higher layers have negotiated.</p>
<p>Then we also should add some lchan scanning to codec_pref.c. It should scan through the lchan configuration and see if there is indeed an lchan for the codec that is selected.</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=121292018-10-10T10:57:17Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>On Tue, Oct 09, 2018 at 04:28:33PM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>But when the BSC is looking for an lchan the function lchan_select_by_type() does not find a TCH/F (since we only configured TCH/H). But instead of failing the function tries again with TCH/H, and succeeds. This leads into a TCH/H lchan to be selected and eventually leads into the wired ASSIGNMENT COMPLETE that happily tells the MSC that a GSM-HR has been selected as codec, even though this codec has never been allowed by the configuration.</p>
</blockquote>
<p>That fall-back code has been there "from the start" of openbsc, from before we<br />had any codec matching.</p>
<p><strong>Something</strong> has to do a fallback, though, in case multiple codecs are permitted<br />and the first one isn't available.</p>
<blockquote>
<p>Then we also should add some lchan scanning to codec_pref.c. It should scan through the lchan configuration and see if there is indeed an lchan for the codec that is selected.</p>
</blockquote>
<p>exactly. Iterate the allowed codecs in order of preference, and call<br />lchan_select() for each one; remove the fall-back to other voice codecs from<br />lchan_select().</p>
<p>This will be needed by assignment_fsm.c and handover_fsm.c, so it might as well<br />be a wrapper like lchan_select_by_codec_prefs(ms_codecs, bts_codecs,<br />msc_codecs) or something, in lchan_select.c, called by both. Or maybe rather<br />add the codec pref args to lchan_select_by_chan_mode() and do the matching in<br />there?</p>
<p>The RSL Chan Required / Immediate Assignment code already does that, it falls<br />back to TCH/* if lchan_select_by_type() has no SDCCH left. See abis_rsl.c<br />rsl_rx_chan_rqd().</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=121382018-10-10T11:38:20Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-4 priority-2 priority-default" href="/issues/3637">Bug #3637</a>: handover decision 2: properly check available codecs</i> added</li></ul> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=121402018-10-10T12:03:18Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>exactly. Iterate the allowed codecs in order of preference, and call<br />lchan_select() for each one [...]</p>
<p>This will be needed by assignment_fsm.c and handover_fsm.c</p>
</blockquote>
<p>In assignment_fsm.c, we want to pick one from a list of available configs.<br />(It's up to the user to configure codecs so that we don't need transcoding support...)</p>
<p>In handover_fsm.c, we currently want one specific existing lchan config that should be matched.<br />If the codec changes we're currently still broken in two ways: a) lack of transcoding b) no message to tell the MSC about it.<br />But ultimately, as soon as we support transcoding, we wouldn't mind to change the channel / codec type during handover. So basically, we can already implement towards the way Assignment does things: until transcoding is here, it is up to the user to configure so that codecs never mismatch, and we might as well pick any supported codec now; maybe mildly prefer to stay on the same codec the old lchan is on. When support for transcoding is added, users can start configuring more freely.</p>
<ul>
<li>internal HO: so far we have an lchan with a {type,mode,mr_cfg} and want to find an equivalent one.<br /> So far we just lchan_select_by_type(), i.e. we're happy if the TCH/x kind matches, ignoring AMR stuff and codecs.<br /> So that needs to be less naive.</li>
</ul>
<ul>
<li>incoming HO from remote BSS: we have a BSSMAP Handover Request message, with a Channel Type IE as well as Codec List (MSC Preferred).<br /> So far we do match_codec_pref(), apparently already heeding the request's IEs and AMR bits.<br /> Then we do lchan_select_by_chan_mode(). Looks ok?</li>
</ul> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=121412018-10-10T12:21:43Zdexter
<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>50</i></li></ul><p>I have now added checks that make sure a suitable pchan is available on the BTS. However we still may run into the odd situation that a wrong channel rate is used because that is problem is not addressed yet. But at least we are now preventing flawed configurations that can not work.</p>
<p>(<a class="user active" href="https://osmocom.org/users/91">neels</a> thanks for your input. I will go through that later but I see that we indeed need the fallback, but we only need it does not contradict wat the MSC allowed with the ASSIGNMENT REQUEST)</p>
<p>See also:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/11295">https://gerrit.osmocom.org/#/c/osmo-bsc/+/11295</a> codec_pref: cosmetic: seperate half/full rate determination<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/11296">https://gerrit.osmocom.org/#/c/osmo-bsc/+/11296</a> codec_pref: also check physical channels</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=121602018-10-11T14:10:32Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/3645">Bug #3645</a>: internal handover: when handover changes the speech codec, it should notify the MSC with BSSMAP Handover Performed</i> added</li></ul> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=124202018-10-29T13:32:03Zdexter
<ul></ul><p>Since the logic that checks the configuration the bug got more difficult to reproduce. The only situation where a wrong channel assignment now can happen is when for example all TCH/F are occupied, but at least one TCH/H is still free. When then a TCH/F is requested in the assignment request, the BSC will assign a TCH/H. We also would see that in the assignment complete. I am working on way to test this.</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=130522019-01-10T17:59:50Zdexter
<ul></ul><p>I have now analyzed the problem further. The channel allocator fails the assignment in the following situations:</p>
<ul>
<li>All FR channels full, but Assignment permits FR and HR (We should get at least an HR channel)</li>
<li>All HR channels full, but Assignment permits FR and HR (We should get at least an FR channel)</li>
</ul>
<p>When all HR channels are full and we purely ask for an HR channel we get an assignment complete for a FR channel.</p>
<p>I have now TTCN3 test cases and VTY debug commands that pinpoint those corner case situations. I will push the stuff for review when I have polished it a bit.</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=130762019-01-15T17:54:39Zdexter
<ul></ul><p>I have added two more tests to check the if the BSC returns with the preferred rate (FR or HR). When both, FR and HR is requested and FR is preferred, then FR is returned. For the case where FR and HR is requested and HR is prefered, FR is returned as well, which is wrong.</p>
<p>I managed to pinpoint one part of the problem, but not everything yet. 3 of 10 tests still are still failing.</p>
<p>The current state can be found on pmaier/challoc (osmo-ttcn3-hacks and osmo-bsc)</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=130792019-01-16T16:17:20Zdexter
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>80</i></li></ul><p>I think I have a good understanding now of what is going wrong at the BSC and I am now working on a solution. Actually the way the codec is currently selected does not honor the fact that an assignment command may ask for HR and FR (with a preference) at the same time, nor does decision include the current channel load.</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=130932019-01-17T17:34:00Zdexter
<ul><li><strong>% Done</strong> changed from <i>80</i> to <i>90</i></li></ul><p>The channel allocator problems seem to be fixed now. All the TTCN3 I have set up to address the problem do now pass. The patches and the TTCN3 tests are now in gerrit:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/12621">https://gerrit.osmocom.org/#/c/osmo-bsc/+/12621</a> chan_alloc: remove references to lchan_alloc()<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/12622">https://gerrit.osmocom.org/#/c/osmo-bsc/+/12622</a> lchan_select: dont allow half rate EFR to be selected<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/12623">https://gerrit.osmocom.org/#/c/osmo-bsc/+/12623</a> lchan_select: Do not unsolicitedly select a TCH/F<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/12624">https://gerrit.osmocom.org/#/c/osmo-bsc/+/12624</a> bsc_vty: add features to shun specific lchans<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/12625">https://gerrit.osmocom.org/#/c/osmo-bsc/+/12625</a> assignment_fsm: fix channel allocator preferences<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12620/">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12620/</a> WIP: BSC_Tests: Add tests to check channel allocator</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=131672019-01-28T15:50:24Zdexter
<ul></ul><p>The channel allocator fix and the necessary VTY changes are still under review. I have discussed with neels recently how we can simplify the lchan disable/enable functionality and we came across the idea that it is actually very easy to send the lchan fsm from unused to borken state and vice versa. I am using this method now and the tests still behave as expected. I haven't pushed that to gerrit yet since there still some review issues left.</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=131842019-01-30T09:37:32Zdexter
<ul></ul><p>I am now done with the review issues. The patches can be found under:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/12624">https://gerrit.osmocom.org/#/c/osmo-bsc/+/12624</a> bsc_vty: add features to disable specific lchans via vty<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/12625">https://gerrit.osmocom.org/#/c/osmo-bsc/+/12625</a> assignment_fsm: fix channel allocator preferences<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/12679">https://gerrit.osmocom.org/#/c/osmo-bsc/+/12679</a> bsc_vty: add vty command to display all lchans</p>
<p>The VTY patches are split up into two separate ones. The changes that just show lchan states for debugging are now separate. Also the lchan blocking is now done by using the borken state. Doing it that way requires no changes to the lchan FSM, its just the VTY that puts the lchan FSM from unused to borken state and vice versa.</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=131852019-01-30T09:39:23Zdexter
<ul></ul><p>Since the VTY syntax for switching between borken and unused had to be slightly modified in order to be more expressive on what actually happens the related TTCN3 tests also need some adjustment:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12728">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12728</a> BSC_Tests: fix vty interface for channel allocator tests</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=133532019-02-14T11:28:57Zlaforge
<ul></ul> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=134572019-02-25T11:16:23Zdexter
<ul></ul><p>The patch is now merged, but unfortunately we now see the following two testcases failing:</p>
<p>TC_assignment_codec_amr_f<br />TC_assignment_codec_amr_h</p>
<p>The reason for this is that S15-S0 are incorrectly stored and therefor the value is lost when the ASSIGNMENT complete is generated. The following patch fixes this:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/13039">https://gerrit.osmocom.org/#/c/osmo-bsc/+/13039</a> assignment_fsm: use activate.info.s15_s0 for ASS. COMPL.</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=134822019-03-05T08:57:36Zdexter
<ul></ul><p>Unfortunately I am still a bit confused where to store the s15_s0 bits I will discuss with neels as soon as possible how the problem can be resolved.</p>
<p>The S0-S15 bits are pretty much the only thing that has to be stored for longer. All other parameters are deducted from the current lchan parameters.</p>
<p>The speech codec IE is generated from the following parameters:<br />lchan->type, lchan->tch_mode and conn->lchan->activate.info.s15_s0</p>
<p>conn->lchan->activate.info.s15_s0 is the problematic one, it needs a different storage position. I wonder if it could be lchan->s15_s0 since the S-bits are a normal property of the lchan like the type or the tch_mode? This is what needs to be discussed.</p>
<p>Currently the storing of the s15_s0 happens somewhere were the value gets overwritten or not copied when the lchan changes so we get a constant 0x0000 here. This is also the reason why TC_assignment_codec_amr_f and TC_assignment_codec_amr_h are currently not passing.</p> OsmoBSC - Bug #3503: osmo-bsc: codec-list VTY cfg implementation not filtering correctlyhttps://osmocom.org/issues/3503?journal_id=135312019-03-11T17:47:16Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>The problem is fixed now, however, the storage location of S15-S0 is not correct yet. Since the scope of this task is solved now and the related tests are all passing I have crated a new task for this. See also: <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: Fix storage location of AMR S15-S0 bits (Resolved)" href="https://osmocom.org/issues/3833">#3833</a></p>