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
It's more logical to have the boundaries sorted in ascending order:
* band 1 represents lowest interference levels,
* band 5 represents highest interference levels.
Change-Id: Ie9bf4bf0c89418685b8ea5096332d22cfba7c521
Related: SYS#5313
As stated in "GSM/EDGE Evolution and Performance", section 12.3,
both features *can* be enabled simultaneously.
Change-Id: I2189f01bd78625dab3d642597240338ee581fc98
Related: SYS#5319
We have lots of counters for intra-BSC handover *away from* a given BTS,
but still missing are counters indicating how many handovers *targeted*
a given BTS. Also count incoming HO.
Related: SYS#4878
Related: Iba229313d73fa20266f6d4eac5820579fb14c604 (osmo-ttcn3-hacks)
Change-Id: Id9f2c6e2865ebe680879018fff08d283ce24c983
I was a bit confused that grep did not find HO counters being used, so
let's add some comments to better explain and provide a grep hook.
Related: SYS#4878
Change-Id: I242de13e657286e09428a8ca6e583d8b5155faa2
nanoBTS would NACK a CHANnel ACTIVation message for an 'intra cell
channel change' if it does not contain the Timing Advance IE. And
this is right, because according to 3GPP TS 48.058, section 8.4.1,
point '4)', it *must* be included.
Indeed, the actual Timing Advance value is not known during the
manual channel activation triggered from the VTY interface. So
let's merely indicate 0 if it's not known.
Change-Id: Iee7ddb4cf1a9a7bb9b34e6c9f6f9899da480fbd0
It is possible to change the neighbor-list mode via the VTY from
automatic mode to manual neighbor-list configuration. In the manual
mode, the user can add ARFCN values manually. This command can be found
under the bts node. Lets add pendant of this command on the control
interface as well.
Change-Id: Id97bc0d31a358db6221c385761773fb48670c921
Related: SYS#5641
The VTY allows flexible control over the neighbor cell information via
the neighbor command, which can be found in the configure terminal under
the bts node. Lets add pendant of this command on the control interface
as well.
Change-Id: I343a40e18fa9b91e6c381912c0426a002841e079
Related: SYS#5641
The Neighbor Address Resolution Service is using the control interface
API as well. Lets add a comment to indicate that this service is not
related to the normal control interface.
Change-Id: Iec86f72548bfc54a2c86dadec69dd1c64813d852
When the gsm_subscr_conn_fsm (GSCO) terminates abormally it might not go
through the forget-mgw-endpoint mechanism. It might be terminated
forcefully, which means only the pre_term callback runs. The pre_term
callback clears the endpoint, but it does not put the mgcp_client
reference back into the pool. This results into a wrong ref-count in the
mgw-pool.
Change-Id: I5a7ce6a1880a1060df74d03dd4eb38b51fd85c69
Related: SYS#5675
The option -t --testmode is defined, but not evaluated. It seems that
the code of this option was removed long ago. Lets remove it now.
Change-Id: Ie11173f5a7aab568b9a25102ad7dcf37fd49f318
VAMOS secondary lchans are to be used specifically when the osmocom dyn
TS is set to pchan_is=TCH_{F,H}. Setting secondary subslots for
OSMO_DYN TS is not needed since it's only used to initialize the TS, and
OSMO DYN already initializes 8 subslots
(subslots_per_pchan[GSM_PCHAN_OSMO_DYN]=8). Otherwise, ts_setup_lchans()
will try to initialize 8+2 lchans on the TS, which is more than needed
and will access out of bounds in the array.
Related: OS#5278
Change-Id: I8727d5b446179c0ebcd8738507efe5a50afaf1e2
Since a while ago, osmocom types dynamic TS supports being configured as
SDCCH8, hence the maximum subslots is 8. This fixes issue where only up
to 2 subslots where being used on those TS.
Related: OS#5278
Related: SYS#5309
Fixes: 52b9912ef9
Change-Id: I50e6530284ef49cfd77d1944d4a183c5df345820
It is not possible to operate a cell that has secondary TRXs in
different bands. Especially considering that DCS1800 and PCS1900 have
overlapping ARFCN numbers it would be hard for the MS to tell to which
band it should switch. Also the ImmAss. message only contains the ARFCN
number. It is impractical to have TRXs in different bands and probably
this also violates the sepec.
Change-Id: Icc2af9e2a9bca3897dbbb34d7b2c0fe6f843bedd
The value ncc_permitted is preset in osmo_bsc_main.c from
bootstrap_bts(). It is a constant value that also cannot be changed via
the VTY. Therefore it should be set from bts_alloc(). This also fixes
the problem that when the BTS is added at runtime from the VTY. BTSs
added at runtime would have an all zero ncc_permitted until the next
restart of osmo_bsc.
Change-Id: I9f02277d7b4b4bcb383e749435416a0b22efd5e8
Related: SYS#5369
The index counter bts->chan_load_samples_idx is initialized to 0 in
bootstrap_bts. Since the bts object is allocated using talloc it is
already guaranteed that everything is set to zero. So we do not need to
initalize chan_load_samples_idx.
Change-Id: Ia75e59c44c3ccd653a2614c2cda7519faf999f09
The acs value is currently set from bootstrap_bts() in osmo_bsc_main.c.
The value is set to 0. Since the BTS object is allocated using
talloc it is guaranteed to be 0 from the beginning. Lets set it from
bts_alloc anyway so that we have a place holder that is easy to find.
Change-Id: Idc4e08c471e15c36b4ea7eb3981254e179115765
The pwrc value is currently set from bootstrap_bts() in osmo_bsc_main.c.
The value is set to 0. Since the BTS object is allocated using
talloc it is guaranteed to be 0 from the beginning. Lets set it from
bts_alloc anyway so that we have a place holder that is easy to find.
Change-Id: Id76879a94cf8cf8c07e8fc7e8aa399cd50e04e9a
At the moment we set the R99 flag from bootstrap_bts() in
osmo_bsc_main.c. However this constant flag should be set together
with the many preinitalized chan_desc values in bts_alloc
Change-Id: I5b78c4e25616ab552c37ba8b7c9948cf7052bad4
The function gsm_set_bts_type() already takes care of setting the
model->started flag to true. There is no need to do this in
bootstrap_bts() again.
Change-Id: Ia70943d96d466ab506fe368ef178a2ccc7483adc
Controversy: this duplicates bts.N.rsl_connected. I would like to add
this duplication for consistency, since we now have these counters:
bsc.0.num_trx:rsl_connected
bsc.0.num_trx:total
bts.N.num_trx:total
and the old
bts.N.rsl_connected
which does not fit well with above naming scheme. Any user will be
justified to expect a stat named bts.N.num_trx:rsl_connected as well.
Determine bts.N.num_trx:rsl_connected in the new function
bsc_update_connection_stats(), where the other num_trx:* are set.
Related: SYS#5542
Related: I5be1cb470930354c4561cbed301bc50a32484ed9 (osmo-ttcn3-hacks)
Depends: I137992a5479fc39bbceb6c6c2af9c227bd33b39b (libosmocore)
Change-Id: I55b55159fe13d937e441d8c2ed915734463e1154
This is similar to bsc.0.num_trx:total but per single BTS.
Related: SYS#5542
Related: I5be1cb470930354c4561cbed301bc50a32484ed9 (osmo-ttcn3-hacks)
Depends: I137992a5479fc39bbceb6c6c2af9c227bd33b39b (libosmocore)
Change-Id: I283d38e7a8c032e274a5bd2fa150ec2c9a7157b4
If an RF Resource Indication message includes interference band(s)
for 'pure' PDCH (i.e. not dynamic) timeslot(s), osmo-bsc logs:
DRSL DEBUG abis_rsl.c:1515 (bts=0,trx=0) Rx Resource Indication
DRSL ERROR bts_trx.c:236 (bts=0,trx=0) chan_nr 0xc7 cbits 0x18:
(bts=0,trx=0,ts=7,pchan=PDCH,state=UNUSED) is not GSM_PCHAN_OSMO_DYN
DRSL ERROR abis_rsl.c:141 (bts=0,trx=0,ts=7,pchan=PDCH,state=UNUSED)
Abis RSL Rx Resource Indication: mismatching chan_nr=0xc7
Let's better check if a timeslot is capable of GSM_PCHAN_PDCH,
rather than checking if it's GSM_PCHAN_OSMO_DYN.
Change-Id: I2cac4acd4c5145c5c525c9952fdc754477ce0942
Related: SYS#5313
Now that we solved all the interdependency symbol mess, we can finally
enable call to this function.
Change-Id: Id4c724ef17beae4bb0918ebd1a809665b59e4861
These are not needed anymore since we re-introduced libbsc, specially to
avoid all this churn.
Some specific methods are explicitly required to be overwritten by
tests, so we specificially mark those with __attribute__((weak)) in
order to be able to overwrite them.
This is the last step towards fixing interdependency mess of symbols and
stubs, and requires previous patches in order to have tests apssing
fine.
Change-Id: Ic7401b8a6eb903882e30fda1cf091ac99a254ef0
This allows having it initialized automatically, as we usually do with
this type of code. As a result, tests or other apps importing libbsc
don't need to take care of calling it.
NOTE: This fix is required by follow-up patches where some stubs are removed
and hence some tests start using FSMs internally. Since tests were not
using those FSMs before, there was no need to call ts_fsm_init().
This is one further step towards fixing interdependency mess of symbols
and stubs.
Change-Id: I0e4b95b5e73fbb3844d83ba33e66786831088e1f
This is used inside group of files forming libbsc (shared files used by
several apps). Let's instantie only once inside a file from libbsc
instead of doing so on each binary.
This is one further step towards fixing interdependency mess of symbols
and stubs.
Change-Id: I9b287aa492ca6aae5fc56133e1510aff3146fe25
osmo_fsm_inst_free() must be called explicitly, otherwise the instance
is kept in the llist of instances and produces heap-use-after-free.
Note: This fix is required by follow-up patches where some stubs are removed
and hence some tests start using FSMs internally. Due to this bug, tests
will crash due to reason explain in previous paragraph.
This patch itself may introduced failures to build due to some new
interdependencies being introduced in same follow-up patches mentioned
above, which are in turn fixed by this present patch.
So they are expected to be merged together.
Change-Id: Ib0e5560efe518833f76f846d7269e82d85c186a1
Increase the reaction time at the expense of more stable loop with less
temporary oscillations.
See updated user manual documentation in this commit for a larger
description.
Related: SYS#5371
Change-Id: I46be244a5e01a74086e3a977ec3ea139742a0074
* Adds vty option dyn-bsc for ms-power-control -> mode
* Imports power_control.c from osmo-bts project
[at commit 2f3cd4b697972d8484f9a9d3b7ef634086f65fa5]
* Removes unused C/I code from osmo-bts's power_control.c
This patch then calls the power loop on receipt of measurement
reports and updates the MS Power Level accordingly.
Change-Id: Ibc307e758697eb5ca3fb86622f35709d6077db9e
From the nature of the lchan_activate_info.tsc_set and .tsc, it is easy
to forget to set tsc_set,tsc = -1 to use default TSC Set and TSC values.
Handover code is one such instance that forgets to set -1.
Change the semantics of tsc_set and tsc so that this kind of error can
not happen again as easily: use a separate bool to flag whether to use
the default config or explicit values.
Implicitly fix the lchan_activate_infos "launched" in handover_fsm.c as
well as abis_rsl_chan_rqd_queue_poll().
Related: OS#5244 SYS#4895
Related: I1ed6f068c85b01e5a2d7b5f2651498a1521f89af (osmo-ttcn3-hacks)
Change-Id: Iae20df4387c3d75752301bd5daeeea7508966393
When the SDCCH gets released while the TCH still beeing activated, then
the ChanActivACK that is received after the TCH is activated will trigger
a segmentation fault in the assignment_fsm. The reason for this is that
conn->lchan, which holds the SDCCH at that point in time, is now NULL.
To prevent osmo-bsc from crashing, the FSM should check for the presence
of conn->lchan first. If it does not exist, the FSM should terminate.
(Assignment failed)
Change-Id: I3b1cd88bea62ef0032f6c035bac95d3df9fdca7a
Related: SYS#5627