aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-07-26Bump version: 1.2.0.2-94ea → 1.2.11.2.1Harald Welte1-0/+10
Cherry-pick gcc-10 compilation fixes. Change-Id: I4ee92fecd7f1f48922c827c000742d195f78d8b9
2020-07-26bts-trx: trx_if.c: Fix some printf formatsPau Espin Pedrol1-3/+3
Compiler from raspberrypi4 warns/errors about those. Change-Id: I4f973eb4ffdf8869b522d14e25853357fcd1e984
2020-07-26fix compilation with gcc-10Harald Welte6-42/+43
/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
2020-01-03Bump version: 1.1.0.95-24e7-dirty → 1.2.01.2.0Pau Espin Pedrol2-6/+117
Change-Id: Id132c615f7398402ac20d179e5917bea58ef3334
2020-01-03l1sap.c: ensure ms power control loop is runningPhilipp Maier1-0/+2
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
2020-01-03rsl: ensure measurement reports are sentPhilipp Maier5-8/+41
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
2019-12-31osmo-bts-trx/vty: ensure backwards compatibility with older config filesVadim Yanitskiy1-2/+11
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
2019-12-23l1sap: is_fille_frame(): verify len of data comparedPau Espin Pedrol1-0/+3
Change-Id: Id3d1725ff36091ed5c57927caad09a8baea6f52e
2019-12-05power_control.c: Clarify loop algo vars and use correct ones during logPau Espin Pedrol1-18/+18
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
2019-12-05power_control.c: Log maximum allowed MS Power LevelPau Espin Pedrol1-6/+10
Change-Id: I983ff824ef6f54f1e800819d622158d5e2a51f04
2019-12-05rsl: Clarify when autnonoums MS Power Ctrl Loop is usedPau Espin Pedrol1-9/+6
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
2019-12-04rach_pass_filter(): Add information about channel typeHarald Welte1-10/+11
When logging about filtering access bursts, let's indicate if this is on a CCCH, PDCH or handover related. Change-Id: I03f21f2b54cbe5aad36ac71a614d5df98867df80
2019-12-03rsl_rx_chan_act: Apply bitmask when parsing IE MS_POWERPau Espin Pedrol1-1/+1
Change-Id: I99c6a4d353f405582d5e4f9d12c01c25c7bb4dff
2019-12-02common/abis.c: use tall_bts_ctx as talloc-context for libosmo_abis_init()Vadim Yanitskiy1-1/+1
This way it's much easier to introspect the library internal talloc allocations from the VTY interface. Change-Id: Ic8d9fc7ce3da8abf0ea73d2b20366133cd801c37
2019-12-02common/abis.c: pass gsm_bts_trx to e1inp_sign_link_create()Vadim Yanitskiy1-4/+2
Change-Id: I8a6242d3e02f9bd19d287ecad18e001a5991175f
2019-11-30bts-trx: Drop low layer MS Power Control Loop algoPau Espin Pedrol7-214/+9
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
2019-11-27scheduler_trx.c: cast ptrdiff value to fix printf formatPau Espin Pedrol1-1/+1
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
2019-11-26common/vty.c: fix: properly assert() the result of get_string_value()Vadim Yanitskiy1-2/+2
Change-Id: I6ecd46371e601ad0fb629f9756b36c9c4758a958 Fixes: CID#205067, CID#205068
2019-11-22pcuif_proto.h: extend RACH.ind with TRX and timeslot number fieldsVadim Yanitskiy4-7/+15
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
2019-11-20power_control.c: Limit speed of announced MS Power Level value changesPau Espin Pedrol3-9/+83
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
2019-11-20power_control.c: Don't use announced MS Power level as input for loop ↵Pau Espin Pedrol3-26/+4
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
2019-11-20osmo-bts-trx/trx_if.c: fix: NOPE.ind also contains C/I fieldVadim Yanitskiy1-5/+6
Change-Id: I201b72d2a6f5307ede252d5d707f1ebadafe6a4b
2019-11-20scheduler_trx.c: avoid division by zero when calculating BERPhilipp Maier3-4/+13
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
2019-11-19osmo-bts-virtual.cfg: ms-power-control dsp -> osmoOliver Smith1-1/+1
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
2019-11-19osmo-bts-trx/trx_if.c: also print both RSSI and ToA256 for NOPE.indVadim Yanitskiy1-3/+3
Change-Id: I36586ac33757705df16e14cfdd92becb96c8cf70
2019-11-19osmo-bts-trx/trx_if.c: fix: always initialize bi->burst_len for NOPE.indVadim Yanitskiy1-1/+3
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
2019-11-19osmo-bts-trx: general handling of NOPE / IDLE indicationsVadim Yanitskiy3-8/+20
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
2019-11-14Introduce BTS feature BTS_FEAT_MS_PWR_CTRL_DSPPau Espin Pedrol9-4/+23
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
2019-11-14power_control.c: Fix ms pwr ctrl skipped if MS doesn't support announced MS ↵Pau Espin Pedrol3-2/+15
Power Level Related: OS#1851 Change-Id: I1a9c00fe4eb3fa1eaa7997a9ec20716ddfe180a7
2019-11-14power_control.c: Log rx current and target signal levelsPau Espin Pedrol1-4/+6
Change-Id: I31ce7930a1daa20a2ff81f31a37df94298c877d6
2019-11-14power_control.c: Apply latests improvements from loops.cPau Espin Pedrol2-45/+75
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
2019-11-14bts-trx: loops.c: Avoid always clamping MS power to MS power class 1Pau Espin Pedrol1-10/+1
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
2019-11-14Move and rename gsm_lchan.ms_power fieldPau Espin Pedrol6-21/+20
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
2019-11-14rsl: Remove unneeded duplicate reset on some lchan fieldsPau Espin Pedrol1-3/+0
Both ms_power and ms_power_ctrl are reset to 0 again further below. Change-Id: Ia2a5da068d440232361d57bd5ac33eddebf05ebe
2019-11-14Change gsm_lchan field fixed to boolPau Espin Pedrol3-11/+11
Change-Id: I715ef151b67a21e325c574585a257e71b4b0ce2a
2019-11-14Change gsm_bts_trx field to bool and rename itPau Espin Pedrol5-7/+7
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
2019-11-14cosmetic: Fix trailing whitespacePau Espin Pedrol3-3/+3
Change-Id: I7b9a091226e3c7dd60b3921ab0d53688f42d1a4d
2019-11-12rsl: Fix logged value in rx MS Power ControlPau Espin Pedrol1-1/+1
The interesting value in this case is the incoming new ms max power. Change-Id: Ib6fcb21b1b4bdbc8b749a1b8543d97331699ef3b
2019-11-12bts-trx: Implement MS Power control loop calculations using dBm instead of ↵Pau Espin Pedrol2-31/+58
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
2019-11-12rsl: Assign recv pwr to lchan's max ms powerPau Espin Pedrol1-2/+22
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
2019-10-31scheduler_trx: initalize n_errors, n_bursts_bits, n_bits_totalPhilipp Maier1-5/+11
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
2019-10-29scheduler_trx: use gsm0502_fn_remap() to calculate frame numberPhilipp Maier1-26/+35
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
2019-10-28cosmetic: l1sap.c: Fix typoPau Espin Pedrol1-1/+1
Change-Id: I9fee7be915546cfd11810c74d511beb8ec10d044
2019-10-28power_control.c: Take into account RSL CHAN ACT ms power level limitsPau Espin Pedrol1-0/+7
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
2019-10-28loops.h: Fix missing include for struct l1sched_trxPau Espin Pedrol1-0/+2
Change-Id: I67b63367e46bd43807f61e8f7e63924b8c2427e4
2019-10-28bts-trx: loops.c: Take into account RSL CHAN ACT ms power level limitsPau Espin Pedrol1-0/+4
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
2019-10-28cosmetic: bts-trx: document variable power levelPau Espin Pedrol1-1/+1
Change-Id: Ia4bc291c8213dd6cfe3b13a99b3108532b6907b1
2019-10-21osmo-bts-trx/scheduler: fix: print the last frame number in rx_data_fn()Vadim Yanitskiy1-2/+2
All other Uplink burst handlers print frame number of the last (currently received) burst. Let's make rx_data_fn() consistent. Change-Id: Ie5762a132326be3ef4e4e38cc126f05d51098a20
2019-10-21vty.c: avoid coverity BAD_SHIFT issuesOliver Smith1-0/+2
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
2019-10-21vty.c: don't ignore get_string_value() errorsOliver Smith1-4/+4
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