Change in osmo-bsc[master]: WIP: avoid switching dyn ts to sdcch8 if it starves later TCH

neels gerrit-no-reply at lists.osmocom.org
Wed Jul 7 20:56:44 UTC 2021


neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/24876 )

Change subject: WIP: avoid switching dyn ts to sdcch8 if it starves later TCH
......................................................................


Patch Set 1:

(1 comment)

I see this fundamental problem:

The case this patch is targeting is Immediate Assignment:

1 new MS does CHAN REQ
2 we always Immediate-Assign an SDCCH
3 MS asks for voice call (goes through to MSC)
4 BSC gets Assignment Request from MSC to assign to TCH

The place where you are aiming to change the behavior is 2.
So if we know that a TCH will be requested, don't occupy last available TCH as SDCCH.

The problem is: how do you know at that point that a TCH will be requested?
The place where you figure out step2_type goes through a codec list.
But this list of permitted codecs will only be available during step 4.

In practice, step 4 always and only requests TCH, and if it might ever happen
that a normal Assignment from the MSC requests an SDCCH8, then that SDCCH8
*will* be the final lchan type assigned. Typically, no TCH will follow shortly.

The only case we need to cover is: first assigning an SDCCH8 shortly before a TCH
is requested, and that only happens during the initial CHAN REQ dance.

I have these ideas:

- during CHAN REQ, an MS typically requests a chan mode. So, an MS can send a Channel Request reason
  of e.g. CHREQ_T_SDCCH or CHREQ_T_TCH_F. See abis_rsl.c:1684
  https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/abis_rsl.c?id=52b9912ef95838c0b60fc171984d3157a56fe488#n1684
  So you could guess the step2_type from this CHREQ reason.

- we could in general count the free TCH slots and always avoid pchan switch to SDCCH8
  if that would occupy the last available TCH. Not so elegant but fairly easy to implement.

- figuring out whether TCH are available after a dyn TS switch could be done via
  counting available TCH: if we have a dyn TS in PDCH mode, and the nr of available
  TCH/F is 1, we know that switching the dyn TS to SDCCH8 will reduce TCH/F by one.
  So we don't necessarily need a second pass over lchan_select(), we can use the
  counts instead.
  There is code doing something similar in handover_decision_2.c:1035:
  https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/handover_decision_2.c?id=52b9912ef95838c0b60fc171984d3157a56fe488#n1035
  I imagine there could be a next_sdcch_reduces_tchf somewhere;
  Then refuse if CHAN RQD asked for TCH and we see that
  free_tchf - next_sdcch_reduces_tchf <= 0.
  Should yield similar behavior with much less complexity in lchan_select functions

- this reminds me of the 'handover2 min-free-slots (tch/h|tch/f) N' config option.
  I was thinking whether it makes sense to take this number as an indicator whether
  we allow "congesting" TCH by switching a dyn to SDCCH8. But it's not a good fit really.

I see another possible issue:

The patch avoids switching to SDCCH8 for the first MS in need of Immediate Assignment.
Once the timeslot is switched to SDCCH8, any other new MS will happily occupy SDCCH on it.
The SDCCH lchans will be released as the MS complete their signalling requests, but it is
still theoretically possible that after having converted to SDCCH8 once, the timeslot will
"resist" switching back to PDCH and "never" be available as TCH again. To illustrate, imagine a
high load situation. A lot of MS are trying to establish calls, but lchans are exhausted.
We take care to keep the last dyn TS available as TCH, servicing calls as possible.
In-between, there is one MS that only wants to send an SMS, so it gets assigned the first
SDCCH on the last remaining dyn TS. Now continuous CHAN RQD easily get an SDCCH assigned
(because we no longer need to switch the dyn TS and skip the check), and the dyn TS remains
in SDCCH8 mode indefinitely, occupied by MS trying to establish phone calls, which fail since
there are no TCH left. So I get the idea that even if a dyn TS is in SDCCH8 mode, we should
avoid Immediate Assignment there for MS that need a voice call established.
More generally put: if an MS asks for TCH during CHAN RQD, we refuse Immediate Assignment
when there are no TCH lchans available, always. In addition, we also refuse Imm Ass
when a dyn TS switch to SDCCH8 is necessary and no TCH is left after that switch.
This is indeed also solved by above mentioned free_tchf - next_sdcch_reduces_tchf <= 0 method.
So I guess that is a better approach to solve this issue.

https://gerrit.osmocom.org/c/osmo-bsc/+/24876/1/src/osmo-bsc/lchan_select.c 
File src/osmo-bsc/lchan_select.c:

https://gerrit.osmocom.org/c/osmo-bsc/+/24876/1/src/osmo-bsc/lchan_select.c@216 
PS1, Line 216: 				return step2_type;
this is where step2_type is figured out



-- 
To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/24876
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: I3b32968949a7bdcbebf5a823359295bac51d8e08
Gerrit-Change-Number: 24876
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-Comment-Date: Wed, 07 Jul 2021 20:56:44 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210707/85871d9b/attachment.htm>


More information about the gerrit-log mailing list