Change in osmo-bsc[master]: refactor lchan counting

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.org
Mon Nov 8 14:42:26 UTC 2021


Hello Jenkins Builder, laforge, pespin, fixeria, 

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

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

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

Change subject: refactor lchan counting
......................................................................

refactor lchan counting

Add chan_counts_for_trx() and chan_counts_for_bts(). Drop
bts_count_free_ts() and trx_count_free_ts().

Rationale:

The bts_count_free_ts() and trx_count_free_ts() always returned the
number of free lchans, not timeslots. Hence, passing the pchan type as
argument never really matched the semantics.

Especially, when looking for free SDCCH, there is no clear match on a
gsm_phys_chan_config enum value: SDCCH8_SACCH8C, CCCH_SDCCH4,
CCCH_SDCCH4_CBCH, SDCCH8_SACCH8C_CBCH? -- GSM_LCHAN_SDCCH is clear.

==> Rather count free lchans by enum gsm_chan_t.

Counting lchans of distinct types required separate iterations for each
lchan type.

==> Rather compose an array of counts for all types, in one go.

I need to count the amount of free SDCCH lchans in an upcoming patch to
implement the performance indicator allAvailableAllocatedSDCCH (cumulate
time for which no SDCCH are available).

To implement allAvailableAllocated{SDCCH,TCH}, I need a count of both
the used as well as the total lchans for a type: it does not make sense
to flag "all available allocated" if none are ever available.

To properly count dynamic ts, I need the maximum total that can be
possible at any time. And to count currently free lchans, I need the
current total. This may seem counter intuitive, but consider, e.g.:

- Obviously, if a cell has only static TCH/F timeslots, it does not make
  sense to flag that all available TCH/H are occupied, because no TCH/H
  are available ever. Just stating this as contrast to dyn TS.

- If a cell has OSMO_DYN timeslots, I *do* want to flag that all TCH/H
  are occupied when all dyn timeslots are fully occupied.

- If those OSMO_DYN however are all used as TCH/F, the current total of
  TCH/H becomes zero, and it seems like TCH/H should not be considered.

- To count the nr of currently free lchans, I need the currently
  possible total of lchans and the nr of occupied lchans.

So return both a maximum total and a current total of lchans. In above
example, the maximum total shows that there would be TCH/H possible.

BTW, it would be nice to keep a chan_counts array on trx, bts and bsc
level and update as channels are allocated and released, instead of
counting them all over periodically. But it's less error prone this way.

Related: SYS#4878
Change-Id: I2fb48c549186db812b1e9d6b735a92e80f27b8d3
---
M include/osmocom/bsc/Makefile.am
M include/osmocom/bsc/bts.h
M include/osmocom/bsc/bts_trx.h
A include/osmocom/bsc/chan_counts.h
M src/osmo-bsc/Makefile.am
M src/osmo-bsc/abis_rsl.c
M src/osmo-bsc/bts.c
M src/osmo-bsc/bts_trx.c
A src/osmo-bsc/chan_counts.c
M src/osmo-bsc/handover_decision_2.c
10 files changed, 238 insertions(+), 72 deletions(-)


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

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


More information about the gerrit-log mailing list