Similar to paging:attempted, count paging:expired not only per BTS, but
also for the whole BSC. Add active_paging_requests to struct bsc_subscr,
to increase the counter only once if paging expires, and not once per
BTS where paging expired.
Related: SYS#4878
Change-Id: I9c118e7e3d61ed8c9f1951111255b196905eba4d
osmo-trx-uhd with a B200 has proven to provide bad (lower than usually
considered good) C/I values due to high noise (even with band filters in
place). Hence, default thresholds (gathered from literature on the topic)
are too high and end up in bad algorithm output decisions.
Furthermore, most users of Osmocom don't use it in densely populated
areas, hence RXLEV based algorithm used when C/I based one is disabled
is good enough.
Let's disable C/I based one by default, and let advanced users which
specific needs to enable and confiure thresholds specifically for their
needs (hardware, cell surrounding conditions, etc.).
Related: SYS#4917
Change-Id: If1a73c60695379bcfcd0f44c6ec6dd659563e279
abis_nm locally declares its own struct for the ipaccess firmware
header, even though libosmocore defines it as well. Lets use the
definition from libosmocore.
Change-Id: I69cb45fc40bd20ea2533cc8cd6a68363b59cc408
The function generate_ma_for_bts() is called when the OML TEI comes up.
In the same code path boostrap_bts() is called as well. It would be more
logical to call generate_ma_for_bts() from boostrap_bts() since it is
also part of the bootstrapping process.
Change-Id: Ib2ed5b1eac3701cfb3a3e8dd478488ba5404d1fd
Related: SYS#5369
At the moment check_bts and bootstrap_bts is called only once on startup.
When a new BTS is set up during runtime bootstrap_bts, nor check_bts is
called. This means that some parameters of the BTS stay uninitalized
until osmo-bsc is restarted. Lets rather call check_bts() and then
bootstrap_bts() when the OML TEI of the BTS comes up.
Change-Id: Ie599f809623efd6ea4ab3f39294195fc1ef84b85
Related: SYS#5369
Let's have a short and consistent naming for both ACCH repetition
and temporary ACCH overpower structures, like it's done in osmo-bts.
Change-Id: I39b98dcd14219402959646524315d5afea7c08cf
Related: Ib1d51f91139b4c2fe794e37fc8543b2d7a9b9c07
Let's have a short and consistent naming for both ACCH repetition
and temporary ACCH overpower structures, like it's done in osmo-bts.
Change-Id: Ia12c83ad1af4744ce28ba655ac806784f746e88a
Related: Ib1d51f91139b4c2fe794e37fc8543b2d7a9b9c07
The linter (executed by Jenkins) complains:
src/osmo-bsc/bts_vty.c:653: ERROR:CODE_INDENT: code indent should use tabs where possible
src/osmo-bsc/bts_vty.c:654: ERROR:CODE_INDENT: code indent should use tabs where possible
src/osmo-bsc/bts_vty.c:656: ERROR:CODE_INDENT: code indent should use tabs where possible
src/osmo-bsc/bts_vty.c:657: ERROR:CODE_INDENT: code indent should use tabs where possible
and blocks changes, adding V-1 when I am changing the related code.
Change-Id: If3c8c09ddff7cb945425e74344ceb4da989ddffc
The linter (executed by Jenkins) complains:
src/osmo-bsc/abis_rsl.c:543: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
and blocks changes, adding V-1 when I am changing the related code.
Change-Id: I0cf00ff898e69734850659e8ba0e2ff023f9b2dd
In the case of ts->pchan_from_config=GSM_PCHAN_OSMO_DYN,
ts->max_primary_lchans will be 8 due to SDCCH8 support, and we don't
want to set lchan->vamos.is_secondary=true for lchans at the end of the
array.
Related: OS#5278
Change-Id: If86af5fafe059d5e830c1f6d37034f7325d9a96c
The function set_bts_loc does not check the string pointers resturned by
strtok_r. In this particular case this is not a problem because the
function set_bts_lock will only see verfied input. However, lets check
the results anyway to avoid creating false positives in coverity scan.
Change-Id: Ie21c392e0405fc45811c6d55bf5508e9eb6784de
Fixes: CID#240849
In order to be able to call check_bts() and bootstrap_bts() from
inp_sig_cb(), we must move it below bootstrap_bts.
Change-Id: I1a365bc2278368ec1f5c0db3f3e466b124b16e83
Related: SYS#5369
The function bootstrap_bts does a few checks before it does the actual
initialization. To make the code more modular, lets split the function
into two functions, check_bts and bootstrap_bts. Also be sure that we
print the BTS number when the check failes.
Change-Id: Id2b26f147d2f35e156e2da8ee58d2bbbb93de4ac
Related: SYS#5369
The function bootstrap_bts verifies that the ARFCN number is within the
valid range of the current band. In case of error it prints that the
ARFCN is out of range, but it does not print the BTS number, nor the
ARFCN number.
Change-Id: I432448b4bd5ea1a209838a6c5105cc1e9f7d80ee
Same as all_allocated:{sdcch,tch}, but already trigger when all
non-dynamic timeslots are allocated.
Related: SYS#4878
Related: Ib3997a827c9cc43d1361bb0cf3bfab9f6d91bf82 (osmo-ttcn3-hacks)
Change-Id: I2fa14531f16d3f07085620f1c50eb839c420da6a
This is a candidate for adding to libosmocore (as osmo_time_cc), but
let's first use this in osmo-bsc to make sure that it works as intended.
I started out expecting to be done with this in half an hour, but I
found out that accumulating elapsed time to an integer counter has a
staggering amount of complexity to it, and a million pitfalls.
The intended use is to report allAvailableSDCCHAllocated and
allAvailableTCHAllocated performance indicators in OsmoBSC. Hopefully
this will also be generally useful elsewhere, to be worth the effort.
Related: SYS#4878
Change-Id: Icdd36f27cb54b2e1b940c9e6404ba9dd3692a310
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
Improve the current VTY support to allow enabling/disabling C/I logic
independent from value setting. This way C/I support can be quickly
disabled & enabled.
Reminder: changing power parameters still require VTY Command "bts NR
resend-power-control-defaults" to be excuted prior to new parameters
being applied on the BTS.
Related: SYS#4917
Change-Id: Id1224c2d9a52db2ed805c49e048d3086ed0167f5
assignment_fsm_allstate_action is only used in module assignment_fsm.c,
so lets decalare it as static
Change-Id: I90d6c11bd485e3be80efc7f146e0129d93e18458
This fixes call setup issues when more than ~1km from the tower.
NOTE: We use the last reported TA from the UE in the CHANnel ACTIVation.
When the UE is more than 1km from the tower, (unshifted) TA in the
measurement report can be 8 or greater. Once we send TA of 8 in the
CHAN ACTIV message, the lchan is unrecoverable.
Change-Id: I1c9bd5bf2fd126e62bcbec419f3499d2e0465559
Setting LOWER_CMP_N and UPPER_CMP_N for all channel types can be quite
cumbersome and end up in lengthy config files. Let's instead add a
placeholder command to apply it to all channel types of a BTS at once.
This is useful specially since a user disabling C/I capabilities
probably does so because it may require a fair amount of fine-tuning
parameters to have it working perfectly. Hence, a user not willing to
spend time configuring those parameters correctly (and for which default
ones doesn't work properly) will require quick way to get rid of C/I
based MS Power Control Loop. By disabling C/I comparison, osmo-bts will
rely on RxLev only when applying the MS Power Control Loop, which is
fine for non noisy environments.
Related: SYS#4917
Change-Id: I0e1a1a9228a15e9ec9c41b7952b03e1d25309706
Completely describe the 'rf_states' string elements (in one place), and
fix the missing <rsl_status> item in bsc_ctrl_commands.c comments.
Related: SYS#5542
Change-Id: Ifc3610c344b3e270111e2f6c5155a6fb90d8f2ac
Add per-TRX command to lock/unlock single TRX.
(Besides the global root-node rf_locked command setting the global RF
policy.)
Corresponds to VTY command: 'bts N' / 'trx N' / 'rf_locked (0|1)'.
Related: SYS#5542
Related: I2bb5096732f75a7341c7e83951e63c5a2038b469 (osmo-ttcn3-hacks)
Depends: I4dac826aab00bc1780a5258b6b55d34ce7d50c60 (libosmocore)
Change-Id: Ie46fd730797b64fb185d705c3507e36f5f23ef4b
These commands return a listing of OML state, RF policy as well as RSL
connection status for each TRX in the form:
<bts_nr>,<trx_nr>,<opstate>,<adminstate>,<rf_policy>,<rsl_status>;<bts_nr>,<trx_nr>,...
For example, the root node 'rf_states' may return:
0,0,operational,unlocked,on,rsl-up;1,0,operational,unlocked,on,rsl-down;2,0,inoperational,locked,on,rsl-down;
A 'bts.N.rf_states' returns the same form of string, but lists only the
TRX for the given BTS nr.
Note, there is already a CTRL command 'bts.N.rf_state' (singular
'rf_state', not plural 'rf_states'), which only reflects the overall
status of all TRX combined. This new command has per-TRX resolution.
The rf-policy is so far always looked up in the global gsm_network flag,
as does the old 'rf_state' command; see osmo_bsc_rf_get_policy_by_bts()
which does not depend on the specific BTS at all. This may be worth
revisiting in the future, so I am already including the rf-policy in the
rf_state string for each TRX, even though it is globally identical.
Related: SYS#5542
Related: I01e6f391a5e71b0606c42be9b57f8a1687d59bcb (osmo-ttcn3-hacks)
Change-Id: I14fa2678fc8f2c11a879c5e9615ac552782c5b7e
TS 45.008 section 4.7.1:
"""
Upon receipt of a command from an SACCH to change its power level on the corresponding uplink channel, the MS
shall change to the new level at a rate of one nominal 2 dB power control step every 60 ms (13 TDMA frames), i.e. a
range change of 15 steps should take about 900 ms. The change shall commence at the first TDMA frame belonging to
the next reporting period (as specified in subclause 8.4). The MS shall change the power one nominal 2 dB step at a
time, at a rate of one step every 60 ms following the initial change, irrespective of whether actual transmission takes
place or not.
"""
Since the reported MS_PWR in L1 SACCH Header is, according to specs, the
one used for the last block of the previous SACCH period, it becomes
clear the first SACCH block after a requested MS Power Level change by
the network may contain mismatches between the announced MS_PWR by the
MS and the measured Rxlev/RxQual. Hence, let's better use a
P_CON_INTERVAL of 1 which retriggers the MS Power Control Loop every second
SACCH block.
Related: SYS#5371
Change-Id: Iade5b597e0e56b07c6d78995fcec7c641e4e643f
While NACC was initially developed, it became clear there was need for
a way to interact PCU<->BSC in order resolve ARFCN+BSIC into CGI-PS
for later RIM usage.
Hence, this resolution was first (until today) implemented using an out
of bands RPC system using the CTRL interface, which required specific
config to be written and matches in osmo-pcu and osmo-bsc VTY (ip+port
of the CTRL interface to use).
However, this has several shortcomings:
* As explained above, specific configuration is required
* Since recently, we do support BSC redundancy in osmo-bts. Hence the BTS
may switch to a BSC other than first one. If that happened, that'd mean
the CTRL interface would still point to the initially configured one,
which may not be the same currently serving the PCU.
During recent development of ANR related features, a similar need for
PCU<->BSC was required, but this time it was decided to extend the IPA
multiplex of the Abis OML connection to pass PCUIF messages,
transparently forwarded to each side by the BTS.
This has the advantage that connection PCU<->BTS is handled by BTS and
both sides send messages transparently.
Let's switch by default to using this new interface, while still
maintaing the old way for a while (announcing them as deprecated) to
avoid breaking existing deployments until they are upgraded to new
versions of osmo-pcu and osmo-bsc.
Change-Id: I9073a121564503f483c84263ac72476041e47c03
Related: SYS#4971
So far we were inherting the bs_power in used when activating an lchan
for an MS for which we already had previous lchan. For instance, when an
MS is first assigned an SDCCH, and later on, it is assigned a TCH to
place a voice call.
Doing so is, however, not correct because current and old lchans may be
placed on different TS or even on different TRX, which means they will
have different BS Power restrictions. In the scenario described above,
for instance, an SDCCH could have been assigned on C0 and hence have
a bs_power of 0, and later on, whenever the TCH lchan as created, it
would have inherited the C0 bs_power despite it may have been possible
to use a different (lower) max bs power.
Furthermore, the lchan->bs_power_db basically stores the *maximum* bs
power reduction. Hence it makes not sense at all to copy over the value,
since it is anyway not updated from MS measurement reports so far
anyway.
Fixes: 997a257f8d
Related: SYS#4919
Change-Id: I4a7736aa9a1395e0cc118b98b69896bd0f1e94e6
A previous commit (Feb 05 2021) moved copy of TA value to some other
place to fix some related issues, but forgot to update the comment.
Fixes: b03e73f27b
Change-Id: Ia10038919b6650dff45b7233f58fea94e9808712
Testing has shown that the Training Sequence Code in pre-chan-ack mode
is inaccurate (only worked with a BSIC that incidentally yielded the
same TSC value as the wrong TSC value sent in the IMM ASS msg).
Move the code setting the correct TSC and TSC-Set to the first stage of
channel activation (lchan_fsm_wait_ts_ready_onenter()) so that it is
available for both pre-chan-ack and pre-ts-ack Early-IA modes.
Have a separate function for setting the preliminary values requested in
Channel Activation (lchan->activate.*) into the accepted operative
places (lchan->*). Call this early for early-IA modes.
Hence the TSC and TSC-Set used in the early IMM ASS message is now the
correct one, and the same as sent during Channel Activation.
There shouldn't be any, but if there are other values besides TSC
suffering from the same problem, they are now also set to the right
values before sending IMM ASS early.
Related: SYS#5559
Related: I4479244b0c53648e62e84e1ebf986f51d659484f (osmo-ttcn3-hacks)
Change-Id: I9f26074154600d854a0b3baee2f38a6666f4cb56
bs_power_db, as its name suggests (also check vty code and
rsl_tx_chan_activ()) contains value in dB, not in 2dB steps.
Change-Id: I76bd6bb1b307ab75ba1292865747419228e0687a
This commit extends existing VTY and RSL infrastructure to configure and
manage MS Power Parameters used in MS Power Control loop, by adding
support to set up Carrier-to-Interference (CI) parameters.
Using C/I instead of existing RxQual is preferred due to extended
granularity of C/I (bigger range than RxQual's 0-7).
Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance"
Table 10.3) provides detailed information about expected target values,
even different values for different channel types. Hence, it was decided
to support setting different MS Power Parameters for different channel
types.
These MS Power Parameters are Osmocom specific, ie. supported only by
newish versions of osmo-bts. Older versions of osmo-bts should ignore
the new IEs added just fine. The new IEs containing the MS POwer
Parameters are not send for non osmo-bts BTSs, hence this commit is
secure with regards to running osmo-bsc against an ip.access BTS such
as nanoBTS.
Related: SYS#4917
Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca
Change-Id: I7e76ec47b323d469f777624b74b08752d1f5584f
So far we have stat items per BTS. Add stat items summing overall BTS
status.
Add stat items:
- num_bts:oml_connected
- num_bts:all_trx_rsl_connected
- num_bts:total
- num_trx:rsl_connected
- num_trx:total
Related: SYS#5542
Related: Ic1b35b7406547f92818afe399a2383d154576409 (osmo-ttcn3-hacks)
Change-Id: I2057a798e681a169cc03243a09b3d6449734c010
The MGCP proxy which is built into osmo-bsc is used to tunnel MGCP
messages through an SCCP-lite link. This is an SCCP-lite specific
implementation detail that is not present in SCCP/AoIP.
Change-Id: Id3a8c45ae38d6b9d9c106a9e83b3cbfff919650d
Related: SYS#5091
Since the libosmo-mgcp-client now supports MGW pooling, lets use this
feature in osmo-bsc. Large RAN installations may benefit from
distributing the RTP voice stream load on multiple media gateways.
Depends: osmo-mgw Icaaba0e470e916eefddfee750b83f5f65291a6b0
Change-Id: I8f33ab2cea04b545c403a6fe479aa963a0fc0d0d
Related: SYS#5091
To configure temporary overpower, new VTY commands are added. This patch
also addes the logic needed to attach the temporary overpower IE to the
RSL CHANNEL ACTIVATE message.
Change-Id: I488a91bb4ed86f630db56564a0cd293f39f0f690
Related: SYS#5319
TSC was initially set to -1 (to be picked by callee), but erased when
using designated initializers later on in the function, hence TSC being
set to 0. As a result, TSC 0 would be requested to the BTS, which may
have configured a different BSIC containing BCC!=0.
Related: OS#5219
Change-Id: I26813561ee9e7783a4004f32225f19296bd6319c
We already have MSC connection stat items, but for hysterical raisins
there are separate such stats for each MSC. Hence we have N connection
counters, each being either 0 or 1, for a single MSC.
Add a new stat counting the *overall* MSCs that are connected,
and one indicating the total number of configured MSCs.
Related: SYS#5542
Related: I178dcf4516606aa561d47b06061b8a416d3c40cf (osmo-ttcn3-hacks)
Change-Id: If76bbf9b3adb64c68d5c31c6b526fa71a99996ae
Instead of having static const structs in header files (which end up
duplicated in each and every compile unit!), have one .c file with the
rate_ctr and stat_item descriptions.
Related: SYS#5542
Change-Id: I8fd6380b5ae8ed2d3347e7cfbf674c30b6841ed9
Allow resetting the BSSMAP link from VTY, for BSC_Tests.ttcn.
In the field, detecting that an MSC is lost is done by getting three
connection failures in a row. For the BSC_Tests, it is easier to just
provide a VTY command to reset an MSC's link status.
I want to add tests that verify the stat items reflecting the MSC
connection status. To be able to run a test expecting fewer connected
MSC after a test that launched more MSCs requires the links to be reset.
Related: SYS#5542
Related: Ice3056dc46c94f9399f8379db7aeb7193782f2f2 (osmo-ttcn3-hacks)
Change-Id: I1975941b790d2b30d0904d41e456220cba26ecff
Some UMTS capable phones (such as SE K800i) send this message
together with the 'normal' RR Classmark Change, what makes
osmo-bsc log the following warning:
DCHAN NOTICE gsm_04_08_rr.c:1037
lchan(0-0-1-SDCCH8-0)[0x562ea76d3ab0]{ESTABLISHED}:
(type=SDCCH) Unknown RR message: UTRAN Classmark Change
We don't handle it, so just ignore without logging anything.
Change-Id: Icb8e44c9a06519ead9c3dc9308788c23505d4bb1
Add explicit indexes like [BSC_STAT_NUM_BTS_TOTAL] = { ...
BSC_STAT_NUM_BTS_TOTAL == 0 and the first item of bsc_stat_desc of
course has index 0, but when grepping the code, it looks like
BSC_STAT_NUM_BTS_TOTAL is missing a name definition.
Same for MSC_STAT_MSC_LINKS_ACTIVE and MSC_STAT_MSC_LINKS_TOTAL.
Related: SYS#5542
Change-Id: Ie47e0857c41d517a9b37be96f6669d1825d24a6d
Add experimental 'pre-ts-ack' to the 'immediate-assignment' options:
send the IMM ASS even before a dynamic timeslot is switched. This
possibly saves an Abis roundtrip, but may be racy.
When pre-ts-ack is chosen, already do the IMM ASS before the dyn TS
pchan switch is ACKed.
In Immediate Assignment, in case the dyn TS is not ready yet, get the
pchan kind from lchan->type, which already reflects the target type, and
not from ts->pchan_is, which still reflects the previous pchan type.
Related test is in I2ae28cd92910d4bc341a88571599347a64a18fe5
Related: SYS#5559
Change-Id: I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74
When 'immediate-assignment pre-chan-ack' is set, send the Immediate
Assignment directly after the Channel Activation, not waiting for the
Activation ACK, to save an Abis roundtrip.
Related test is in If71f4562d532b6c5faf55f5fd073449a8a137ebf
Related: SYS#5559
Change-Id: I56c25cde152040fb66bdba44399bd37671ae3df2
This patch adds only the VTY config option without any effect, to ease
patch review.
The implementation follows in I56c25cde152040fb66bdba44399bd37671ae3df2
The new config option is written so that further variants of Immediate
Assignment sequencing may be added easily.
See also I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74.
Related: SYS#5559
Change-Id: I710343d1728153faf3db9758ff5a1ef26bb8d3d4
Looking for a bug, I spread this logging to understand what was
happening. Might as well keep it.
Related: SYS#5559
Change-Id: I46b660cd51a41e561712a0bd849ce0ee8d1a9588
The function gsm48_lchan2chan_desc_as_configured() dups
gsm48_lchan2chan_desc() with merely a different pchan type
(ts->pchan_from_config instead of ts->pchan_is).
In an upcoming patch, I would like to do the same, just with yet another
pchan value (derived from lchan->type, because that reflects the channel
type even before a dynamic timeslot switched its pchan type).
So replace gsm48_lchan2chan_desc_as_configured() by
gsm48_lchan_and_pchan2chan_desc() with explicit pchan arg;
also call this from gsm48_lchan2chan_desc(), reducing code dup.
gsm48_lchan2chan_desc_as_configured() had more concise error logging.
Absorb that into the new gsm48_lchan_and_pchan2chan_desc().
Add gsm_lchan_and_pchan2chan_nr(), like gsm_lchan2chan_nr() just with
explicit pchan arg, to be able to pass the pchan down from the new
functions mentioned above.
Related: SYS#5559
Change-Id: I67f178c8160cdda1f2ab5513ac4f65c027d4012f
The bottom of the function changes the lchan state. If a failure branch
is reached, that should no longer happen. Change 'break' to 'return' in
four places to not mix up the channel release.
Related: SYS#5559
Change-Id: I4674752ab4f1c8e8147ef3366f90e9ea2abd5aec
The option -l ("The local address of the MGCP") is still present in the
commandline help and the manual, but it is used nowhere and osmo-bsc
exists when it is used. Lets remove it.
Change-Id: Ia295f4414e0d6e78b388c0c72f1a5b8df8bc3d7e
The if conditions for logging an lchan change made it look like
new_lchan might actually be NULL, which it never is. So rather pin
new_lchan as non-NULL with an assert and simplify the logic.
Related: CID#237146
Related: b0d854556d
Change-Id: I8859c6cb9b3b15287e339ce4b6815b946965d0d9
The previous naming was confusing since when appearing on log files it
seemed to mean the reason was mainly only call reestablishment, when it
actually means either call establishment (the usual reason) OR call
re-establishment (should happen seldomly).
Let's add some parenthesis to make it clearer.
Related: SYS#5548
Change-Id: Id2dccd71803335c284a5ba271fa7f7890d253c27
In the command
bts <0-255> trx <0-255> timeslot <0-7> sub-slot <0-7> deactivate fr
the final argument indicating the channel type does not make sense and
is not actually used. Define a separate vty command for 'deactivate', so
that it doesn't require arguments only used for 'activate'.
Change-Id: Ibdeca3b1d75b9f6092f566544e9d5f4da67fffce
For a call re-establishment, the MS shows up on a different cell and
requests CM Re-Establishment (3GPP TS 24.008 9.2.4). As soon as the
Layer 3 is established, the MSC will clear the first A-connection; the
re-establishment *has* to happen on a new separate A-connection. So for
a brief moment we must allow two distinct A-interface connections to be
used for the same subscriber.
Tested by BSC_Tests.TC_cm_reestablishment
added in I1e7d446644f46b8a0a94688e618ffb4f23a8900e
Related: SYS#5130
Change-Id: I2da9a971dd36c4289a78040adfe85704c8282c59
Usual allocation mechansim, when some signalling channel is needed,
first tries to reserve an SDCCH, and if all of them are exhausted, then
attempts to reserve a TCH as a last resort.
This, however, may cause TCH starvation under certain situations, for
instance if there high load on other services (LU, SMS, etc.).
Hence, it may be desirable for the operator to forbid reservation
of TCH slots once SDCCH become exhausted. This commit is thus adding a
VTY command which allows forbidding it. The default behavior (allow using
TCH timeslots when SDCCHs are exhausted) is kept as before.
The above mentioned prohibition is applied only to non-voicecall related
signalling services. That's because voicecall services will end up
requiring a TCH anyway, and forbidding reservation of TCH straighaway
when SDCCHs are exhausted would mean no voice calls could be initiated
while still TCHs would be available.
Related: SYS#5548
Change-Id: Ib08027125145df26602069bfb51847063b0ccc0c
Every time a new file is added in osmo-bsc, it ends up being a pain
because its .o file has to be included to other tests/util binaries, or
stubs need to be added.
Let's instead bundle all .o files together in an .la file and pass that
around.
Change-Id: If91dc589ea1e476da105b58846d1c3e720a439e1
Adds gsm_bts_stats_reset() to clear the stats and calls it from the
different models.
Change-Id: Ic42687cd73e3546edaa99fb1268a5960ffa43b12
Related: SYS#5541
If the RES IND message is invalid, let's not return ENOENT which
translates to "No such file or directory", instead return EINVAL.
Related: SYS#5313
Change-Id: Ifd700e90c881874d428f2860603a4ddbf13d705e
If all channels of a BTS are in use and there are no interference
ratings to be reported, the Resource Information IE may be empty. Do not
log this as an error, it is not something that needs operator attention.
Related: SYS#5313
Change-Id: I75b851ef1269674f43db3fb3a48518e76182d7f0
As seen in osmo-bsc log:
DCHAN ERROR abis_rsl.c:2287 lchan(12-0-2-TCH_H-1){BORKEN}: Event LCHAN_EV_RLL_REL_IND not permitted
Related: SYS#5523
Change-Id: Idc7796d41f3483c89559746d9a00fdf32bf67c57
We already looked it up, it's not necessary to look it up again by
calling lchan_select_by_type(). Let's instead call
lchan_select_set_type() directly on the lchan pointer.
Related: SYS#5309
Change-Id: I1054c18f58c9e249f263e3e97a365a1fd8b03a93
It's an easy helper, but it helps in standarizing and finding similar
places in code.
Morevoer, it will be used in follow-up commit where we first use
lchan_avail_by_type and finally we select it in a later stage.
Change-Id: I025a40962a5e5d40543b297a0760e47618fb525c
The VTY handover_vtc.c offers a large number of handover specific
settings. Those settings are (with one exception) auto generated using
macros. Lets add an equivalent for the control interface that uses the
same auto generation mechanisms.
Change-Id: I12f143906818fd6b16e8783157cbb1eb51e49ffc
Depends: libosmocore I53fc207677f52b1dc748b01d58424839cdba807c
Related: SYS#5369
The VTY defun already indicates BSC_VTY_ATTR_RESTART_ABIS_OML_LINK
correctly, but so far we would immediately start using the new values
internally, and wrongly interpret interference levels. Fix that.
Have bts->interf_meas_params twice: interf_meas_params_cfg for the VTY
configured values, and interf_meas_params_used for the values that the
BTS actually knows about, after they were sent via OML.
In a running BSC, when changing the interference level boundaries on the
telnet VTY, the BTS is not immediately told about the change. That would
require a BTS restart. Hence store the cfg values separately in
interf_meas_params_cfg. For comparing/printing interference levels in a
running BTS, only employ the values that were actually sent via OML and
placed in interf_meas_params_used.
Related: SYS#5313
Change-Id: Iad8cf4151ff7f86dc0549158ed5d91d788d40b1f
This commit improves some cosmetic and logical aspects from recent
commit (see "Fixes" below).
* Fix typo s/free_tcch/free_tchh/"
* Improve some comments
Fixes: fdb87343d7
Change-Id: Id6217c929068b0182cb2d4a9922bfbf544c8c75d
Hold off re-assignment after an intra-cell re-assignment due to low
rxqual.
Adjust test_amr_tch_h_to_f_rxqual.ho_vty to show the changed behaviour.
Related: SYS#5198
Change-Id: Id00a07313fe04eec509b336c0637b59c707760e0
To be able to add a fake time to handover tests, the penalty timers need
to use an osmo_* time source.
There already is a fixme comment rightfully asking for a monotonic
clock, so this change is overdue anyway.
An upcoming patch will prove that this works:
"handover tests: test passing of penalty timeout"
I65e59cc7309778cf9d71612669ce84d101c8135e
Related: SYS#5198
Change-Id: Ifb1ab3165db50511aed4f65aa445798367d7e19e
In an upcoming patch, handover_decision_2.c will use this indicator to
decide whether to start a penalty timer:
"hodec2: add low-rxqual-assignment penalty timer (2/2)"
Id00a07313fe04eec509b336c0637b59c707760e0
Related: SYS#5198
Change-Id: I5de385e0666f716184a62e6e70d656545ac5d2ee
In case an MS requests a channel to establish a voice call, we usuually
try to assign an SDCCH to negotiate the call and finally make the MS
switch to a TCH. However, it doesn't make much sense to provoke a switch
of a dynamic TS into SDCCH8 if that would mean we end up with no TS
available for TCH at the next step close in time. In that case, we are
better assigning the TCH directly so that the full call can be
established successfully.
Related: SYS#5309
Change-Id: I3b32968949a7bdcbebf5a823359295bac51d8e08
The rach control parameter value that controls the usage of
call-reestablishment is currently hardcoded. Lets add a VTY option for
this so that we are able to configure call-reestablishment
Change-Id: Ia18c1dde4c001cb4d423f694f8bc146adfd77daf
Related: SYS#5130
In lchan_select, do not return on the first available lchan, but iterate
through all available lchans. Among those that would match, pick the one
with the lowest interference level as indicated by earlier RES IND.
Lchans that have no interference ratings are picked last.
This feature is off by default, enable per BTS with
network
bts N
channel allocator avoid-interference 1
osmo-bsc still does the same ascending/descending lchan allocation as
before this patch with the default setting of:
channel allocator avoid-interference 0
Related: SYS#5313
Change-Id: I844494092193811dfd9fa4d52983cbaed0fc9248
Store the config option whether the channel allocator should try to
avoid lchans with higher interference levels reported in RES IND.
The actual implementation of avoiding interference follows in
I844494092193811dfd9fa4d52983cbaed0fc9248
Related: SYS#5313
Change-Id: I8b62d0b41ad9e908b27713db9219e3dbc1ebaab7
call lchan_reset() after allocation, to make sure that lchan->* fields
that have a nonzero default value get initialized properly.
In particular, a future patch adds interference measurements, and an
lchan that never received any Resource Indication info should always
indicate that there are no measurements (a nonzero constant).
Related: SYS#5313
Change-Id: I700a969f5b11c21dacda9a7cad00c943dce554b3
So far handover decision 1 uses the FULL or SUBSET TDMA measurements
across all measurement reports, depending on whether the last
measurement report indicates that DTX is in use or not.
Handover decision 2 since recently uses TDMA_MEAS_SET_AUTO to choose for
each individual measurement report whether to use the FULL or the SUBSET
value, depending on each single report's DTX use flag.
Also switch handover decision 1 to heed every single report's DTX flag,
by simply using TDMA_MEAS_SET_AUTO, replacing the current decision.
Change-Id: Iebe980254b8c4a53ef9e7d720e417dc67077eff7
Add TDMA_MEAS_SET_AUTO to indicate automatic choice between FULL and
SUBSET measurements depending on DTX. So far use only in hodec2.
TDMA_MEAS_SET_AUTO looks at each individual measurement report's DTX
flag and for each report chooses FULL if DTX is not used, or SUB if DTX
is used.
The default setting for 'handover2 tdma-measurement' is still 'subset'.
To use the automatic choice, users need configure
handover2 tdma-measurement auto
Change-Id: I67dce55ccf892c8679272ee5dfedc25620f0f725
Cosmetic preparation for enabling automatic choice between FULL and
SUBSET measurements depending on DTX in handover decision 2.
Change the internal API to pass separate enums for the choices {RXLEV,
RXQUAL}, {UL, DL} and {FULL, SUB}.
Change-Id: I283e03126a6bc1f5f1b35f9801e841053edd2947
This allows quickly finding out whether the timeout is happening due to
RLL not established or whether RTP is not ready. In essence, it
indicates whether issue may be coming from MGW or from MS/BTS side.
If coming from MGW, the timer T3101 is in general not a problem and the
issue should be related to some misbehaving.
If coming from MS/BTS, T3101 may require tunning (it could be a
misbehaving of the MS/BTS too, or simply bad signal).
Related: SYS#5526
Change-Id: Ib655f71aec584962c70d84a4405d996505dff53c
As seen in osmo-bsc log during heavy load scenario:
<000f> abis_rsl.c:2171 lchan(12-2-6-TCH_H-0)[0x559b880d1f40]{WAIT_RF_RELEASE_ACK}: Event LCHAN_EV_RLL_REL_IND not permitted
Related: SYS#5523
Change-Id: Ie307872851490ae4d60c8117a5f4e2d8c2a414d6
This feature signals support to configure Osmocom Dynamic Timeslot type
as SDCCH8, on top of historically supported TCH/H and TCH/F.
The idea is that when unneeded, the TS is configured as PDCH, and as
soon as there's need for an SDCCH and there's none available, the TS is
dynamically reconfigured to SDCCH8. Once all logical channels in the
dynamic TS are released and hence becomes free, the BSC will reconfigure
it to PDCH.
Related: SYS#5309
Depends: libosmocore.git Change-Id Ifc0ca8916bd3e93e5a60a7dd7391d2588fdb5532
Change-Id: I29ac8b90168dba3ac309daeb0b6cfdbbcb8e9172
They will gain support to be activated as SDCCH/8 soon too.
Related: OS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Id5b89fe589a52ff88486435ac43809edb4b80f98
Let's make sure the null pointer is caught by the assert if ever code
ends up here with conn->lchan being NULL.
Change-Id: I404df638da6a93caa535f10fd330ea24a775bfc3
BS Power Control is not allowed on the BCCH/CCCH carrier, unless
the BTS is operating in the BCCH carrier power reduction mode.
Allow constrained BS power reduction (up to 6 dB) on active logical
channels iff BCCH carrier power reduction mode is enabled.
Take into account that the maximum power difference between a timeslot
used for BCCH/CCCH and the timeslot preceding it shall not exceed 3 dB.
Change-Id: I2cc6a86731984f586ef35b43a8d3de631f7d8a2f
Related: SYS#4919, SYS#4918
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, starting from version 13.0.0 (2015-11) there is a feature
called 'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
Introduce a VTY command to turn on and off the BCCH carrier power
reduction operation. Also introduce a CTRL command. On the
A-bis/RSL, abuse the BS POWER CONTROL message by setting
the Channel Number IE to 0x80 (RSL_CHAN_BCCH).
Currently, only osmo-bts-trx is supported. A value greater than
zero makes it reduce the power on *inactive* timeslots of the
BCCH carrier. Sending zero disables the BCCH power reduction
mode completely.
For more details, see 3GPP TS 45.008, section 7.1, and 3GPP TR 45.926.
Change-Id: I047fce33d4d3e4c569dd006ba17858467a2f4783
Related: SYS#4919
The constant is called OSMO_NRI_BITLEN_DEFAULT, NRI_BITLEN_DEFAULT does
not exist and got rendered as "NRI_BITLEN_DEFAULT" in the vty doc.
Add missing vty test for 'nri bitlen'.
Change-Id: I8af840a4589f47eaca6bf10e37e0859f9ae53dfa
If BS Power Parameters IE is present in the channel activation
message, the BTS shall employ dynamic BS power control for that
logical channel and interpret BS Power IE as the maximum value.
If the maximum value is 0 dB, then it does not make sense to send
BS Power Parameters IE to the BTS, because the power control loop
would never exceed the maximum.
Change-Id: If8507992dfd90ade1edda99b72bf2420a702ccd5
Related: SYS#4918, SYS#4919
That variable is never used after being set. Furthermore, it is being
set to the same value already stored, so there's no use in setting it
and it creates confusion.
Change-Id: Ib6ee28aa9a449992f5d3dea6df7dd2b7e30e73c9
follow-up to
0256c89187
Icac06ed554fd61bf7c4bfb1d5c3739a01f2915a4
Previous patch increased the range, but let's also allow one more
argument so that the A5 mask can be fully enabled.
Change-Id: Ie8cd753e4425d7d51397e4dddc24108fa0392de4
we recently added control commands to apply vty config files during
runtime using the control interface. However, there is no command that
allows us to store the config file modifications.
Change-Id: If17095bb86f82dd8feb86eb72c4133ea3aa1c3b3
Related: SYS#5369
msg->data_len is the total number of bytes available in the buffer,
not the actual length of the payload. Use msgb_length().
Change-Id: I35bf0827ff14e84a755c1aa24a6efc06bc7b9f9b
inter-BSC into this BSC: from BSSMAP Handover Request, parse and store
Kc128. All else is already implemented: depending on the chosen
encryption algorithm, Kc128 will end up in the Channel Activation.
inter-BSC out of this BSC: nothing is needed to support A5/4, the BSSMAP
Handover Required message does not contain any encryption related
information. The MSC already knows the chosen algorithm.
Related: SYS#5324
Change-Id: I7e9590e8c96aa50086148863ad9a2741b978e614
Receive and store the Kc128 key from MSC, and use as key sent to BTS if
A5/4 is the chosen encryption algorithm.
(A5/4 in handover will follow in a separate patch)
Related: SYS#5324
Change-Id: I7c458c8a7350f34ff79531b3c891e1b367614469
Add A5/4 to the internal mask of allowed algorithms.
(Not actually working yet, A5/4 implementation follows in other
patches.)
Related: SYS#5324
Change-Id: Icac06ed554fd61bf7c4bfb1d5c3739a01f2915a4
An upcoming patch for A5/4 would need to add a kc128 arg and reject
cause rc to gsm0808_cipher_mode(). Instead prepare for less cruft by
just having a single function.
Related: SYS#5324
Change-Id: I7f7c635943990a251ae28ae7a0d69cc3a239a154
In build_encr_info(), validate the algorithm and key presence and return
negative if errors are encountered.
At all callers, handle the error case.
An upcoming patch will add handling of Kc128 for A5/4 encryption and
also wants to return error codes. This is a preparation for that patch:
I7c458c8a7350f34ff79531b3c891e1b367614469
Notice that osmo-bsc does send the key along even if A5/0 is chosen,
this patch keeps that behavior unchanged.
Related: SYS#5324
Change-Id: I125d8aabceddd5b34cb98978cee9b6d2fc8fd0f2
'vamos' is only set to true for osmobts types, hence no need to check
that condition again.
fixup for commit d37dcb9f68
'RSL: rx and tx VAMOS Channel Number cbits for VAMOS lchans'
I957eff0d2c33ec795eda75a4bff21965b0179f73
Related: CID#236318
Related: SYS#5315 OS#4940
Change-Id: I4d9afc2996d95fdc15ee1a04e31d781b595023e3
The AFS bias actually should not apply to local cell lchans, because it
makes no sense for intra-cell considerations:
- same-cell lchans obviously have identical rxlev;
- any nonzero AFS bias thus always raises the TCH/F above the TCH/H;
- for intra-cell reassignment, the power budget hysteresis is,
naturally, not applied.
So, before this patch, setting AFS bias even to only 1 would
unconditionally move all (AMR) TCH/H lchans over to free TCH/F lchans in
the same cell.
Recent patch Id40d1cf8b58410c7d4eb87407fe8b8106e352438 implements
explicit upgrade from TCH/H to TCH/F *if* the TCH/H is experiencing low
rxqual or low rxlev, as a proper replacement for intra-cell AFS bias.
Related: SYS#5198 SYS#5365
Change-Id: I315f24123ae016887ab91666870ce252e096f90f
Make sure that the target lchan has been initialized before attempting
to reassign.
I ran into this in the VAMOS tests, forgetting to set the BTS_FEAT_VAMOS
in osmo-bts-omldummy: the vty command from ttcn attempts to reassign to
a non-initialized lchan, and aborts osmo-bsc.
Change-Id: Ia77a3312dde0e4b8df9ad2f33339266bae06439d
The RSL_CHAN_OSMO_VAMOS_MASK mask applies to the chan_nr,
but the cbits variable in rsl_lchan_lookup() is chan_nr >> 3.
So the mask didn't do its job. Now it does.
A bit embarrassing how i took the suggestion to use this mask and put it
into code without testing it. It looked good enough...
Change-Id: I005c5f319bb6f14651aeb613cdff52e79f761913
Pass flag into find_alternative_lchan() indicating that a TCH/H channel
has low ratings (rxqual or rxlev, doesn't matter).
Heed this flag in the last round, the requirement A check, and allow
candidates that have equal rxlev, if they result in an upgrade from
TCH/H to TCH/F. This allows intra-cell upgrades to TCH/F.
An important point is that this patch allows upgrade to TCH/F *without*
the AFS bias setting. See also I315f24123ae016887ab91666870ce252e096f90f.
Related: SYS#5198 SYS#5365
Change-Id: Id40d1cf8b58410c7d4eb87407fe8b8106e352438
Drop terminating newline from an assignment_fail() call which causes an
erratic line feed in logging.
Change-Id: Ib56e1f6a45c7e2c235f8ef0c8dea7151481677ab
Add VTY command to trigger an intra-cell re-assignment, also allowing to
re-assign to a secondary VAMOS lchan.
Related: SYS#5315 OS#4940
Change-Id: If006f5caaf83b07675f57e5665cfa79328da55e6
Add the Osmocom-specific extension to indicate VAMOS shadow lchans in
RSL, in lchan lookup and RSL message transmission.
Note that RR messages containing cbits (Assignment Command, Handover
Command, ...) must *not* send Osmocom specific cbits to the MS. Only the
RSL messages directed to the BTS send Osmocom specific bits.
Related: SYS#5315 OS#4940
Depends: If33c1695922d110c0d2c60d5c0136caf2587194e (libosmocore)
Change-Id: I957eff0d2c33ec795eda75a4bff21965b0179f73
It's bad to abort the program for an incompatible chan_nr. Instead of
OSMO_ASSERT(), make sure that error handling happens all they way to the
original callers of gsm_lchan2chan_nr etc.
This is also preparation to add further error causes: Osmocom specific
cbits needed for a non-Osmo BTS.
Related: SYS#5315 OS#4940
Change-Id: I71ed6437c403a3f9336e17a94b4948fca295d853
There is some odd repetition of macros with all possible subslot
indexes, but now we are using the defined macros instead of magic
numbers, making it easier to see that it is correct.
Also this allows trivially adding VAMOS cbits cases to the existing
switch() in a subsequent patch.
Change-Id: I4c6ce2f4ca999c19a58909b9adb849a3b8b6ffc8
Change gsm_lchan_name_compute() to a function that in-place updates the
lchan->name. That allows calling it numerous times with the talloc
handled internally. Rename it to lchan_update_name().
Add 'shadow' to lchan_update_name() and lchan_fsm_update_id() for VAMOS
shadow lchans, and also print the lchan index that it is a shadow for,
instead of the index in the lchan array.
When set_pchan_is() updates the VAMOSness of the lchans, call
lchan_fsm_update_id(). From lchan_fsm_update_id() also call
lchan_update_name().
This is a bit convoluted for legacy reasons. There are utility programs
and C tests using bts_trx.c but not lchan_fsm.c. lchan_update_name()
lives in gsm_data.c for that reason. This patch calls
lchan_update_name() from lchan_fsm_update_id() and not vice versa to
avoid having to add stubbed lchan_fsm_update_id() functions to all
utility programs and C tests.
We can't easily unify the lchan->name and lchan->fi->id without lots of
refactoring rippling through all those little utility programs and C
tests.
Change-Id: I7c2bae3b895a91f1b99b4147ecc0e3009cb7439a
So far there is a bunch of code setting a primary lchan in VAMOS mode.
This patch now adds the actual secondary "shadow" lchans that may be
combined with a primary lchan in VAMOS mode to form a multiplex.
VAMOS lchans are put in the same ts->lchan[] array that keeps the
primary lchans. They are at most two additional usable lchans (for a
TCH/H shadow) added to either TCH/F or TCH/H.
Keeping these in the same array allows looping over all lchans easily.
The ts->max_primary_lchans indicates the index of the first VAMOS shadow
lchan.
Related: SYS#5315 OS#4940
Change-Id: I928af99498bba488d317693f3144d4fccbbe9af3
We already send the TSC Set in the RSL Channel Activation, telling the
BTS about the TSC Set. The MS needs to be instructed of the TSC Set in
the RR Assignment Command.
The first code to actually do an Assignment to a VAMOS activated lchan
will follow in If006f5caaf83b07675f57e5665cfa79328da55e6.
Change-Id: Ibf3b6d276fadf724c16a5225c03e96a27a056153
Add function lchan_activate_set_ch_mode_rate_and_mr_config() and call it
for both plain channel activation and after a mode modify that needs RTP
activation. The AMR config was missing after Mode Modify.
Related: SYS#5315 OS#4940
Change-Id: I842fe7a14a91d1ec123cb4a3f52afe34456c03e3
lchan->activate.info.ch_mode_rate should remain unchanged, it is the
immutable request data. However, for VAMOS, we will want to
automatically see that the chan_mode is chosen correctly.
As a first step, place a mutable ch_mode_rate copy at
lchan->activate.ch_mode_rate, i.e. not in .activate.info, but in
.activate. Use that everywhere.
This is mostly a non-functional change, preparing for a subsequent patch
that adds handling of VAMOS shadow lchans.
As side effect of adding lchan_activate_set_ch_mode_rate_and_mr_config()
after MODE_MODIF_ACK (enabling the voice stream after a channel mode
modify), fix AMR config: the call to lchan_mr_config() was missing.
Change-Id: Icc9cc7481b3984fdca34eef49ea91ad3388c06fe
VAMOS shadow lchans do not exist yet, but add the indicator flag that
tells whether an lchan pointer is a primary or a shadow lchan.
In Mode Modify: based on the flag, choose a different default TSC Set
for shadow lchans; do BTS type compat checking for shadow lchan use.
Actual lchans with vamos.is_secondary == true will be introduced by
patch: 'add VAMOS secondary lchans to timeslot struct'
I928af99498bba488d317693f3144d4fccbbe9af3
Change-Id: I4072fc7703c592df699fe8e27c02df09acde0909
Put a (primary) lchan in VAMOS speech mode.
This is not yet about activating shadow lchans, this merely puts any
lchan in a VAMOS capable channel- and speech mode.
Protocol:
In RR Channel Mode Modify, send a spec conforming VAMOS channel mode as
well as an Extended TSC Set, wich adds the TSC Set to the training
sequence code value.
In RSL MODE MODIFY, send Osmocom specific extensions to indicate the TSC
Set and TSC, as well as the VAMOS channel mode; only to OsmoBTS type
cells.
- Set the Channel Mode's Channel Rate to Osmocom specific
RSL_CMOD_CRT_OSMO_TCH_VAMOS_Bm / RSL_CMOD_CRT_OSMO_TCH_VAMOS_Lm
- Add the Osmocom specific Training Sequence IE containing both TSC Set
and TSC.
(These are documented in the Abis manual.)
Implementation:
The internal API to request a Mode Modify is lchan_modify(info). Add to
this info the 'vamos' bool, set to true when the modification should put
the lchan in VAMOS channel mode or not.
When info.vamos == true, make sure the channel mode value is a VAMOS
one: in the copy of info->ch_mode_rate at lchan->modify.ch_mode_rate,
convert to the right VAMOS/non-VAMOS equivalent channel mode.
When the modification is through, set lchan->vamos.enabled
appropriately.
This patch also builds on Ic665125255d7354f5499d10dda1dd866ab243d24
'allow explixit TSC Set and TSC on chan activ / modif / assignment'
placing tsc_set and tsc values in the TSC related IEs.
Related: SYS#5315 OS#4940
Change-Id: Ibf53f4797d7491b17a33946fd7d920f038362b4c
Get rid of this artificial barrier, because Modify with active voice
stream is supported since commit
"lchan and assignment FSMs: make Channel Mode Modify more sane"
d5cb0eb8fd
I4986844f839b1c9672c61d916eb3d33d0042d747
Change-Id: I25f4a881fa32a07f97d7d6e6b812f8afc699d951
Add missing REQUIREMENT_A_TCHF to form a full REQUIREMENT_TCHF_MASK.
That allows detecting TCH/F -> TCH/H upgrades also in the requirement A
flags, where we look for any viable lchan.
Prepares for upcoming patch Id40d1cf8b58410c7d4eb87407fe8b8106e352438
which implements TCH/H to TCH/F upgrades within the same cell.
Related: SYS#5198 SYS#5365
Change-Id: Ic44615b314782423bab0ceef5810311776f92754
Fix build error:
meas_vis.c:196:16: error: 'struct gsm_meas_rep' has no member named 'bs_power'; did you mean 'bs_power_db'?
Output the value in the same format as before the change that introduced
this regression (dB / 2).
We didn't catch this regression with jenkins because meas_vis is only
built if libcdk is installed.
Related: OS#5173
Fixes: d9b7aedb ("change bs_power to bs_power_db")
Change-Id: I9ba9b491ccbde9aa14cfb14ecc551acb2bfd7674
An unintended change in default behavior was introduced in patch:
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
Ic665125255d7354f5499d10dda1dd866ab243d24
c33eb8d569
Set tsc_set and tsc = -1 for all lchan_activate_info and
assignment_request requests to actually yield the default behavior of
selecting the TSC based on the timeslot cfg or the BSIC value.
By setting tsc = 0 implicitly, the patch caused all requests to ask for
tsc 0 instead of calling gsm_ts_tsc().
For a Channel Mode Modify in assignment_fsm, pass the lchan's current
TSC to keep it unchanged.
osmo-ttcn3-hacks Id67a949e0f61ec8123976eb8d336f04510c55c01 adds a test
to verify the expected TSC in all of the activation, assignment and
modify messages. Current osmo-bsc master fails, this patch fixes.
Related: SYS#5315 OS#4940 Ic665125255d7354f5499d10dda1dd866ab243d24
Change-Id: If12df11511fe22ea167782f776736a1a9c484b1f
A side effect is that the final cleanup part of that function is now
always called, also when num_cell == 7.
(Whether we should really clear that logging context at that place is a
different question, out of scope here.)
Change-Id: I71a402a0940857bbedbaf25d293429934706a83c
Instead of calling DEBUGPC() over and over, compose a string using
osmo_strbuf and then log it once.
Rationale:
a) DEBUGPC() is a bad idea for gsmtap_log, because each DEBUGPC()
dispatches a separate gsmtap_log packet, fragmenting the actual log line
in wireshark.
b) DEBUGPC() is a bad idea because it checks the logging categories for
every DEBUGPC() invocation.
c) using a separate function with osmo_strbuf and OTC_SELECT, we can
actually skip the entire string composition in case the DMEAS logging
category is disabled, with a single logging category check.
Change-Id: I4cb607ff43a1cb30408427d99d97c103776b6e69
The RSL BS Power IE in measurement reports is encoded as dB / 2.
Instead of using this coding all over the code, converting to dB and
often printing confusing values in logging etc, store as plain dB.
The conversions should be at the points where a "weird" format is
defined: the RSL encoding needs divided-by-two, so apply it there. The
meas_vis is (now unfortunately) defined as div-two, and so on. But
internally we now just store the plain dB value and calculate with it
without duplicating the wire decoding step everywhere.
Rename to bs_power_db to clarify the unit of the stored value.
Change-Id: I229db1d6bcf532af95aff56b2ad18b5ed9d81616
This fixes handover oscillation in the presence of power reduction on
the downlink: apply the reduced power to the cell's RXLEV in order to
not rate the current cell as weaker than it actually is.
Related: SYS#5339
Change-Id: Ifcf59964b5e2d550d79e4ba14d90962808f79dae
According to 3GPP TS 45.008, the BSS shall monitor the levels of
interference on its IDLE traffic channels. The actual measurements
are performed in the BTS and then reported to the BSC over the
A-bis/RSL link(s) in RF RESource INDication messages.
3GPP TS 45.008 defines the following measurement parameters:
* Intave: Interference Averaging period (see table A.1),
* Interference level Boundaries (see table A.1).
Both parameters are sent to the BTS over the A-bis/OML, and can
now be configured via the VTY interface. Only those BTS models
which 'speak' the OML protocol defined in 3GPP TS 52.021 will
actually get the configured parameters, others will keep using
the hard-coded parameters.
Change-Id: I99ebf57aac1f3ca7e0497c3b4f6b0738c6ed7e47
Related: SYS#5313, OS#1866
This message periodically appears in the logs with subsys=DNM and
level=INFO for every disconnected BTS. I find this message useless
and even annoying, so I propose to remove it in this patch.
Change-Id: I7e2498cc61d311ca08585b2f1c49de021b17a5a1
Without this guard, a command like this can crash osmo-bsc:
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 activate fr
when timeslot 0 is configured as non-combined 'CCCH'.
Change-Id: I0197a6a2595ff9dade58e37383d44d2df3b03288
CLoses: OS#5170
chan_mode_to_rsl_cmod_spd() may actually return negative on error. To be
able to check for that, handle the returned value as a signed rc before
assigning to the unsigned spd_ind.
Related: SYS#5315 OS#4940 CID#236231
Change-Id: I52e13b24ce67e288ff32dbdaa1c1759089926f5c
Use lchan->modify.tsc in gsm48_lchan_modify().
The TSC is chosen exactly once upon LCHAN_EV_REQUEST_MODE_MODIFY
(lchan_fsm.c), and that should be the only place calling gsm_ts_tsc().
All other mode modify code should just use the final lchan->modify.tsc.
This fixes an error in patch:
Ic665125255d7354f5499d10dda1dd866ab243d24
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
Thanks to coverity for actually detecting this mistake.
Related: SYS#5315 OS#4940 CID#236233
Change-Id: I87ecf7d9266f37f4c775d029e277b614671a9401
This code is available in libosmocore since ~3 years ago
(fdf8b7b1beeb0cda262c5fb060a933aa7edb5e9a). Let's use it instead of
maintaining duplicated code which diverges over time.
Depends: osmo-bsc.git Iae058c35506bc25c9f4790889b89ac46aea664b6
(contains cherry-pick of bug fixed in osmo-bsc.git).
Change-Id: I53ad3067623077b6a8737c2a0aecc8b46bf71a15
lchan->modify.info.ch_mode_rate should remain unchanged, it is the
immutable request data. However, for VAMOS, we will want to
automatically see that the chan_mode is chosen correctly.
As a first step, place a mutable ch_mode_rate copy at
lchan->modify.ch_mode_rate, i.e. not in .modify.info, but in
.modify. Use that everywhere.
This is a non-functional change, preparing for a subsequent patch that
adds handling of VAMOS shadow lchans.
Change-Id: I8a3daac0287f15a59d3688388bb13e55facb2cea
Both VAMOS- and non-VAMOS speech modes should result in indentical voice
handling. So make sure that all chan_modes are converted to non-vamos
before comparing / evaluating in switch statements.
Change-Id: I791e7966b1f8eaa3299a8a46abeb313cf5136e0b
So far we have a couple of macros iterating a specific number of lchans,
depending on dynamic timeslot state etc. With addition of VAMOS lchans,
this would become more complex and bloated.
Instead of separate iteration macros for each situation, only have one
that takes a number of lchans as argument. That allows to more clearly
pick the number of lchans, especially for non-trivial VAMOS scenarios.
Related: SYS#5315 OS#4940
Change-Id: Ib2c6baf73a81ba371143ba5adc912aef6f79238d
So far the number of usable lchans is determined on-the-fly by the
physical channel config. With VAMOS, this becomes more complex, namely
determining whether the BTS is vamos capable.
Instead of calling a function to determine the number of lchans for
every use, rather place the number of valid lchans in int members of the
timeslot struct, and initialize those during timeslot setup.
Actual use of these new fields will follow in a subsequent patch, which
introduces the ts_for_n_lchans() macro to replace current lchan
iteration macros.
Related: SYS#5315 OS#4940
Change-Id: I08027d79db71a23e874b729c4e6173b0f269ee4f
This is particularly interesting for VAMOS multiplexes, but also gives
more prominence to this rather central aspect of GSM RF.
Related: SYS#5315 OS#4940
Change-Id: I7842ff89bece6d88387dae056e350529bae6fc38
Activating / modifying to a VAMOS mode will require picking specific TSC
Set / TSC. It is a bad idea to pick the TSC in each message encoding
function, rather make this choice centrally.
So far we pick the training sequence code to use based on the timeslot
configuration, and this TSC is determined only upon encoding the RSL
messages.
Instead, pick the TSC to use upon the initial lchan activation /
modification request; store this in the request structs and pass through
the activation / modification code paths.
For VAMOS modes, we also need to pick a TSC Set. Do so also upon activ /
modif request. Note that the TSC Set is not yet applied in this patch,
it will be applied in upcoming VAMOS patches.
The activ / modif request may pass -1 for tsc_set and/or tsc to indicate
no specific choice of TSC Set and TSC, resulting in the same behavior as
before this patch.
For example, lchan->activate.info.tsc* may be passed as -1. The exact
choice for tsc_set and tsc is then stored in lchan->activate.tsc*, i.e.
one level up (the .info sub-struct is considered as immutable input
args). The lchan->activate.tsc* are the values actually encoded in RSL
messages. After the ACK, the lchan->activate.tsc* is stored in
lchan->tsc* to indicate the TSC actually in use. Same for modif.
Note that in 3GPP TS 45.002, the TSC Set are numbered 1 to 4, while the
TSC are numbered 0 to 7. On the wire, though, TSC Set is sent as 0 to 3
value. This is a weird discrepancy, odd choice made by the spec authors.
For conformance with the spec wording, I decided to pass the TSC Set
number as a 1-4 ranged value, and only convert it to the 0-3 on-the-wire
format upon message encoding. So log messages and VTY output will
indicate the first TSC Set as "1", but the first TSC as "0", as defined
in 3GPP TS 45.002, even if that is somewhat weird.
Related: SYS#5315 OS#4940
Change-Id: Ic665125255d7354f5499d10dda1dd866ab243d24
Expose the training sequence code used in the RSL Channel Description IE
as an input parameter.
So far the Channel Description IE is always composed with a training
sequence code from gsm_ts_tsc(). For RSL commands enabling VAMOS mode,
specific training sequence codes are required.
So far, all callers still use gsm_ts_tsc(), making this a patch without
any functional change. Upcoming patches will pass specific TSC as
configured for VAMOS instead, in specific places.
Related: SYS#5315 OS#4940
Change-Id: I49503a6f5d25bb3bc9a0505bd79ed1d5c4f50577
Move the conversion from chan_mode to lchan type out of the
lchan_select_by_chan_mode() function, so that the conversion can be used
by other code paths, coming up in VAMOS patches.
Related: SYS#5315 OS#4940
Change-Id: I296651ebadba81f8b3db0d9bb5b5377877a43677
Prepare for VAMOS, where there will be secondary "shadow" lchans serving
secondary MS on the same timeslots. For those, RSL messages will need to
reflect a different stream ID aka TEI, via an rsl_link_vamos.
Make sure that every code path that sends an RSL message for a specific
lchan selects the RSL link via the new function rsl_chan_link(). When
VAMOS is implemented, this function can select the proper RSL stream.
Rename gsm_bts_trx.rsl_link to rsl_link_primary. This makes sure I'm not
missing any uses of the RSL link, and clarifies the code.
Related: SYS#5315 OS#4940
Change-Id: Ifbf16bb296e91f151d19e15e39f5c953ad77ff17
So far we do all channel reassignments by Handover Command. Since
osmo-bsc now supports rassignment of ongoing voice calls, do intra-cell
congestion resolution by Assignment Command.
In effect, add support for expecting an Assignment Command in
handover_test, and expect assignments instead of handovers for
intra-cell congestion resolution test cases.
Related: SYS#5330 OS#3277
Change-Id: Id56a890106b93fcee67ac9401b890e7b63bba421
So far the assignment FSM always tried to satisfy the channel mode and
rate by either re-using the current lchan or finding a new, unused
lchan. For VAMOS however, we want to pick one specific lchan.
Add target_lchan to struct assignment_request and skip all mode matching
and lchan selection when a specific target_lchan is set.
Related: SYS#5315 OS#4940
Change-Id: I71e0d4ff4746706e0be5266e4574d70ca432e3d7
It is better design to take state change actions in the onenter
function, instead of triggering a state change and then calling
lchan_mode_modify() or lchan_activate(). The reason is that in
principle, any state change may cause error handling to abort and
deallocate FSMs.
This is also preparation for reassignment to a specific lchan in an
upcoming patch.
Related: SYS#5315 OS#4940 OS#3277
Change-Id: I9a2e7eefd4196b80671311e5dfd275893ec0e275
Firstly, do not store the encoded AMR length-value bits in gsm_lchan->*
before an activation/modify has actually succeeded.
And secondly, do not store the AMR LV structure in struct gsm_lchan at
all, but only generate the TLV exactly when a message is being composed.
In gsm48_multirate_config(), generate the LV directly to a msgb instead
of a static buffer first. gsm0408_test.c expected output verifies that
the generated LV bytes remain unchanged.
In lchan_mr_config(), introduce a target mr_conf argument, so that Chan
Act and Mode Modify may generate the filtered AMR config to different
locations (lchan->{activate,modify}.mr_conf_filtered).
Only after receiving an ACK for Activate/Modify, set
lchan->current_mr_conf from lchan->{activate,modify}.mr_conf_filtered.
Use the properly scoped lchan->activate.mr_conf_filtered for Chan Act,
lchan->modify.mr_conf_filtered for Mode Modify and
new_lchan->current_mr_conf for Handover Command as appropriate.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie57f9d0e3912632903d9740291225bfd1634ed47
The previous patch reshuffled the code without having any functional
change. In this patch, a functional change follows:
It does not really make sense to decide on AMR mode filtering based on
whether an activation request came from the VTY:
a) BTS: There is no need to skip AMR mode filtering for the BTS config
at all. There is always a BTS.
b) MSC: Instead of testing for a VTY origin of the request, rather skip
the MSC AMR config filtering exactly when there is no conn associated
with the lchan.
Move the bts filtering directly into mr_config_filter().
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ia7519d2fa9e7f0b61b222d27d077bde4660c40b9
Split off two function from lchan_mr_config() which do not directly
manipulate struct gsm_lchan members. This allows subsequent patches to
re-use mr_config_filter() for Channel Mode Modify without depending on
lchan->activate.info; allows to filter AMR modes without modifying the
state of an already active lchan before sending a Channel Activation or
Channel Mode Modify; and allows to move mr_config_render_lv() to
gsm_04_08_rr.c so that the mr_ms_lv and mr_bts_lv no longer need to be
stored in struct gsm_lchan -- they essentially duplicate s15_s0.
Rationale:
This is a follow-up for the AMR configuration in the sense that previous
patch Ie0da36124d73efc28a8809b63d7c96e2167fc412 started for channel mode
and rate, and the s15_s0 bits:
The AMR mode filtering directly manipulates struct gsm_lchan members and
takes parameters from lchan->activate.info. This makes it hard to
separate lchan activation from the Channel Mode Modify procedure.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Iebac2dc26412d877e5364f90d6f2ed7a7952351e
The GSM48_CMODE_DATA_* rates are completely unused in OsmoBSC anyway,
but there is some code in abis_rsl.c checking its value, and if we were
to start using it that is the place where it should be.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie0e065a5dca5f4a31d5d81e3528a539214a74170
The single place that calls this special case is now actually doing the
exact same thing as the general case, and this is merely code dup.
Related: SYS#5315 OS#4940
Change-Id: Ic62e8a48d3c88a1966086240a41732d169328491
Neels Hofmeyr
Oliver Smith
Vadim Yanitskiy
Pau Espin
Philipp Maier
Keith Whyte
Neels Hofmeyr
Daniel Willmann
Eric Wild