Change in osmo-bsc[master]: refactor bsc_find_msc()'s round-robin

[neels]

Hello pespin, laforge, Jenkins Builder, 

I'd like you to reexamine a change. Please visit

    https://gerrit.osmocom.org/c/osmo-bsc/+/18505

to look at the new patch set (#5).

Change subject: refactor bsc_find_msc()'s round-robin
......................................................................

refactor bsc_find_msc()'s round-robin

Prepare for MSC pooling by NRI. Before introducing actual NRI decoding and MSC
matching, fix the bsc_find_msc() implementation.
(Indicate the places relevant for NRI by "TODO" comments).

bsc_find_msc() puts an MSC to the end of the internal list of MSCs when it was
used. This has problems:

- Modifying the list affects VTY output, e.g. 'show running-config' and
  'show mscs' change their order in which MSCs are shown, depending on how
  often a round-robin selection has taken place.

- Emergency calls and normal calls potentially pick quite different sets of
  eligible MSCs. When the round-robin choices between these sets affect each
  other, the choice is not balanced. For example, if only the first MSC is
  allow_emerg == true, every emergency call would reset the round-robin state
  to the first MSC in the list, also for normal calls. If there are regular
  emergency calls, normal calls will then tend to load more onto the first few
  MSCs after those picked for emergency calls.

Fix: Never affect the ordering of MSCs in the internal list of MSCs. Instead,
keep a "next_nr" MSC index and determine the next round-robin target like that.
Keep a separate "next_emerg_nr" MSC index so that emergency call round-robin
does no longer cause normal round-robin to skip MSCs.

Further problems in current bsc_find_msc():

- The "blind:" label should also do round-robin.
- The "paging:" part should not attempt to use disconnected MSCs.
- Both should also heed NRI matches (when they are added).

Fix: instead of code dup, determine Paging Response matching with an earlier
Paging Request right at the start. If that yields no usable MSC, continue into
the normal NRI and round-robin selection.

The loop in this patch is inspired by the upcoming implementation of MSC
pooling by NRI, as indicated by the two TODO comments. The point is that, in
the presence of an NRI from a TMSI identity, we always need to iterate all of
the MSCs to find possible NRI matches. The two round-robin sets (Emergency and
non-Emergency) are determined in the same loop iteration for cases that have no
or match no NRI, or where a matching MSC is currently disconnected.

Change-Id: Idf71f07ba5a17d5b870dc1a5a2875b6fedb61291
---
M include/osmocom/bsc/gsm_data.h
M src/osmo-bsc/gsm_08_08.c
2 files changed, 71 insertions(+), 60 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-bsc refs/changes/05/18505/5
-- 
To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/18505
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: Idf71f07ba5a17d5b870dc1a5a2875b6fedb61291
Gerrit-Change-Number: 18505
Gerrit-PatchSet: 5
Gerrit-Owner: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy at sysmocom.de>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200607/c3de1ce5/attachment.htm>