<p style="white-space: pre-wrap; word-wrap: break-word;">I see this fundamental problem:</p><p style="white-space: pre-wrap; word-wrap: break-word;">The case this patch is targeting is Immediate Assignment:</p><p style="white-space: pre-wrap; word-wrap: break-word;">1 new MS does CHAN REQ<br>2 we always Immediate-Assign an SDCCH<br>3 MS asks for voice call (goes through to MSC)<br>4 BSC gets Assignment Request from MSC to assign to TCH</p><p style="white-space: pre-wrap; word-wrap: break-word;">The place where you are aiming to change the behavior is 2.<br>So if we know that a TCH will be requested, don't occupy last available TCH as SDCCH.</p><p style="white-space: pre-wrap; word-wrap: break-word;">The problem is: how do you know at that point that a TCH will be requested?<br>The place where you figure out step2_type goes through a codec list.<br>But this list of permitted codecs will only be available during step 4.</p><p style="white-space: pre-wrap; word-wrap: break-word;">In practice, step 4 always and only requests TCH, and if it might ever happen<br>that a normal Assignment from the MSC requests an SDCCH8, then that SDCCH8<br>*will* be the final lchan type assigned. Typically, no TCH will follow shortly.</p><p style="white-space: pre-wrap; word-wrap: break-word;">The only case we need to cover is: first assigning an SDCCH8 shortly before a TCH<br>is requested, and that only happens during the initial CHAN REQ dance.</p><p style="white-space: pre-wrap; word-wrap: break-word;">I have these ideas:</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">- during CHAN REQ, an MS typically requests a chan mode. So, an MS can send a Channel Request reason<br>  of e.g. CHREQ_T_SDCCH or CHREQ_T_TCH_F. See abis_rsl.c:1684<br>  https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/abis_rsl.c?id=52b9912ef95838c0b60fc171984d3157a56fe488#n1684<br>  So you could guess the step2_type from this CHREQ reason.</pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;">- we could in general count the free TCH slots and always avoid pchan switch to SDCCH8<br>  if that would occupy the last available TCH. Not so elegant but fairly easy to implement.</pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;">- figuring out whether TCH are available after a dyn TS switch could be done via<br>  counting available TCH: if we have a dyn TS in PDCH mode, and the nr of available<br>  TCH/F is 1, we know that switching the dyn TS to SDCCH8 will reduce TCH/F by one.<br>  So we don't necessarily need a second pass over lchan_select(), we can use the<br>  counts instead.<br>  There is code doing something similar in handover_decision_2.c:1035:<br>  https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/handover_decision_2.c?id=52b9912ef95838c0b60fc171984d3157a56fe488#n1035<br>  I imagine there could be a next_sdcch_reduces_tchf somewhere;<br>  Then refuse if CHAN RQD asked for TCH and we see that<br>  free_tchf - next_sdcch_reduces_tchf <= 0.<br>  Should yield similar behavior with much less complexity in lchan_select functions</pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;">- this reminds me of the 'handover2 min-free-slots (tch/h|tch/f) N' config option.<br>  I was thinking whether it makes sense to take this number as an indicator whether<br>  we allow "congesting" TCH by switching a dyn to SDCCH8. But it's not a good fit really.</pre><p style="white-space: pre-wrap; word-wrap: break-word;">I see another possible issue:</p><p style="white-space: pre-wrap; word-wrap: break-word;">The patch avoids switching to SDCCH8 for the first MS in need of Immediate Assignment.<br>Once the timeslot is switched to SDCCH8, any other new MS will happily occupy SDCCH on it.<br>The SDCCH lchans will be released as the MS complete their signalling requests, but it is<br>still theoretically possible that after having converted to SDCCH8 once, the timeslot will<br>"resist" switching back to PDCH and "never" be available as TCH again. To illustrate, imagine a<br>high load situation. A lot of MS are trying to establish calls, but lchans are exhausted.<br>We take care to keep the last dyn TS available as TCH, servicing calls as possible.<br>In-between, there is one MS that only wants to send an SMS, so it gets assigned the first<br>SDCCH on the last remaining dyn TS. Now continuous CHAN RQD easily get an SDCCH assigned<br>(because we no longer need to switch the dyn TS and skip the check), and the dyn TS remains<br>in SDCCH8 mode indefinitely, occupied by MS trying to establish phone calls, which fail since<br>there are no TCH left. So I get the idea that even if a dyn TS is in SDCCH8 mode, we should<br>avoid Immediate Assignment there for MS that need a voice call established.<br>More generally put: if an MS asks for TCH during CHAN RQD, we refuse Immediate Assignment<br>when there are no TCH lchans available, always. In addition, we also refuse Imm Ass<br>when a dyn TS switch to SDCCH8 is necessary and no TCH is left after that switch.<br>This is indeed also solved by above mentioned free_tchf - next_sdcch_reduces_tchf <= 0 method.<br>So I guess that is a better approach to solve this issue.<br></p><p><a href="https://gerrit.osmocom.org/c/osmo-bsc/+/24876">View Change</a></p><p>1 comment:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/c/osmo-bsc/+/24876/1/src/osmo-bsc/lchan_select.c">File src/osmo-bsc/lchan_select.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/c/osmo-bsc/+/24876/1/src/osmo-bsc/lchan_select.c@216">Patch Set #1, Line 216:</a> <code style="font-family:monospace,monospace">                          return step2_type;</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">this is where step2_type is figured out</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-bsc/+/24876">change 24876</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-bsc/+/24876"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-bsc </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: I3b32968949a7bdcbebf5a823359295bac51d8e08 </div>
<div style="display:none"> Gerrit-Change-Number: 24876 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Wed, 07 Jul 2021 20:56:44 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>