AgeCommit message (Collapse)AuthorFilesLines
29 hourspower_control.c: Limit speed of announced MS Power Level value changesHEADmasterPau 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
30 hourspower_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
35 hoursosmo-bts-trx/trx_if.c: fix: NOPE.ind also contains C/I fieldVadim Yanitskiy1-5/+6
Change-Id: I201b72d2a6f5307ede252d5d707f1ebadafe6a4b
35 hoursscheduler_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
2 daysosmo-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
3 daysosmo-bts-trx/trx_if.c: also print both RSSI and ToA256 for NOPE.indVadim Yanitskiy1-3/+3
Change-Id: I36586ac33757705df16e14cfdd92becb96c8cf70
3 daysosmo-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
3 daysosmo-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
7 daysIntroduce 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
7 dayspower_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
7 dayspower_control.c: Log rx current and target signal levelsPau Espin Pedrol1-4/+6
Change-Id: I31ce7930a1daa20a2ff81f31a37df94298c877d6
7 dayspower_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
7 daysbts-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
7 daysMove 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
7 daysrsl: 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
7 daysChange gsm_lchan field fixed to boolPau Espin Pedrol3-11/+11
Change-Id: I715ef151b67a21e325c574585a257e71b4b0ce2a
7 daysChange 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
7 dayscosmetic: Fix trailing whitespacePau Espin Pedrol3-3/+3
Change-Id: I7b9a091226e3c7dd60b3921ab0d53688f42d1a4d
9 daysrsl: 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
9 daysbts-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
9 daysrsl: 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
2019-10-17Rename variable: CALIB_SUCESS -> CALIB_SUCCESSMartin Hauke1-3/+3
Correct the name of this variable. Change-Id: I75cb6404d772b79933d1d9d694abf8eff1fad020
2019-10-17Fix common misspellings and typosMartin Hauke44-178/+178
Change-Id: I403b9029f57fec3fdec2c1e2cbeac0f6eab53f24
2019-10-17vty: add "logging filter l1-sapi"Oliver Smith2-0/+70
Add VTY commands to filter by L1 SAPI. Allow to filter by multiple SAPIs by running the filter command multiple times: OsmoBTS> logging filter l1-sapi agch OsmoBTS> logging filter l1-sapi pch Related: OS#2356 Change-Id: I32d86d3d34757135b4cce59919c2fc2b67f0a889
2019-10-16bts-trx: Time out if no clock ind recvd after RSP POWERONPau Espin Pedrol3-2/+57
Before this patch, if due to whatever reason the TRX started fine (RSP POWERON 0) and sockets were created but no CLOCK IND was ever received by the BTS, it wouldn't notice since the timerfd timeouts (bts_shutdown("no clock")) are only checked after the first CLOCK IND is sent by the TRX. As a result, the BTS would be kept on forever saying everything is fine but it would be sending no DL burst at all to the TRX (tested with a modfied osmo-trx dropping clock indication). With this patch, new APIs are added to indicate the scheduler_trx code the timeframes where clock ind are expected (between RSP POWERON 0 and RSP POWEROFF 0); if TRX sends clock indications out of that timeframe, BTs lower layers will drop them (controlled by "powered" bool). Hence, the scheduler_trx can now place a timeout (reusing same timerfd because its new use is exclusive in time with its other previous use) when it is told that CLOCK IND should start appearing, and if none arrives in considerable time, then the BTS can be shut down to notify the rest of the network. Related: OS#4215 Change-Id: Iba5dbe867aff10e70ec73dbf1f7aeeecb15c0a4d
2019-10-11log: set L1 SAPI log contextOliver Smith6-0/+293
Add a new common L1 SAPI enum, to unify all the BTS specific SAPIs. Translate to this enum, and set the context for uplink messages in each BTS specific implementation. Set the context for downlink messages in the common l1sap code, by converting the osmo_phsap_prim back to the SAPI value (mostly looking at chan_nr). The new functions for doing this conversion, get_common_sapi_by_trx_prim() and get_common_sapi_ph_data(), are based on the existing to_gsmtap() and gsmtap_ph_data() functions. Note that we can't set the uplink SAPI context in the common code, because then we can't set it as early as possible. In this patch, the SAPI context is set for the PHYs where the SAPI is readily available. With additional conversion from the RSL channel, the SAPI context could be set for osmo-bts-trx in a follow up patch. Related: OS#2356 Depends: (libosmocore) I814cb3328d99faca9220adb5a80ffb934f219d7d Change-Id: I6b7bb2e1d61502b61214f854a4ec5cbb7267545b
2019-10-10README.md: update osmo-bts-trx specific limitationsVadim Yanitskiy1-5/+0
The ticket has been closed, BER and C/I measurements are now being sent to OsmoPCU (see Ia58043bd2381a4d34d604522e02899ae64ee0d26). Change-Id: I1909a70b82421802f32c1bc4f69a2e4210db5b2d
2019-10-09L1SAP: there can be no DATA.ind primitives on PTCCH/U, reject themVadim Yanitskiy1-16/+18
Change-Id: Ib846a9b8e619c7da56b5f0a54d16f629913af80d
2019-10-09L1SAP: use GSMTAP_CHANNEL_PDTCH for PDTCH blocks by defaultVadim Yanitskiy1-2/+4
We don't know whether a data block on PDCH belongs to PDTCH or PACCH without parsing it, because the latter one is being allocated on demand. Let's use GSMTAP_CHANNEL_PDTCH by default, rather than GSMTAP_CHANNEL_PACCH. Change-Id: I7639215ef936a8ac05ca417a91f4e12755f318d4
2019-10-09L1SAP: fix gsmtap_pdch(): there can be no DATA.ind on PTCCH/UVadim Yanitskiy1-7/+0
Change-Id: Id69010ffa8c697e8c01bbb21509253c330f95343
2019-10-09L1SAP: use the actual ARFCN for outgoing PCUIF messagesVadim Yanitskiy1-4/+4
Change-Id: I07b3aac97603d85fb6cf077d3a342b12b0643171
2019-10-09bts-trx: Log TRXC and TRXD socket recv()/send() failuresPau Espin Pedrol1-5/+23
Related: OS#4215 Change-Id: Ic3e41d82b43459495d45873d612a3bd349ac174a
2019-10-09L1SAP: properly handle 11-bit encoded RACH.ind in gsmtap_ph_rach()Vadim Yanitskiy1-1/+1
Change-Id: Id263c2b716fd282d37d705a1c5f430ce7c0edaf0
2019-10-09L1SAP: refactor handling of Access Bursts on PDCHVadim Yanitskiy1-15/+43
First of all, we also need to apply the same filtering to Access Bursts on PDCH as for the normal ones on RACH, i.e. filter them by ToA (Timing of Arrival) and BER (Bit Error Rate). Secondly, we shall not interpret Access Bursts on PDTCH/U as handover related ones. Instead, let's print a warning and ignore them since they are not (yet) supported by OsmoBTS. Finally, in gsmtap_pdch() we need to set a proper channel type for Access Bursts received on PDCH (PDTCH/U or PTCCH/U). Change-Id: I461fde9f4543c45c42b591cd3fd0ff3d98673cec
2019-10-09L1SAP: do not pass unused parameter to l1sap_handover_rach()Vadim Yanitskiy1-3/+2
Change-Id: I7f2d909f1bde09cbec106240df290381b3418e46
2019-10-09L1SAP: clarify debug messages in rach_pass_filter()Vadim Yanitskiy1-3/+3
RACH stands for Random Access CHannel, while in rach_pass_filter() we're dealing with Access Bursts, that may be received on other logical channels too (e.g. PTCCH, PDTCH or any other). Change-Id: I1e5ca9930ab491a6916c972865154d54530cbf51
2019-10-09L1SAP: also consider RSL_CHAN_OSMO_CBCH8 as CBCHVadim Yanitskiy1-1/+2
Currently we don't distinguish between CBCH on BCCH+SDCCH/4 and CBCH on SDCCH/8, but in libosmogsm we have two independent (non-standard) RSL channel number values for them. Maybe some day we will, so let's extend the definition of L1SAP_IS_CHAN_CBCH. Change-Id: I2f6d501a29edaf89dfb17d5d64f930cdb1943630
2019-10-09L1SAP: use RSL_CHAN_* definitions from libosmogsmVadim Yanitskiy1-10/+21
Change-Id: I2708b5d5bb6b92f90766ac752bafd28cff2549b0
2019-10-07gitignore: add oc2g generated filesOliver Smith1-0/+5
Change-Id: I3e7af6d290988099535bab63bbc53a901d16b55f
2019-10-05bts-trx: Drop unused func check_transceiver_availability()Pau Espin Pedrol2-13/+0
After getting rid of transceiver_available, this function is not used anymore by any code, since its per-trx counterpart l1if_provision_transceiver_trx() is the one used by other code. Change-Id: If5a988eb14658a78dd46234dccc052dc12fb872a