As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is
the value used over previous measurement period. Hence, we need to feed
the algo with the measurements taken over that same period.
Related: SYS#4917
Change-Id: I13c0014fdd73f823ae5b1256c35bfa7d97cfa334
Field is renamed to look similar to similar fields in power control
loop. This is a preparation commit, next one will add functionality to
skip SACCH blocksi (P_CON_INTERVAL).
Related: SYS#5371
Change-Id: I169ce58ab827e38b64f4b15f935097a9118fa118
From TS 45.010 5.6.1 (delay tracking for circuit switched channels):
"""
Restricting the change in timing advance to 1 symbol period at a time
gives the simplest implementation of the BTS. However the BTS may use
a larger change than this but great care must then be used in the BTS design.
"""
In general 1 TA at a time (every 480ms of SACCH block) should be enough,
since section 5.6.3 states:
"""
The control loop for the timing advance shall be implemented in such a way that it will cope with MSs moving at a
speed up to 500 km/h
"""
Which is ~140 m/s, and 1 TA step around 500m, so most of the time we
should be save and no steps of more than 1 TA should be required.
However, unlikely changes from reflected to direct signal or vice versa
could produce higher increments, so let's increase the maximum step size
allowed to 2 in order to give more room.
Change-Id: I9e48faabf3090588233e274b2b39065cf85fbec7
First step improving and reworking TA loop:
Move trigger of the loop to similar place done by BS/MS Power Control
Loop, that is, upon receivial of UL SACCH block, which contains
information about the TA used to transmit the block encode in L1SACCH
Header. Hence, from computed received TOA and TA used when transmitting
from the MS, we can infer the desired TA to be used by the MS, which
will send back to it later during DL SACCH block.
The values taken are actually the ones calculated for the previous SACCH
block and stored in lchan->meas.ms_toa256. That's because L1SACCH
contains the TA used for the previous reporting period, similarly to
what's specified for MS Power Control loop (TS 45.008 sec 4.2):
"""
The MS shall confirm the power control level that it is currently employing
in the SACCH L1 header on each uplink channel. The indicated value shall
be the power control level actually used by the mobile for the last burst
of the previous SACCH period.
"""
(The reader may observe that currently this is not properly done for MS
Power Control loop when calling lchan_ms_pwr_ctrl(): this is a bug.)
This new method also permits changing TA quicker, since we have more
confidence that the TA we request is aligned with the one used to
transmit, and we don't simply increment/decrement based on the value we
request to transmit.
Related: SYS#5371
Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
Tests have shown that even a delay of 0, i.e. a simple defer until the
next select() loop, makes the difference from failing to working early
IA. So set the default to 0, achieving such defer.
Related: SYS#5559
Change-Id: I95365649edd51114bcf6028f0dc3bbe4186f96d2
During live testing, it has become apparent that some IMM ASS still fail
when sending the RR IMM ASS directly upon the target channel becoming
active.
Add a bit of delay after activation, to give some time for the channel
to light up for the MS. Default is 50ms.
Related: OS#5559
Change-Id: Ia1e63b98944dc840cde212fc732e20277cdc5585
The bug showed up in previous commit and is fixed in this commit. It can
be seen how rounding error is carried over time in the average
measurement, and affects final values.
Change-Id: I680d1c94bd4bae179b14b26662a819fa1462a5c8
Before this comits, averaging and delta calculation was done in RSSI,
but stored the averaging cached state in variables named "rxlev", which
was really confusing. Let's keeping averaging and delta calculations
based on RxLevels.
Some of the tests change results due to test passing RSSI -45, which is
an invalid Rxlev (only up to -47 is supported).
Others fail due to an unrelated bug showing up now. Basically the averaging algo
is doing rounding the wrong way when downscaling the values. It will be
fixed in a follow-up commit.
Change-Id: I4cff8394f22b5d47789163051364ff594b2bcd74
params->rxqual_meas.upper_thresh is left unchecked in
lchan_bs_pwr_ctrl() on this commit on purpose, to keep this
commit with old behavior wrt to algo logic.
Change-Id: If7e3987df89d680cfa443195ab2f225681d0e6cf
This commit reworks the code in function lchan_bs_pwr_ctrl()
and logging to look similar to that of lchan_ms_pwr_ctrl(), so that
reader can easily spot similarities between both and add simillar
features more easily.
This commit is also a preparation to add EWMA avg support for RxQual
measurements. Logging is also reworked now to look similar to that of MS
Power Control Loop, because having several parameters driving the algo
(RxLev and RxQual), it becomes more suitable to log all of them together instead
of intermediate info only aplicable to one param such as "delta".
Change-Id: Ida76b55f0da722135eb61ed06ea2b3a1862df600
This commit extends existing MS Power Control Loop algorithm to take
into account computed C/I values on the UL, received from MS. The
related C/I parameters used by the algorithm are configured at and
provided by the BSC, which transmits them to the BTS similar to already
existing 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: I5dfd8ff9ab6b499646498b507624758dcc160fb6
The AMR transmission phase directly depends on the frame number. The
transmission phase is used to tell if a received AMR frame contains a
CMI (frame type that is currently used) or CMR (frame type that the
receiver should use) codec identifier. The formulas in the present
implementation seem to be correct but they do not reflect the numbers in
the spec very well, nor do they have unit-tests. Lets replace them with
more readble functions and test those functions with unit-tests.
Change-Id: I94a934a6b3b397b4cd0e9da3577325de58814335
Related: SYS#5549
We have two osmocom specific timers used in the BTS, X1 and X2. Expose
those on the VTY configuration, as timer group 'bts'.
This prepares for a subsequent patch, where I would like to add another
configurable timer. This provides the basic infrastructure for that.
Related: SYS#5559
Change-Id: I0f56f9425134679219884b0c3c2f29e77aff5e64
This is not as trivial as with OsmoBSC or OsmoMSC, because normally the
osmo-bts process exits right away when there is no BSC. Hence add
--vty-test option to main.
Use 'osmo-bts-virtual --vty-test' for testing. The other BTS models
require dependencies / configure switches to be built.
Essentially copied from osmo-bsc.git:
configure.ac: add --enable-external-tests
tests/Makefile.am: add 'vty-test' target
Add osmo-bts.vty, some trivial VTY node testing.
This prepares for adding VTY tests for T timer configuration added in a
subsequent patch.
Related: SYS#5559
Change-Id: I730daf548a3a9bb116aa8b6d5772ca9af0ada08f
Ensure that we check the PHY capabilities in both cases:
* RSL CHANnel ACTIVation, and
* RSL CHANnel MODE MODIFY,
by calling bts_supports_cm() from rsl_handle_chan_mod_ie().
Modify bts_supports_cm() to accept a 'struct rsl_ie_chan_mode',
so we can handle VAMOS enabled channel modes and CSD later on.
Change-Id: I31a444592436705ec9d6ddade3cbfa7f8cb4bb91
Related: SYS#5315, OS#4940
gsm_bts_trx_alloc() already does initialize some fields of the
allocated 'struct gsm_bts_trx' instance, and having an additional
function for initializing the other fields makes no sense.
Note that I intentionally didn't merge a call to bts_model_trx_init()
into gsm_bts_trx_alloc(), because this would break some assumptions
regarding the order of initialization and cause regressions.
This also allows us to not call bts_model_trx_init() from tests.
Change-Id: I4aefaf47b05a67ec0c4774c1ee7abcc95e04cc13
First of all, there is no reason to use a void pointer because
it's always 'struct phy_instance'. Also, no need to encapsulate
this pointer into 'role_bts' because there are no other roles in
osmo-bts (we used to have shared headers years ago).
This commit also fixes a bug in test_sysmobts_auto_band(), where a
pointer to 'struct femtol1_hdl' was directly assigned to trx.pinst.
Change-Id: I9bd6f0921e0c6bf824d38485486ad78864cbe17e
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I8713f4e04e92b4d7e211c499fc6e78983edfb139
Related: OS#5034
The only reason why it was not 'const' is that in lchan_new_ul_meas()
we may need to overwrite 'ulm->is_sub'. This can still be done after
memcpy()ing a new set of samples to the destination buffer.
Change-Id: I0cabf75f8e0bf793c01225a4a8433e994c93f562
Related: OS#5024
One part of the algorithm simply provides a _suggested_ 'delta' that
needs to be applied to the current power level, while the other part
ensures that this suggested value does not exceed the limits. Thus
it's possible that some logging messages would state that the power
reduction value remains unchanged, while the 'detla' != 0.
Change-Id: I7496a158b9ac6074a965056d708d8078a98cb1aa
Related: SYS#4918
This change makes BS power control loop:
- take the lower RxQual threshold (L_RXQUAL_XX_P) into account, so
the BS power is increased only if RxQual exceeds this threshold;
- apply the configured increase step size instead of reducing the
current attenuation by half.
MS power loop is not affected, it does not even handle RxQual yet.
Change-Id: Ib3c740b9a0f3ba5dfb027e144dc13f456cb26ae2
Related: SYS#4918
It makes more sense to use a reduce step size that is smaller than
the increase step size. This way both MS/BS power control loops
would be able to react quickly of the signal gets weaker, while
the good signal would not trigger radical power reduction.
Change-Id: Ie358fd828a68bfa1d23559197e8df8478fb4535e
Related: SYS#4918
In change [1] the new power control structures and default params
were introduced. In change [2], the existing VTY commands for MS
power control in the BTS were deprecated and changed to use the
new structures as storage. Finally, in change [3], handling of
the power control parameters on the A-bis/RSL was implemented.
This change is the final logical step in the mentioned chain: it
makes both MS/BS power control loops use the new parameters, and
removes the old structures. The actual implementation of both
power control loops remains the same, however the expected output
of some unit tests for the Downlink loop needs to be changed:
- TC_fixed_mode: disabling dynamic power control becomes a separate
step of the test script since the field 'fixed' is removed;
- TC_rxlev_target: RxLev thresholds are printed 'as-is'.
Not all of the new parameters are used by the power control loops
yet. Further improvements to be done in the follow up commits.
[1] I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
[2] Icbd9a7d31ce6723294130a31a179a002fccb4612
[3] I5a901eca5a78a0335a6954064e602e65cda85390
Change-Id: Ib18f84c40227841d95a36063a6789bf63054fc2e
Related: SYS#4918
We already have MS Power Control, which according to 3GPP 45.008
shall be implemented in the MS to minimize the transmit power in
the Uplink direction. The BS Power Control may optionally be
implemented by the network side for the same purpose.
Using Downlink signal measurements reported by the MS, the BSS
(either BSC, or BTS) may control Downlink attenuation in a way
that the transmit power remains as low as possible, or remains
in a specific range corresponding to good RxLev values on the
MS side. This change implements autonomous BS Power Control,
that can optionally be enabled by the BSC.
BS Power Control re-uses parts of the MS Power Control code,
so all parameters can be configured in the same way - via the
VTY interface or a configuration file. This basically means
that features like hysteresis and EWMA based filtering are
also available for BS Power Control.
The only difference is that RxQual values higher than 0 would
trigger the logic to reduce the current attenuation twice.
Note that one of the unit tests ('TC_rxlev_max_min') fails,
as the power step limitations for raising and lowering look
wrong to me, and the related discussion is still ongoing.
Change-Id: I5b509e71d5f668b6b8b2abf8053c27f2a7c78451
Related: SYS#4918
Similar to I3c07cb6e14acd5a988761bbc51a9c3b60fb22d87, this change
is another step towards separating the common delta calculation
logic from lchan_ms_pwr_ctrl(), since this function will loose
access to the averaged values.
On the one hand, the affected logging statements are getting
less precise; on the other, logging the averaged value as the
actual value ('rx-current') may be even more confusing.
Change-Id: I07007e45c859b4080fbbe520ffb5ccc0bb9c4244
Related: SYS#4918
This change would allow to separate the common logic from
lchan_ms_pwr_ctrl() and re-use it for Downlink power control.
The logging statement was quite useful during early stages
of development and testing of hysteresis and filtering,
but now we can sacrifice it.
Change-Id: I3c07cb6e14acd5a988761bbc51a9c3b60fb22d87
Related: SYS#4918
This would allow to pass only two pointers:
- 'struct bts_power_ctrl_params', and
- 'struct lchan_power_ctrl_state',
and get rid of 'struct gsm_lchan' dependency. The later is
exactly where all state variables are supposed to be kept.
Change-Id: Idfefca30f4944bc722b4e9d8f1685eb77670a9db
Related: SYS#4918
The logic in measurement.c checks the amount of collected measurement
values. This is done for the total amount of measurements and the amount
of SUB blocks measurements.
The functions that return the expected number of measurement values
currently do not take into account that the mode of a TCH/F or TCH/H has
an effect on the number of expected SUB blocks. (In signalling channels
all blocks count as SUB). Also a TCH/H in signalling mode generates only
half the amount of measurements because the blocks in signalling mode
are sepreded over 6 bursts instead of 4. This also needs to be taken
into account.
Change-Id: I01c7b6cc908c647263ab88f6b6281c4732f88779
Related: OS#4799
Recently we've introduced EWMA based uplink power filtering, that
should reduce Uplink power oscillations. However, the power loop
is still quite sensitive to small deviations from the target power
level: even such an insignificant deviation like 2-5 dBm triggers
the loop to increase or decrease the MS power level. Even if the
EWMA based filtering is enabled with 80% smoothing (alpha = 0.2).
This change introduces a new configuration parameter - 'hysteresis':
uplink-power-target <-110-0> hysteresis <1-25>
that together with the 'uplink-power-target' defines a range:
[target - hysteresis .. target + hysteresis]
in which the MS power loop would not trigger any power changes.
This feature is now *enabled* by default, so given that:
- default 'uplink-power-target' is -75 dBm, and
- default 'hysteresis' is 3 dBm,
the default target Uplink power range is: -78 dBm ... -72 dBm.
Change-Id: Iacedbd4d69d3d74e2499af5622a07a8af0423da0
Related: SYS#4916
It makes no sense to do further calculations if the actual Uplink
signal strength equals the target value configured in the VTY.
Change-Id: Id99c7013a722403e773df8367b1a9d7a856e639b
Related: SYS#4916
So far the Uplink power control loop did not filter the Uplink RSSI
measurements (reported by the BTS) at all. The lack of filtering
makes our implementation too quick on the trigger, so in the real
deployments there will be unneeded Tx power oscillations.
In order to reduce this effect, let's implement a very simple EWMA
(also known as Single Pole IIR) filtering that is defined as follows:
Avg[n] = a * Pwr[n] + (1 - a) * Avg[n - 1]
where parameter 'a' determines how much weight of the latest UL RSSI
measurement result 'Pwr[n]' carries vs the weight of the average
'Avg[n - 1]'. The value of 'a' is usually a float in range 0 .. 1, so:
- value 0.5 gives equal weight to both 'Pwr[n]' and 'Avg[n - 1]';
- value 1.0 means no filtering at all (pass through);
- value 0.0 makes no sense.
This formula was further optimized with the use of '+=' operator.
The floating point math was also eliminated by scaling everything
up (by 100). For more details, see:
https://en.wikipedia.org/wiki/Moving_averagehttps://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filterhttps://tomroelandts.com/articles/low-pass-single-pole-iir-filter
The EWMA filtering is now *enabled by default*, but can be disabled
or (re-)configured over the VTY at any time:
! Completely disable filtering
no uplink-power-filtering
! Enable EWMA smoothing with the given parameters
uplink-power-filtering algo ewma beta <1-99>
Note that the VTY command expects 'beta' instead of 'alpha':
alpha = (100 - beta)
and the value must be in %. This is done for simplicity:
1% means lowest smoothing,
99% means highest smoothing.
Let's say we have EWMA filtering enabled with alpha = 0.4, and get
-98 dBm on the input, while the last output value was -60 dBm.
The new output would be:
Avg[n] = 0.4 * Pwr[n] + 0.6 * Avg[n - 1]
Avg[n] = (0.4 * -98) + (0.6 * -60)
Avg[n] = -75.2 => around -75
Of course, this is not a silver bullet, but better than nothing.
Change-Id: Ib6dcadbf14ef59696c6a546bd323bda92d399f17
Related: SYS#4916
See previous commit adding the unit test about the error description and
expected behavior.
The wrong behavior appeared due to step_size_mdB being unsigned and the
whole addition at the left side of the comparison being turned too as
unsigned, hence a small negative value turning into a big positive
value, and tpp->p_total_cur_mdBm not being updated to speed up the power
ramping.
Change-Id: I36a34362ebc90226fd8e1e190f898c3718fd923a
The test code is extended to support testing more than one ramping loop.
A new test ramping test is added, which shows buggy behavior, since
being in -10dBm and targeting 10dBm with max_initial_pout_mdBm=0 should
immediatelly jump -10->0 and then slowly ramp up (2dB) 0->10dB.
The issue will be fixed in next commit.
Change-Id: I5adc9008ac415eb23274755fc8270df8eebdc6fb
Some backends like osmo-bts-trx require exchanging messages like
POWEROFF to close the TRX, and hence need some time. Switch the function
to expect result asynchronously by calling a callback.
This will be used later to wait until all TRX are really powered off
before exiting the process.
Change-Id: I7d76b600fc06e1114b35bf0c2d08eff5bbd1b69a
According to 3GPP TS 08.58, section 9.3.4, BS Power IE indicates
the transmission power attenuation on a particular channel:
+--------------+---------+-----------------+
| Reserved (3) | FPC (1) | Power level (4) |
+--------------+---------+-----------------+
so let's change handling of this IE as follows:
- s/bs_power/bs_power_red/g, so it reflects 'reduction';
- store power attenuation value in dB, not in 2 db steps;
- get rid of ms_power_ctrl.bts_tx_pwr, it's always 0 anyway;
- fix rsl_tx_meas_res(): use lchan->bs_power_red;
- always check if FPC (Fast Power Control) flag is set;
- we don't support it, so reject messages containing it;
- fix rsl_rx_chan_activ(): properly apply the bitmask.
Change-Id: I16cc50dfca102030380a06e16c234d5f6698f38f
It was a very bad idea to mix "public" BTS features, that are
reported to the BSC via OML, and those features, that are used
locally (and exclusively) in osmo-bts.
Why? At least because we already have the BTS feature manipulation
API in libosmocore, that is used by osmo-bsc, but for some reason
not by osmo-bts. New features added to libosmocore would clash
with the existing "internal" ones like BTS_FEAT_MS_PWR_CTRL_DSP.
So what this change does can be described as follows:
- remove duplicate definition of the "public" features,
- use libosmocore's API for the "public" features,
- separate both "internal" and "public" features:
- the "public" features continue to live in bitvec,
- the "internal" features become flags,
- s/BTS_FEAT/BTS_INTERNAL_FLAG/g.
Change-Id: Icf792d02323bb73e3b8d46384c7890cb1eb4731e
The function ts45008_83_is_sub rougly decides if a frame is a SUB frame
or not. This works by checking the frame number against against lookup
tables. This works fine for codecs where the occurrence of SUB frames is
fixed. However for AMR this is not the case as the DTX periods are
dynamic. Here it is the responsibility of the lower layers (phy,
frame decoding) to tag SUB frames early since making the decision later
based on the frame number is not possible.
The parameter is_amr_sid_update was probably added as a placeholder. It
is set to falls by the callers of the function. Lets remove this
parameter as a late decision if an AMR frame is a SUB frame will never
work.
Change-Id: I125d5ff592218a9e98130a6a7b6bbc6378ce4132
Related: OS#2978
/usr/bin/ld: /home/laforge/projects/git/osmo-bts/tests/sysmobts/../../src/osmo-bts-sysmo/tch.c:584: undefined reference to `femtobts_tch_pl_names'
/usr/bin/ld: l1_transp_hw.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:108: multiple definition of `pdch_msu_size'; main.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:108: first defined here
/usr/bin/ld: l1_transp_hw.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:71: multiple definition of `femtobts_l1prim_type'; main.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:71: first defined here
see also: https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000651.html
Change-Id: I4a9896153876fcda496365776883827746205f00
The variable irssi_full_sum is not populated with a dummy value when we
are not able to compute irssi_full_sum. Instead we mistakenly write
MEASUREMENT_DUMMY_IRSSI to ber_full_sum, which is wrong
Change-Id: I44d7cb48e3c68ab1b48c78cceb9381ce3e39d7e8
Related: OS#2987
The timing advance controller that is implemented in loops.c of
osmo-bts-trx only works for osmo-bts-trx and not for any of the phy
based bts. Lets move the timing advance controller into the common part
and make it available for every bts. Also lets add a unit-test.
Change-Id: If7ddf74db3abc9b9872abe620a0aeebe3327e70a
Related: SYS#4567
It's not a good idea to request big changes in MS Power based on
sporadic bad signal received, let's instead change announced MS power
levels more smoothly to avoid possible big signal strength fluctations,
similar to what is already done in osmo-bts-trx specific loop (loops.c).
Related: OS#1851
Change-Id: Iecc4ec7e21471ec853ad2d5659af4052aba5444c
Several improvements have been made lately to MS Power Control loop from
osmo-bts-trx in loops.c. Let's port these to the common algorithm.
Related: OS#1851
Change-Id: I579967cc8bb69dc76a315c6c9d3a351f5961d92f
Thies field is used to store and retrieve whether MS power needs to be
calculated and updated by osmo-bts software or autonomously by lower
layers. Previous name was not clear
and may have been understood as indicating whether MS Power Control loop
is done or not in general, and the responsible for that is located under
lchan's ms_power_ctrl.fixed.
Related: OS#1851
Change-Id: Ic690ab69866a7377f1597e24aa7b0214831c1cbe
The ETWS (Earthquake and Tsunami Warning System) uses a so-called
ETWS Primary Notification which is sent
* to phones in dedicated mode (via DCCH from the BSC)
* to phones in idle mode (via P1 Rest Octets on PCH/CCCH)
This patch implements the second part of the functionality, i.e.
transmitting the related ETWS Primary Notification via PCH. As
3GPP doesn't specify how this is communicated over Abis, we use
a new, vendor-specific RSL message type.
Closes: OS#4047
Depends: libosmocore I89c24a81ada6627694a9632e87485a61cbd3e680
Depends: libosmocore I36fc2ffc22728887d1cb8768c7fcd9739a8ec0fc
Change-Id: I18c60cdb86b9c19e09f5ec06d66e9b91608880e6
This commit doesn't change internal logic of any model, only the API to
be able to return result of connect TS asyncrhonously since some models
(like osmo-bts-trx) require some time to process the result. This way
PDCH ACT/DEACT (N)ACK can be sent once the result of this long process
is known. For instance, nowadays in osmo-bts-trx we PDCH (DE)ACT ACK
before getting the result from SETSLOT on the TRX iface.
With this new API, bts_model_ts_connect doesn't return any value
synchronously. Instead, it is expected to always end up calling
cb_ts_connected with the return code from the TS activation process. 0
is considered a successs, while any other value is considered an error.
Change-Id: Ie073a4397dd2f1a691968d12b15b8b42f1e1b0cf
No need to pass -t num_trx anymore to specify number of TRX to use. It
is calculated based on dynamic allocation from VTY config.
Using parameter -t is flagged as deprecated and is transformed into a
NOOP por backward compatibility.
As a result, TRX now are allocated after the BTS is allocated and
initial config (pre-VTY) is applied.
A new function bts_trx_init() is added, to set default config on each
TRX during allocation and before setting VTY config on it.
A new per BTS model function bts_model_trx_init() is added, to allow
per model specific default configuration of each TRX.
Change-Id: Iab1a754ab12a626759f9f90aa66f87bdce65ac9c
* we have to use modulo 51, not 50
* the check for FACCH/SCH has to be applied to to the fn % 51 result
Change-Id: I540a7eeef3ea3ed7347f0f1b5a5a6fe7ce0ec8bb
The unit test that tests lchan_meas_process_measurement() only inputs
test data to lchan_meas_process_measurement() but it is not checked if
the interval end could be detected or not.
- Add a return code to lchan_meas_process_measurement()
- Ensure that the return code is checked in the unit-test
Change-Id: I9e00ce683e8c44528804f65181dbfed9e85e3aed
Related: OS#2975
The function is_meas_overdue() was introduced to allow
lchan_meas_process_measurement() to detect when the end of a measurement
interval has been missed. Interval ends may be missed when the SACCH
block of the related measurement interval gets lost. This is due to the
fact that the SACCH block is used as a trigger to start the measurement
result computation.
The idea behind is_meas_overdue() was to check the frame number of the
current measurement against the frame number of the previous measurement
in order to see if there was a measurement for SACCH in between or not.
Unfortunately SACCH and TCH Voice data is not necessarly processed in
order by each phy. Depending on the phy there may be a jitter between
the timing of SACCH and TCH Voice. Depending on the phy this jitter may
be enough to mess up the timing so that we see a SACCH block earlier
than expected. So we can not use the current frame number of TCH Voice
measurements to check for missed SACCH blocks.
Change-Id: Idfdbf64c1f965f35c12559b3995e2b746c74ee9e
Related: OS#3502
Related: OS#2975
The parameter bs_ag_blks_res, which is loaded into the BTS via the SI3
setting, defines how many of the CCCH blocks shall be used for AGCH. The
remaining CCCH blocks will then be available as PCH for paging.
Unfortunately there is no unit-test yet that verifies that all of the 8
different settings for bs_ag_blks_res.
- Separate the the decision logic that checks if a given fn is part of
an AGCH into a function to have it available in the unit-test.
- Add a test that checks all possible bs_ag_blks_res settings.
Change-Id: Ib9652f4013a4da3766852f8f03ce9ec5590f6989
Related: OS#1575
The unit-test function test_lchan_meas_process_measurement() does not
tag measurements as SUB. Lets make the test function more realistic by
setting the is_sub flag at the correct positions.
- Add SUB-Measurements in the correct position
- Print log lines when adding measurements for sub, also fix
minor bugs in the log printing.
Change-Id: I25c361b21a406c0017ee586f0492c38f2e737e57
Related: OS#3502
Related: OS#2975
At the moment the measurement calculation of osmo-bts works by
collecting the measurement reports the phy emits during a measurement
interval. Normally one would expect a well defind fixed number here, but
some phys will not emit a measurement report for lost blocks. Also
blocks and their reports may get lost because of cpu overload etc.
The computation that is executed at the end of the measurement interval
computes over all received measurement. This evenutally means that
missing measurements will not taken into account and the result will
look better than it is in reality.
To fix this, the interval must be of a defined size and in cases where
less measurements as expected were collected, the algorithm must assume
they have been received with a 100%BER and take that into account.
However, all RSSI and TA/TOA related computations should continue to
rely on actual measurement data.
- make sure the algorithm works over a fixed interval
- replace missing measurements with 100%BER
- fix and extend unit-tests
Change-Id: Idd30fc07603ad7d042c1fb416e247c3bf7d35c8b
Related: OS#2987
The function is_meas_overdue() does not use is_meas_complete() anymore
and therefore the related log output is wrong. Lets correct this.
Change-Id: I9b7aa2f7a7c75bc3eed0c94b6ef9d17e7e36ce96
Related: OS#2975
The tests TC_meas_res_sign_sdcch4 and TC_meas_res_sign_sdcch8 are
failing mainly because lchan->ts->nr is confused with lchan->nr.
There is also a small problem with one of the formulas that compute
fn_missed_end.
- Add explainatory comment to the lookup tables on what the index
is refering to
- use lchan-nr instead of lchan->ts->nr when dealing with SDCCH/4/8
- simplfy and fix the formula
- increase the testcoverage of the unit tests, give SDCCH/4/8 also
a thorough check.
Change-Id: I5d555a21003943bf720c53f3a611029ba45339a9
Related: OS#2975
The function ts45008_83_is_sub() is an integral part of the measurement
calculation as it automatically tags incoming measurements as SUB
measurements. This is important in the context of DTX. Unfortunately
there is no unit test for this function yet.
- Add unit test for ts45008_83_is_sub()
Change-Id: Ia26774859f4bf31baee075896905079368bddd42
Related: OS#3502
We do not test is_meas_complete() individually yet, but it is an
integral part of the measurement processings since this function decides
where a measurement interval ends.
- Add unit tests that test TCH/F, TCH/H, SDCCH/4 and STDCH/8
Change-Id: I8f89d9e7092cd65ba4d5c5649140692dcc20bdd6
Related: OS#2987
the measurement interval end is detected by using the measurement
indication that is related to the SACCH block as a trigger to start the
computation. If the measurement indication for the SACCH gets lost
because the block could not be received then the processing is not
executed. This may cause wrong results or when it happens condecutively
an overflow of the measurement sample buffer.
- Store the frame number of the last received measurement indication
- Use the stored frame number to check if an interval was crossed when
the next measurement indication is received. If we detect that we
missed the interval, catch up by running the computation and
start the next interval.
Change-Id: I3a86cd8185cc6b94258373fe929f0c2f1cf27cfa
Related: OS#2975
the testcase definitions in meas_test.c that define different test
situations for uplink measurement are quite large. Lets have them in a
separate file so that the code meas_test.c is easier to maintain.
- Move all mtc* and ulm* structs as well as the struct definitions
to meas_testcase.h.
Change-Id: I90139ec535056d2cea6de10e77f435d807ce496e
Related: OS#2987
All code in osmo-bts goes through APIs in libosmotrau (osmo_ortp.h),
hence direct dependency is not needed. Fixes OBS warnings:
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-trx/usr/bin/osmo-bts-trx was not linked against libortp.so.9 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-virtual/usr/bin/osmo-bts-omldummy debian/osmo-bts-virtual/usr/bin/osmo-bts-virtual were not linked against libortp.so.9 (they use none of the library's symbols)
Change-Id: I96a9b5f0678331dcf66c007928866a124d8700de
This patch adds extended processing of the high-resolution TOA256
measurement values. It adds reporting of the following values
for each RSL MEAS REP for uplink measurements:
* minimum TOA256 value during reporting period
* maximum TOA256 value during reporting period
* standard deviation of TOA256 value during reporting period
Change-Id: Iea4a4781481f77c6163d82dcd71a844a5be87bf2
We saw in a recent prod setup a BSC with saturated channels. Further
investigation lead to a AGCH queue of 1000 (previous hard_limit)
messages, most of them being regular IMM ASSIGN (non REJ). Hence, we
also want to get rid of other messages in the AGCH queue (like regular
IMM ASSIGN).
Furthermore, In this scenario, sending IMM ASS REJ is as important as other
messages given than nowadays we support dynamic wait indicatior
(calculated based on chan load), which means if we reach the MS, we can
tell it to wait for a long time to reach us again, which is desirable.
Change-Id: I022b8948da8be13fb8f4bc36e7c9dab11c35fddb
In a prod setup, complete channel saturation at the bsc was detected,
and Immediate Assignments were not being answered by the MS once sent by
the BTS.
Further investigation showed that the BTS was all the time printing
messages like this:
"bts.c:540 AGCH: too many messages in queue, refusing message type 0x3f, length = 1001/10"
So it seems the AGCH queue was becoming incredibly full (1000, hard
limit triggered the log), while acgch_queue.max_length was set to 10.
As a result, most probably the Immediate Assignments being sent to the
MS are super old in time, and the MS doesn't known about them anymore
once they are receivied, so no answer is sent back.
Let's try to avoid that by decreasing the hard limit so we never reach
that big queue_len scenario.
The number 100 is selected from data gatherered in agch_test.c which
prints a table of max_length values based on different setups. Some
values can reach around 80 messages, so let's use a slightly bigger hard
limit.
Related: SYS#2695
Change-Id: I272798c959abec123776d2fa8dad5685ec512fbd
Completely drop bts_log_init(), call osmo_init_logging2() directly instead: all
callers of bts_log_init() passed NULL as category string, so all it ever did
was call osmo_init_logging(). The bts_log_info is already declared in the .h.
Here and there also define a proper talloc root context instead of using NULL.
Change-Id: Ic049f77bef74123b95350bcae182a468e0086b9c
gsm_bts_role_bts was introduced at a time when we still shared
gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently
needed a BTS-private structure. Since that sharing was abandoned quite
some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away
with the bts/btsb dualism in a lot of the code.
Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
Pau Espin
Neels Hofmeyr
Philipp Maier
Eric Wild
Vadim Yanitskiy
Harald Welte
Martin Hauke