Age | Commit message (Collapse) | Author | Files | Lines |
|
Cherry-pick gcc-10 compilation fixes.
Change-Id: I4ee92fecd7f1f48922c827c000742d195f78d8b9
|
|
Compiler from raspberrypi4 warns/errors about those.
Change-Id: I4f973eb4ffdf8869b522d14e25853357fcd1e984
|
|
/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
|
|
Change-Id: Id132c615f7398402ac20d179e5917bea58ef3334
|
|
When a bad SACCH frame is received the processing of the frame is ended
early and lchan_ms_pwr_ctrl() is not called. This means that the power
control loop does not get informed about a situation where the signal
level is very weak and increasing the ms power would make sense. In
order to ensure that the power control keeps working on lost SACCH
frames, lets call lchan_ms_pwr_ctrl() with the current RSSI and the
requested (BSC) power setting.
Related: OS#4281
Change-Id: I4fb85754b1a69376b02da7f4b175c6e8ec9cc35c
|
|
osmo-bts currently does not generate a measurement report in case the
SACCH of the related traffic channel is lost. This is a problem because
the moment when reception gets bad measurmenet reporting is crucial to
carry out handover decisions effectively.
The presence of a SACCH block controls the conclusion of the measurement
interval and the sending of the RSL measurement report. The latter one
not only requires a measurmenet indication, it also requires a fully
intact SACCH block.
Lets use the NOPE / IDLE indications from V1 of the TRXD protocol to
ensure a SACCH block is always reported up to l1sap.c. In cases where
the SACCH is bad, trigger the sending of the RSL measurement report
manually without attaching the measurmenet data from the MS (which we do
not have in this case)
Related: OS#2975
Depends: osmo-ttcn3-hacks Ib2f511991349ab15e02db9c5e45f0df3645835a4
Change-Id: Idfa8ef94e8cf131ff234dac8f93f337051663ae2
|
|
osmo-bts-trx used to have its own (low-level) MS Power Control loop,
but recently it has been ripped out. Since [1], the process fails to
start if the configuration file still contains 'ms-power-control dsp'.
Let's be more tolerant: override 'dsp' by 'osmo' and print a warning.
[1] I49706926b1e962b18791174627bc3cc0cd0cd9d5
Change-Id: I4facd21bca3d8cb80d21e83ea267bc013e474533
|
|
Change-Id: Id3d1725ff36091ed5c57927caad09a8baea6f52e
|
|
Rename some variables so that:
* Variables containing power control levels end up with "_lvl".
* Variables containing power levels end up with _dbm.
* Move old current_dbm var to be ms_dbm, to match its power control
level counterpart ms_power_lvl, and add current_dbm to match its
counterpart ns_power_ctrl.current.
Now that variables are more clear, it also becomes clear that old "diff >
0" condition, apart from difficult, was currently wrong, since in order
to print the raise/low verb we want to compare between old and new
values, not between received and new values. Let's fix that in this same
commit.
Change-Id: I4e279a6b93fbcc5da25bf8c9213310939fd493ce
|
|
Change-Id: I983ff824ef6f54f1e800819d622158d5e2a51f04
|
|
Simplify when the fixed field is set in rsl_rx_chan_activ.
Comment talks about enabling autonoumous control loop, but it is
actually describing it when disabling it, which is confusing.
Change-Id: Id6b444a33ab062f6dab11a0ce62d8aecaea87591
|
|
When logging about filtering access bursts, let's indicate if this is
on a CCCH, PDCH or handover related.
Change-Id: I03f21f2b54cbe5aad36ac71a614d5df98867df80
|
|
Change-Id: I99c6a4d353f405582d5e4f9d12c01c25c7bb4dff
|
|
This way it's much easier to introspect the library internal
talloc allocations from the VTY interface.
Change-Id: Ic8d9fc7ce3da8abf0ea73d2b20366133cd801c37
|
|
Change-Id: I8a6242d3e02f9bd19d287ecad18e001a5991175f
|
|
Let's drop it instead of having code duplication from common code in a
lower layer, and maintain only the one in l1sap for all BTS models.
As a result, osmo-bts-trx loses feature BTS_FEAT_MS_PWR_CTRL_DSP and
will only be able to use "ms-power-control osmo" in VTY, which will be
enabled by default (meaning: change of behavior, now MS Power Control is
enabled by default in osmo-bts-trx and can only by disabled by BSC).
Old bts-trx specific VTY command "(no) osmotrx ms-power-loop" is marked
as deprecated but still working for more usual case (1 TRX configured)
to avoid breaking backward compatibility.
TA low level loop is still kept in loops.c and will be moved to l1sap at
some point too.
Related: OS#1851
Change-Id: I0d8b0c981d9ead91d93999df6e45fb06e426aeb9
|
|
On an ARM toolchain:
scheduler_trx.c:294:3: warning: format '%ld' expects argument of type 'long int', but argument 10 has type 'int'
Let's cast it to long int to make sure correct size is applied in all
platforms.
Change-Id: I701b3dbc4e84db21cf02305d374b0df731e70313
|
|
Change-Id: I6ecd46371e601ad0fb629f9756b36c9c4758a958
Fixes: CID#205067, CID#205068
|
|
Since there can be multiple PDCH channels configured on different
timeslots, different TRXes, and BTSes, the PTCCH/U handling code
in OsmoPCU needs to know the exact origin of a given RACH.ind.
Otherwise, it is not known which subscriber originated a given
PTCCH/U indication, and hence it is impossible to send PTCCH/D
Timing Advance notification properly.
Fortunately, we can extend the RACH.ind message without even
bumping the protocol version, because every single PDU has a
fixed size defined by the largest message - INFO.ind. In case
if the actual message payload is smaller, the rest is filled
with a constant padding byte (0x00).
Older versions of OsmoPCU will consider the new fields as padding,
while the messages from older OsmoBTS versions will always have
both fields set to 0x00. Since C0/TS0 cannot be configured to
PDCH, this can be easily detected on the other end.
Change-Id: Iff38934a108b6b1cd298669834263a7d5296c3f6
Related: OS#4102, OS#1545
|
|
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
|
|
calculations
Use instead the received MS Power currently in use by the MS matching
the measured signal. This way there's no need to wait for the MS to
reach the announced MS power level or add checks in case the MS doesn't
support that specific power level. Furthermore, more fine grained
announced power level value can be obtained faster due to more input
iterations not being dropped while waiting.
osmo-bts-trx specific algo was not following this approach and using
announced MS power instead because it's wowrking at a lower level and
henche was not using the transmitted MS Power level value by the MS as
input for the calculation.
The "if (diff < 2 && diff > -2))" condition is dropped since equal
signal strength may still result in a different MS power level announced
(the one currently used by the MS during tx of last SACCH block).
Related: OS#1851
Change-Id: I4494dc27a295a3dca1d3331d4ff712d486643e13
|
|
Change-Id: I201b72d2a6f5307ede252d5d707f1ebadafe6a4b
|
|
There is theoretical risk that when calculating the BER that a division
by zero occurrs. Lets add a check to avoid n_errors / n_bits_total when
n_bits_total is zero.
Change-Id: I1c0731b9a60be4b8c0c84b85b4403168120ceacd
Fixes: CID#205696
|
|
Fix error while starting osmo-bts-virtual with the example config:
"This BTS model has no DSP/HW MS Power Control support"
Fixes: c693067b7e99a643da673cb3e2a36162cbd0f59c ("Introduce BTS feature BTS_FEAT_MS_PWR_CTRL_DSP")
Change-Id: I4f9a06e85d58294719a24197eb1c42a69fbd03d6
|
|
Change-Id: I36586ac33757705df16e14cfdd92becb96c8cf70
|
|
A NOPE.ind indicates absence of an Uplink burst, thus it does not
carry a burst. Let's init the burst length to avoid uninitialized
memory access in the scheduler code.
Change-Id: I77f686bf7df385215892e71733a28ff0d90d7222
Fixes: CID#205857
|
|
Each logical channel can now optionally have an additional handler,
that will be called when a NOPE / IDLE indication is received from
the transceiver. The aim of that handler is to keep the logical
channel state updated in case if one or more Uplink bursts are lost.
Change-Id: I71c552f44c25e56e9779d8b8ef5d4de9f8475637
Related: OS#3428
|
|
It indicates whether BTS model supports managing an MS Power Control
Loop over HW/DSP instead of using the software based osmocom algorithm
present in osmo-bts.
osmo-bts-trx own loop implementation is considered to be a "DSP/HW" one
since it acts on lower layers and interferes with osmocom algorithm
since it controls the same end variable "lchan->ms_power_ctrl.current",
this way we make sure both aren't enabled at the same time.
Old behavior in kept: if common upper-layer algo is not enabled
explicitly in VTY (ms-power-control osmo) and bts-trx specific lower
layer algo is neither enabled (osmotrx ms-power-loop <xyz>), then no
power control is done at all.
Related: OS#1851
Change-Id: I49706926b1e962b18791174627bc3cc0cd0cd9d5
|
|
Power Level
Related: OS#1851
Change-Id: I1a9c00fe4eb3fa1eaa7997a9ec20716ddfe180a7
|
|
Change-Id: I31ce7930a1daa20a2ff81f31a37df94298c877d6
|
|
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
|
|
The affirmation written there is not true, since actually it depends on
the band. For instance, for DCS1800 the maximum MS power is provided by
class 3. Let ms_pwr_ctl_lvl() take care of campling instead.
Change-Id: I744e7c315b818a1e7d3dd2579cd483c693d89b73
|
|
Make it clear that it contains the maximum MS power level (TS 05.05) and
not the one to be used. The one aimed at is in ms_power_ctrl.current.
Since it's used in related code, move it inside the ms_power_ctrl struct
too.
Related: OS#1851
Change-Id: Ib264ec7dac87355cef6415461ed74bd8e9c8ca52
|
|
Both ms_power and ms_power_ctrl are reset to 0 again further below.
Change-Id: Ia2a5da068d440232361d57bd5ac33eddebf05ebe
|
|
Change-Id: I715ef151b67a21e325c574585a257e71b4b0ce2a
|
|
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
|
|
Change-Id: I7b9a091226e3c7dd60b3921ab0d53688f42d1a4d
|
|
The interesting value in this case is the incoming new ms max power.
Change-Id: Ib6fcb21b1b4bdbc8b749a1b8543d97331699ef3b
|
|
ctl levels
Some bands, such as DCS1800, contain power levels such as 29, 30 and 31 not following same
unified sequence other power levels follow regarding conversion to dBm
values.
This makes extremly complex and prone to error comparing different power
levels. Let's instead use dBm values to calculate and crop desired new
value, and then convert it back to TS 05.05 ms power control level
value.
With this commit the control loop should be able to manage correctly the MS power
levels explained above.
Related: OS#4244
Change-Id: I0160637c5ffa606ee3081ad30be8e6f2a42b725b
|
|
Otherwise older ms_power value will be kept and used as a maximum.
From TS 08.58 sec 4.8 "MS power control":
"""
If power control is supported by BTS and it is to be used,
this is indicated by optional parameters in the MS POWER CONTROL
message (or the CHANNEL ACTIVATION message). Based on the
measurements performed on the uplink, TRX then attempts to keep
the power control parameters within the limits set by the
MS POWER CONTROL message (or by the CHANNEL ACTIVATION message).
"""
Change-Id: I0583eef477c33279ee5bfcda80141f365413a276
|
|
Make sure the variables n_errors, n_bursts_bits, n_bits_total are always
initalized. For example in rx_tchh_fn() the value for n_errors is
defined in a switch statement, where the default lets n_errors
uninitalized, which is in that particular case a theoretical problem,
however, lets make sure that the variables n_errors, n_bursts_bits and
n_bits_total are always initalized with 0
Related: CID#205452
Related: CID#205451
Change-Id: If28ea11cc111c7d73ca47b25e65ce399e5baa4c1
|
|
When sched_compose_tch_ind, sched_compose_ph_data_ind or l1if_process_meas_res
is called from rx_tchf_fn or rx_tchh_fn the frame number of the beginning of
the block is required. At the moment this frame number is calculated
wrongly using strange formulas. Lets use gsm0502_fn_remap() to calculate
the beginning of the block properly
Change-Id: I37601ddd85e4287dd9e41ad4a8cb7d314de1a83d
Depends: libosmocore I3d71c66f8c401f5afbad9b1c86c24580dab9e0ce
Related: OS#3803
|
|
Change-Id: I9fee7be915546cfd11810c74d511beb8ec10d044
|
|
This is similar commit to Ifda92155bd9c277ac150a327a7ab63c854087788,
which previously fixed same issue for osmo-bts-trx specific power
control loop code.
TS 48.058 sec 4.8 MS power control:
"""
TRX then attempts to keep the power control parameters within the limits
set by the MS POWER CONTROL message (or by the CHANNEL ACTIVATION message)
by changing the MS Power Level field of the L1 header sent to MS in each
SACCH block.
"""
Should fix TTCN3 BTS_Tests.TC_rsl_ms_pwr_dyn_max for non-bts-trx BTS
models.
Related: OS#1622
Change-Id: I376b52d7bee44132993a69cf532bd418171d0ca2
|
|
Change-Id: I67b63367e46bd43807f61e8f7e63924b8c2427e4
|
|
TS 48.058 sec 4.8 MS power control:
"""
TRX then attempts to keep the power control parameters within the limits
set by the MS POWER CONTROL message (or by the CHANNEL ACTIVATION message)
by changing the MS Power Level field of the L1 header sent to MS in each
SACCH block.
"""
Fixes TTCN3 BTS_Tests.TC_rsl_ms_pwr_dyn_max
Change-Id: Ifda92155bd9c277ac150a327a7ab63c854087788
|
|
Change-Id: Ia4bc291c8213dd6cfe3b13a99b3108532b6907b1
|
|
All other Uplink burst handlers print frame number of the last
(currently received) burst. Let's make rx_data_fn() consistent.
Change-Id: Ie5762a132326be3ef4e4e38cc126f05d51098a20
|
|
Make it obvious for compilers and for coverity, that the sapi value used
to shift a bit for the sapi_mask is always <= 31. The sapi value is an
index of the value string l1sap_common_sapi_names, which has 24 entries.
Fixes: CID#205067, CID#205068
Change-Id: Id8be0ab67479b1f76a4f624bd3a5242e4fe59f4b
|
|
Change uint8_t sapi to int, so we can properly assert on errors from
get_string_value().
Fixes: CID#205066, CID#205069
Change-Id: I4d30afacfab93051868ae8f462cee9ad3dbc7fd0
|