This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
neels gerrit-no-reply at lists.osmocom.orgneels 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/6bca8ffe/attachment.htm>