Age | Commit message (Collapse) | Author | Files | Lines |
|
At the moment the BTS configuration is checked, but the check does not
have much consequence other than that some initialization that is not
executed. The BTS will go into the OML bootstrap phase anyway and most
likely fail at some later point due to the invalid configuration. To
reduce noise and unexpected behaviour of the BTS lets make sure that the
OML boostrap phase can only proceed when the BSC conciders the
configuration as valid.
Change-Id: I42c1c26a9b800600787b1266a871f95f2114c26e
Related: SYS#5369
|
|
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
|
|
Related: SYS#4878
Depends: Iabb17a08e6e1a86f168cdb008fba05ecd4776bdd (libosmocore)
Change-Id: Ica9f908a1a30f334a24c59471affa11225117e12
|
|
Change-Id: I34d29d7d0f66c629367f3d6e8a660e199ecbe080
Related: SYS#5319
|
|
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
|
|
Change-Id: I75b0e289c47841aea22b5966487535cbe855c84f
|
|
Related: I0214b27da18af87eca9715ebf7eeeff945e3e12a (osmo-ttcn3-hacks)
Related: SYS#4878
Change-Id: I79b1261e5a281d9797eaaf9c27d90edd8e27c78b
|
|
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
|
|
Based on allAvailable{SDCCH,TCH}Allocated performance indicators, see
3GPP TS 52.402.
Related: SYS#4878
Related: Ib3997a827c9cc43d1361bb0cf3bfab9f6d91bf82 (osmo-ttcn3-hacks)
Change-Id: I8b06e435a224c8708cd6c67e97ee5413718fc1ed
|
|
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
|
|
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
|
|
Change-Id: Ib422e7d1a7d543dcd8738581839ce55bb8fc29d2
|
|
Related: SYS#4878
Change-Id: Ia9d841a8243adca347e7ea79d31e3cd65eab27ea
|
|
Related: SYS#4878
Change-Id: I32c2c197a6199617a82986480b686c515fa40d62
|
|
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
|
|
An upcoming patch would rather pass a const struct gsm_lchan*.
See I2fb48c549186db812b1e9d6b735a92e80f27b8d3.
Related: OS#4878
Change-Id: I523cbf04e77f43924c3f09094d56f815d3de640d
|
|
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
|
|
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
|
|
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
|
|
Change-Id: I7cc79e368512483ff4e1e56b49ad2b950f627c2f
|
|
* 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
|
|
Change-Id: Ie0c0c75a62b460887f2c78efe043b9e11a76919e
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Change-Id: I15ec8f71a5d31915162cb3ad75ea77e934fa4887
|
|
Change-Id: I347e7da328fed0733af2eec10a3ca6e02a148308
|
|
Adds gsm_bts_stats_reset() to clear the stats and calls it from the
different models.
Change-Id: Ic42687cd73e3546edaa99fb1268a5960ffa43b12
Related: SYS#5541
|
|
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
|
|
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
|
|
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
|