Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I4d48c0c0aa46065560a020369e3b0544385f173e
Related: OS#5034
Name both new tests with suffix '_2' even though the first h_to_f does
not exist (yet?), to indicate the complementary nature of those two
tests.
Related: SYS#5301
Change-Id: I8c8d9d5936f713f7d02e4246eeb373916e62510b
When balancing congestion, not only look at TCH/F or TCH/H separately,
but also to take into account the effects on the other TCH kind from
using/freeing dynamic TS.
Related: OS#5298
Change-Id: I433df6f343650f9056b1bab926bc19ac1d867ad5
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
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
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
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
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
Presence of these lines in the config file does not necessarily mean
that the BTS will not perform measurement pre-processing. It actually
means that the BSC would not include the optional IEs related to the
measurement pre-processing, so the BTS may still apply its default
averaging algorythm with default parameters.
In order to avoid potential confusion, let's avoid printing them.
Change-Id: I585b5bf4fde93d66e47666e0fa9903f21a268b51
Related: SYS#4918
Before the recent changes, the MS Power Parameters IE would always
be included empty in RSL CHANnel ACTIVation messages iff the BTS
type is 'osmo-bts'. Then this behavior was changed, so the user
would need to enable dynamic power control explicitly.
This is a regression, let's revert it back to the old behaviour.
Change-Id: Idb453fc894584ccf4f5f8b45a24421db958e9478
Related: SYS#4918
According to 3GPP TS 45.008, section A.3.2.1:
c) Comparison of RXQUAL_XX with L_RXQUAL_XX_P (XX = DL or UL):
Increase XX_TXPWR if at least P3 averaged values out of N3
averaged values are greater (worse quality) than L_RXQUAL_XX_P.
d) Comparison of RXQUAL_XX with U_RXQUAL_XX_P (XX = DL or UL):
Decrease XX_TXPWR if at least P4 averaged values out of N4
averaged values are lower (better quality) than U_RXQUAL_XX_P.
Given that RxQual is a value in range 0 .. 7, where 0 is the best
and 7 is the worst: L_RXQUAL_XX_P must define the worst quality,
while U_RXQUAL_XX_P must define the best quality value.
Change-Id: I0f37b23ed360782f3c1f4275234c4e18a17aa89b
Related: SYS#4918
The meaningful names expose that some of those tests are apparently
quite similar.
With names like this it is far easier to see whether a specific scenario
is already tested or not, and find a test when looking for a specific
scenario.
Change-Id: I6f6d65d818fd1265e8ff94a2e0afba6392c50eb9
The handover_fsm activates voice on a target lchan only when the source
lchan has an osmo_mgcpc_ep_ci pointer for the BTS side. Since that
struct is opaque, set a fake pointer and override the
osmo_mgcpc_ep_ci_name() function so that the pointer is never
dereferenced.
This more accurately models the RTP stream setup events during handover.
Change-Id: Ibc22001bf9e9874dd3f44f0acac8b6a4c1069aa7
Do not show source file and line numbers in the log, so that the log
output remains unchanged for unrelated changes.
Also show the log level.
Change-Id: I8ebcaf16cd14881a3a41616dcff175e173db9ae8
So far we skipped the HO Detection message, because the FSM also accepts
a handover when the Handover Complete arrives without a Detection.
Rather model the real behavior.
Also send the EST IND message and RTP-ready events from the ho
detection.
Change-Id: Ib676e74f23ef9cd1b55262117822b0e110013bdc
Drop the string arrays, and move the 32 handover tests to separate
script files. Instead of the peculiar implementation and instead of
cryptic commands, implement the handover test scripts as a VTY.
handover_test.c now sets up a VTY with handover testing VTY commands. It
also features the complete and unabridged VTY configuration nodes of
osmo-bsc itself. That allows dropping various ho script commands.
Before:
static char *test_case_14[] = {
"Handover to congested cell, if RX level is below minimum\n\n"
"The better neighbor cell is congested, so no handover is performed.\n"
"If the RX level of the current cell drops below minimum acceptable\n"
"level, the handover is performed.\n",
"create-n-bts", "2",
"create-ms", "0", "TCH/F", "AMR",
"expect-ts-use", "0", "0", "*", "TCH/F", "-", "-", "-", "-", "-", "-",
"set-min-free", "1", "TCH/F", "4",
"set-min-free", "1", "TCH/H", "4",
"meas-rep", "0","0","1","0", "10","0", "1","0","30",
"expect-no-chan",
"meas-rep", "0","0","1","0", "9","0", "1","0","30",
"expect-chan", "1", "1",
"ack-chan",
"expect-ho", "0", "1",
"ho-complete",
"expect-ts-use", "0", "0", "*", "-", "-", "-", "-", "-", "-", "-",
"expect-ts-use", "1", "0", "*", "TCH/F", "-", "-", "-", "-", "-", "-",
}
After:
# Handover to congested cell, if RX level is below minimum
# The better neighbor cell is congested, so no handover is performed.
# If the RX level of the current cell drops below minimum acceptable
# level, the handover is performed.
create-n-bts 2
set-ts-use trx 0 0 states * TCH/F - - - - - -
network
bts 1
handover2 min-free-slots tch/f 4
handover2 min-free-slots tch/h 4
meas-rep lchan 0 0 1 0 rxlev 10 rxqual 0 ta 0 neighbors 30
expect-no-chan
meas-rep lchan 0 0 1 0 rxlev 9 rxqual 0 ta 0 neighbors 30
expect-ho from lchan 0 0 1 0 to lchan 1 0 1 0
expect-ts-use trx 0 0 states * - - - - - - -
expect-ts-use trx 1 0 states * TCH/F - - - - - -
Note how osmo-bsc's stock vty config nodes seamlessly integrate in the
test steps: just enter a configuration node, modify some values, and
indenting trivially takes care of exiting nodes correctly.
Running a test manually:
./handover_test test_0123.ho_vty
Instead of calling each test separately in testsuite.at, have a
handover_tests.sh script that picks up new tests just by presence of
files named test*.ho_vty.
Rationale:
It was considered to move handover tests to the TTCN suite, but there is
an advantage in having these C tests: they run super fast and catch bugs
even in the gerrit verification job, potentially saving a lot of time.
It is a reality that I need more of these tests, for dynamic timeslots
and TCH/F <-> TCH/H switches. The way the handover tests are written, as
arrays of strings containing cryptic fixed-argument script commands, has
been a pain to work with from the start, and now I am no longer willing
to endure that pain.
Change-Id: Ie238ebe41039d3fa44c9699937589e000883e052
Pau Espin
Pau Espin Pedrol
Vadim Yanitskiy