Its name is totally misleading, since they seem to be related to
GetAttributes messages rather than SetAttributes.
Change-Id: I306cb407dbd9b98e301b5d93046bdadcb466b82b
Now that we have separate header/code files for the power control,
let's move the related definitions there. This change makes the
code consistent with osmo-bts, where it's already done this way.
Change-Id: I1cb3f6bfba0306e8f371dcd5162d1813beb3a088
When bad RxQual causes handover to a cell with weaker RxLev, then
handover oscillation *will* happen, as shown in test_rxqual.ho_vty.
Introduce a penalty timer for a cell where we had bad RxQual.
This delays handover back to the cell with stronger RxLev by the penalty
timeout; hopefully the interference is gone after the timeout.
Usually, we set new configuration elements so that osmo-bsc behaves the
same as before the config item was added. In this instance, this makes
no sense, because no-one ever wants handover oscillation from bad
RxQual, which is guaranteed to happen without the new penalty timer. Set
it to 60 seconds by default, same as other penalty timers.
Related: SYS#5911
Change-Id: I057b156604a104a26a7ce45d1c7adadbf452c932
I find it weird that we store the A5 algorithm ID in a format that
is used on the wire: N + 1 (valid for both A-bis and A interfaces).
What confused me even more is that in some functions we print it
as if it was in a normal, human-readable format. And this is
also why one can see weird constructions like:
if (lchan->encr.alg_id > ALG_A5_NR_TO_RSL(0)) { ... }
Let's ensure that our internal structures use the A5/N format:
alg_id=0: A5/0 (0x01 on the A-bis/A interface)
alg_id=1: A5/1 (0x02 on the A-bis/A interface)
alg_id=2: A5/2 (0x03 on the A-bis/A interface)
...
alg_id=7: A5/7 (0x08 on the A-bis/A interface)
so that we can print and compare the value of alg_id without using
additional arithmetics. Let's also rename 'alg_id' to 'alg_a5_n'
as it most clearly indicates which representation it is storing.
This is how the above code snippet would look like:
if (lchan->encr.alg_a5_n > 0) { ... }
Change-Id: Ieb50c9a352cfa5481aebac2379e0a461663543ec
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the abovementioned IEs are present
in the original message, they must be delivered to the SMLC too.
Change-Id: Ifeb359b0468845da0b4fed9e2e4b79256067fa81
Depends: libosmocore.git I8775a93cf4089b1752d040e43d2cba6b8997f955
Related: SYS#5891
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the LCS Client Type IE is present
in the original message, it must be delivered to the SMLC too.
Change-Id: Id3262e67c3dc25cb93fbd52a40689c5529ca2d41
Related: SYS#5891
According to 3GPP TS 44.018, section 9.1.15, the RR Handover Command
message may optionally contain the Cipher Mode Setting IE (10.5.2.9).
Section 9.1.15.10 states that this IE may be omitted in case of the
intra-RAT GERAN-to-GERAN handover, however in case of the inter-RAT
handover (e.g. EUTRAN-to-GERAN), this IE *shall* always be included.
Change-Id: I1d270e82d0a9b12897fc94dae4e8999aa132a22f
Related: SYS#5838
Historically, we first only had
BSS_MAP_MSG_ASSIGMENT_RQST
^
with missing N. libosmocore has this renamed a long time ago and
provides a shim #define that makes the typo version still work.
Having the typo is bad for grepping, so rather use the non-typo name.
Also rename the constant for the ass req counter which so far has a
similar typo, and fix the same typo in the counter description.
The counter name exposed on CTRL luckily doesn't have this typo in it.
Change-Id: Ieaa4f4e6e6f7e1563b1bd15a83f0c1a9112d2312
Teach osmo-bsc to handle empty N-Connect. So far we were always
expecting user data in an SCCP N-Connect from an MSC. However, it is
perfectly valid for an initial BSSMAP request to follow later.
This is relevant for:
- Handover Request (incoming inter-BSC handover)
- Perform Location Request (query physical location of the MS)
Add state WAIT_INITIAL_USER_DATA with new timeout net X25. Always enter
this state so that we don't have two separate code paths for handling
initial user data.
Related: SYS#5864
Change-Id: I535c791fa01e99a2226392eb05f676ba6c3cc16e
In the field we saw Handover Requests without any Chosen Encryption
Algorithm IE, and osmo-bsc completely failed on those. This made me
understand my mistake from when I wrote this handover code.
So far, from a BSSMAP Handover Request, we (I) used only the Chosen
Encryption Algorithm IE to pick the encryption to use on the target
lchan. That is very wrong.
Instead, figure out the intersection of permitted algorithms MSC & BSC,
and pick the best of those. Which means, actually, completely ignore the
Chosen Encryption Algorithm IE.
In the message, the permitted algorithms are passed as a bitmask. The
current code using gsm0808_dec_encrypt_info() passes this on as an
array. In order to select_best_cipher(), I could convert that array back
to a bitmask. Instead pass the bitmask on from message decoding
alongside the struct gsm0808_encrypt_info in req->ei_as_bitmask.
In handover_end(), change the condition so that we can also pass
HO_RESULT_FAIL_RR_HO_FAIL to emit a Handover Failure.
Related: SYS#5839
Change-Id: Iffedc981b60d309ed2e5decd5efedee07a757b53
The naming confused me so that I wrote buggy code again. Hopefully this
clarifies which representations the code paths are using.
In the macro code, highlight the error case of n <= -1 explicitly.
Also add ALG_A5_NR_TO_PERM_ALG_BITS. I need the 1<<n case in an
upcoming patch.
Related: SYS#5839
Change-Id: I7557ae97764bba09c906748a18e9031dfb362611
An earlier patch version had that typedef, the merged version switched
to the struct containing the array.
Change-Id: Id8ca7b298436feb98f4a563ad3cdea510b9362b0
The SAPI "n" REJECT messages were being sent with DLCI keeping the RSL
LINK ID format, which is not the same for CC bits.
With this patch, TTCN3 test BSC_Tests.TC_rll_sapi_n_reject_dlci_cc
passes again.
Related: OS#4728
Related: SYS#5047
Change-Id: Icc187f594743040a3d9b8beff7d9cfc21dd6eb08
Allow returning a context sensitive cause instead of a hardcoded one in
gscon pre_term().
Also, the conn->cause is needed to move message dispatch to an "onenter"
function in patch I234b2a754d0c98031056981823cdbc187e977741. I Split
this part off as a separate patch for better readability.
Related: OS#5337
Change-Id: Ib6432746040899129d1d73ae8dc59add2d88a915
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
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
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
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
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
* 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
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
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr
Neels Hofmeyr
Philipp Maier
Oliver Smith
Keith Whyte