For handover algorithm 2, properly figure out what effects the target
cell will see for the *other* TCH kind when a handover would occupy a
dynamic timeslot.
Before this, only TCH/F or TCH/H would be regarded at a time. This
introduces detection of whether a dynamic timeslot would be occupied by
a handover, and how losing one unused dynamic timeslot affects the
congestion situation for the TCH kind that is not targeted by the
handover.
In other words, if a handover to TCH/F causes congestion in TCH/H
because of a dynamic timeslot becoming occupied, the handover will not
be performed. Before this, oscillation situations could occur.
A subsequent patch will do the same for congestion balancing.
Related: SYS#5297
Change-Id: I1536b60f03cb0aeb6ba14a72b518aec82fa572fe
The test shows a cascade of failures. When we fix the first failure, it
will change the sequence of events that follow after that. But it will
still be interesting to evaluate all the situations currently shown.
Hence fixate each stage's initial situation, by duplicating the
expect-ts-use with an identical set-ts-use. Then, when each individual
scenario gets fixed, subsequent scenarios still remain unchanged.
Change-Id: Ifeaec39ecb64b476ff1438cf987ba0403489c43b
The idea is to avoid confusion between the static PDCH and the dynamic
timeslots. The PDCH is always in 'pdch' mode, while the dynamic
timeslots are 'pdch' when they are not occupied by any TCH.
Change-Id: I1a12518d85ed891c491723e7f03f5bdd4fad980f
So far, the test only works because osmo-bsc fails to notice that
occupying the dynamic TS 1 as TCH/F does, overall, not free a TCH/H, but
reduces available TCH/H from 5 to 4 (one TCH/H freed, but two TCH/H lost
from occupying a dynamic TS). An upcoming patch will make osmo-bsc
sensitive for these cross effects between TCH/F and TCH/H when dynamic
timeslots are involved, hence this test needs to be stabilized.
By using a static TCH/F for TS 1 instead of a dynamic timeslot, the dyn
TS cross effect does not occur and this test actually makes sense.
Change-Id: I492ea095cf3e3c3fd186c889166c4ed93ab3a007
On -u, update the handover_tests.ok file that lists all tests that are
expected to run. This is necessary for the regression tests to succeed.
Update all the numerous test_*.ho_vty.{err,ok} files only when the
update arg is a captial -U, because those are usually not interesting,
except for manual comparison of test runs.
Change-Id: Id280a8d084fd84b0b7486a5c8022e5b7a26f6095
The following message makes no sense:
DRLL DEBUG gsm_data.c:844 MS Power class update: 4 -> 4
because nothing really changed, MS Power class remains 4. Neither
it makes sense to call lchan_update_ms_power_ctrl_level().
Change-Id: I519d2d1575cbb5352cc381a60513db8e0e2cb0a0
Allocating a new list of supported codecs *before* checking the
command arguments is a bad idea. The operator may simply mistype
one of the codecs and will end up with a list of NULL pointers.
The functions calling audio_support_to_gsm88() assume that this
list always does contain valid pointers, so if a new subscriber
connection gets established, or the operator simply invokes
'show running-config', osmo-bsc would crash due to NULL pointer
dereference.
Steps to reproduce:
1. In the VTY, do: 'en' -> 'configure terminal' -> 'msc';
2. Configure any invalid codec list, e.g. 'codec-list Boom!';
3. Invoke 'show running-config', boom!
Let's check the input before changing the internal structures.
Change-Id: I35b740a39c9cf3716d286e717486ef505bc61522
Fixes: OS#4946
My assumption that lchan_reset() is called on CHANnel ACTIVation
was wrong - it's actually called on CHANnel RELease. Therefore
(re)setting per-lchan BS power value must be done in the other
function that is responsible for channel activation.
Change-Id: I056c448ce017458dc4a004374ddca86d44dc35b4
Related: SYS#4918
config_write_bts_gprs() currently writes the remote address of an
NSVC even if osmo_sockaddr_str_from_sockaddr() returns non-zero
code. Thus saving a configuration with only one configured NSVC
to a file would produce the following:
bts N
...
gprs nsvc 0 nsvci 101
gprs nsvc 0 local udp port 23023
gprs nsvc 0 remote ip 127.0.0.1
gprs nsvc 0 remote udp port 23000
gprs nsvc 1 nsvci 0
gprs nsvc 1 local udp port 0
gprs nsvc 1 remote ip
and next time osmo-bsc would refuse to start due to:
Error occurred during reading the below line:
gprs nsvc 1 remote ip
The related condition consists of the following two parts:
- checking if osmo_sockaddr_str_from_sockaddr() != 0;
- checking if 'remote.af != AF_UNSPEC'.
The first one is wrong, because osmo_sockaddr_str_from_sockaddr(),
like many other functions, returns 0 on success. Let's fix this.
After the fix, the second part does not seem to make sense, because
remote.af would remain AF_UNSPEC (0) if the function call succeeds.
Printing the remote port alone does not make sense, let's avoid
printing it if the address cannot be parsed into a string.
Change-Id: I5d6cbde4f605c8184db4ade87de5644a849c05db
Fixes: I621360cab1e12c22248e33d62a9929995053ce04
For balancing load across congested cells and across congested TCH/*
kinds, instead of comparing the number of lchans above the configured
congestion threshold, compare the percent of lchans of overload.
In short, using a percentage prevents cells with less min-free-slots to
fill up 100% while neighbor cells still may have several free lchans
available.
An obvious example of why this is desirable is illustrated by
test_balance_congestion_by_percentage.ho_vty:
Cell A has min-free-slots 2, and has all slots occupied.
Cell B has min-free-slots 4, and has 2 slots remaining free.
If we count congested lchans as in current master: cell A has a
congestion count of 2: two more lchans in use than "allowed". If we move
one lchan over to cell B, it ends up with a congestion count of 3, which
is worse than 2. So when counting lchans, we decide that cell A should
remain full.
Instead, when comparing percentage of remaining lchans, we would see
that cell A is loaded 100% above congestion (2 of 2 remaining lchans in
use), but when moving one lchan to cell B, that would only be 75% loaded
above its treshold (3 of 4 remaining lchans in use). So a percentage
comparison would cause a handover to cell B.
Related: SYS#5259
Change-Id: I55234c6c99eb02ceee52be0d7388bea14304930f
This new CTRL interface allows users of this BSC (such as attached PCU)
to gather neighbor information.
This interface is needed for PCU to translate ARFCN+BSIC keys provided
by MS in the Um side into CGI + RAC keys used to identify target cells
in RIM procedures against SGSNs on the Gb interface.
This patch extends the already existing neighbor information storage in
the VTY by allowing storage of CGI + RAC (RAC couldn't be stored
beforehand).
Related: SYS#4909
Depends: libosmocore.git Change-Id If48f412c32e8e5a3e604a78d12b74787a4786374
Change-Id: Ib07c9d23026332a207d4b7a0f7b4e76c0094e379
Considering feedback by a customer, we prefer congestion balancing by
using percentage of overload instead of number of lchans of overload.
This test is intended to illustrate the change in behavior.
Change-Id: I314915718f66aec50e8dcf94569b0a52ca34b96f
When evenly distributing congestion across cells, count the number of
occupied lchans surpassing congestion, and not the overall number of
free lchans -- which disregards congestion thresholds.
Fix the bugs shown by
test_congestion_no_oscillation.ho_vty
test_balance_congestion_tchf_tchh.ho_vty
This implements a simple calculation for congestion load by counting
lchans in use above congestion. An improvement of this calculation
using percent follows in I55234c6c99eb02ceee52be0d7388bea14304930f.
Related: SYS#5259
Change-Id: Icb373dc6bfc9819446db5e96f71921781fe2026d
With 'set-ts-use', it is convenient to build a scenario of lchan usage,
but still inconvenient to send measurement reports to all lchans.
I need this for testing congestion-check, because each lchan needs to
have at least one measurement report, or congestion check is skipped.
Example:
set-ts-use trx 0 0 states * TCH/F TCH/F - - TCH/HH TCH/HH TCH/H-
meas-rep lchan * * * * rxlev 10 rxqual 0 ta 0
This patch adds the '*' for the lchan arguments, usually being bts idx,
trx idx, timeslot idx and subslot idx.
Use lchan wildcards at the appropriate places to shorten some tests.
Change-Id: I441f92348508d45e1069a3dfa1ff3842dbba97d6
Store the number of free lchans and the min-free-slots settings in
ho_candidate, instead of figuring those out in various places, to make
it easier to read.
Prepare for upcoming patch which also requires these values to fix a
bug.
Change-Id: Ie6ca5af5e8d0ebb8deaaaa637e2728008ecba517
So far it is often confusing which cell a specific member refers to.
Clarify lchan, bts, ... to current.lchan, target.bts, ...
Also move the rxlev_{current,target} to {current,target}.rxlev.
Eliminate numerous local variables to make it easier to read which side
is being used (e.g. "c->target.bts" instead of just "bts").
No functional change.
Change-Id: I06898eb745a5be548df0b76fa760ce790cfab3ed
Also add test_congestion_no_oscillation2.ho_vty which is an almost
identical scenario that does not show the bug -- because it has two more
TCH/H available in BTS 1, showing the strange behavior of the algorithm.
Related: SYS#5259
Change-Id: Idf88b4cf3d2f92f5560d73dae9e59af39d0494c0
Echo each handover_test command on the test output, to help with
understanding the exact point of a test failure.
Even nicer would be a general echo of all VTY commands, but the VTY
currently does not support that feature. Refraining from a libosmocore
patch just for these test scripts...
Change-Id: Ifc307a7d0b7e3caa355f8cee88778762b529ad71
Similar to chan act handling, clarify and safeguard HO Request handling.
Ensure that each HO Request is handled by the test script.
Place unhandled HO Requests in new_ho_req pointer, moving to last_ho_req
upon handling it. Instead of the got_ho_req flag and additional
ho_req_lchan pointer, just keep a last_ho_req pointer.
Drop a bunch of utterly useless RSL message parsing code.
Fix unhandled HO Request in test_max_handovers.ho_vty.
Change-Id: I0a664f24d7dd3d7b254b29675fdc49cd70a1a480
Do not clear pending chan act requests when sending a measurement report
or starting congestion check. This potentially left channel activations
unnoticed and dangling, e.g. for repeated meas-rep.
A typical test should indeed handle pending channel activation requests
before potentially triggering more, safeguard against this by asserting
that only one channel activation is pending.
Place unhandled channel activations in new_chan_req pointer, moving to
last_chan_req upon handling it. Instead of the got_chan_req flag and
additional chan_req_lchan pointer, just keep a last_chan_req pointer.
Change-Id: If06587058798d96afca86358030dc0c1c3c6df39
Fix flaws in picking a candidate for congestion resolution, shown in
recently added tests.
- For TCH/H->TCH/F upgrading, do not favor moving to a weaker neighbor
cell.
- When comparing dynamic timeslots on the same cell, favor a dynamic
timeslot that frees an entire dyn TS even though the target rxlev
differs.
Do not separate the passes for inter-cell and intra-cell candidates:
before, the inter-cell pass would already pick a candidate and start
handover, even though the subsequent intra-cell pass would have revealed
a better candidate. Join the intra-cell considerations into
pick_better_lchan_to_move().
The intra-cell pass was separate, because it would find the *weakest*
current rxlev, to give a TCH/H to TCH/F upgrade to the currently weakest
lchan.
Instead of the separate pass for weakest rxlev, in addition to the
target cell's rxlev, also consider the rxlev *change* in
pick_better_lchan_to_move(): For candidates that do not change the rxlev
(usually those that stay in the same cell) and that upgrade to TCH/F,
favor a candidate with weaker current rxlev.
Completely revisit the conditions in pick_better_lchan_to_move() to
yield the desired prioritization of candidate preferences.
In three handover tests, remove the "FAIL" comments and adjust to now
expect the actually desired behavior.
Related: SYS#5032
Change-Id: I2704899c85c35dfd4eba43468452483f40016ca2
Instead of passing the TCH/H -> TCH/F bias (AFS bias) in local
variables, rather store it in the ho_candidate struct next to the other
rxlev related values.
Add the AFS bias to the compared rxlev in pick_better_lchan_to_move().
Modify pick_better_lchan_to_move() to simpler semantics of returning
either a or b.
No functional change.
Change-Id: I73860abdf2a77270ca4851ad58c09767d1bb08f1
Store the rxlev of the current lchan and the target BTS in the
ho_candidate, to clarify the code.
No functional change, cosmetically prepare for
I2704899c85c35dfd4eba43468452483f40016ca2.
Change-Id: Ie6c165e17bb3c99eebc967a6bb02529db8bdfc98
In handover decision 2, choosing an lchan to move so far takes into
account only the absolute current rxlev, and it fails to look at the
*difference* in rxlev between source and target cell.
My recent feature to favor freeing half-used TCH/H does in fact not work
well. The main reason why the test for that feature passes is that all
lchans in the test get identical measurements -- which is unrealistic.
A test with differing ratings uncovers the flaw in comparing intra-cell
candidates.
Related: SYS#5032
Change-Id: Iabce1ab44b496833c19d999fc3f2903d835c357f
The aim is to pin the current basic behavior of handover decision 2,
before modifying the algorithm conditions to fix some bugs in upcoming
patches -- so far no test ensures this particular detail.
Change-Id: I68cdda21ef59c464f0af3c2eee356623e58ea1cd
Some tests want to repeat the same measurement report, typically 10
times to fill the averaging window. Instead of 10 lines saying
'meas-rep ...', allow 'meas-rep repeat 10 ...'.
Change-Id: Ib2fa81a449fb73ec7c458b0e6877d6561c79a846
In handover_decision_2.c, instead of repeating a similar loop four
times, put that loop in a function and parameterize it.
Prepare for a fix of two problems in handover decision 2, see
I2704899c85c35dfd4eba43468452483f40016ca2.
Change-Id: I7c32d08e490a88a7f044b0a71dc4b07d748dd572
An upcoming test that uses set-ts-use to release used lchans uncovered
an incomplete release, keeping the lchans occupied due to a missing
release ack. Always ack the release.
Change-Id: Ia22906bfbfcc48b7bd08473a2b17f6b0554687d3
We decided not to keep the handover_test script expected outputs
(osmo-bsc's logging output) in the source tree. Hence do not fail the
handover_tests when the output differs, just show a diff (if at all).
Change-Id: I3e9e123b41be71d1fcd9576b0bd38d2fd32353b4