path: root/tests/power/bs_power_loop_test.c
AgeCommit message (Collapse)AuthorFilesLines
2021-11-04measurement: pass *mr to lchan_bs_pwr_ctrl()Vadim Yanitskiy1-48/+8
As a side effect, we have to sacrifice a unit test (TC_inval_dummy) because it becomes impossible to pass a dummy or invalid SACCH block to lchan_bs_pwr_ctrl(). Change-Id: I937117cf26fb718d57920382f6972390ad498c51 Related: SYS#4918
2021-09-14Power Control Loop: Set P_CON_INTERVAL to 1 by defaultPau Espin Pedrol1-3/+8
TS 45.008 section 4.7.1: """ Upon receipt of a command from an SACCH to change its power level on the corresponding uplink channel, the MS shall change to the new level at a rate of one nominal 2 dB power control step every 60 ms (13 TDMA frames), i.e. a range change of 15 steps should take about 900 ms. The change shall commence at the first TDMA frame belonging to the next reporting period (as specified in subclause 8.4). The MS shall change the power one nominal 2 dB step at a time, at a rate of one step every 60 ms following the initial change, irrespective of whether actual transmission takes place or not. """ Since the reported MS_PWR in L1 SACCH Header is, according to specs, the one used for the last block of the previous SACCH period, it becomes clear the first SACCH block after a requested MS Power Level change by the network may contain mismatches between the announced MS_PWR by the MS and the measured Rxlev/RxQual. Hence, let's better use a P_CON_INTERVAL of 1 which retriggers the MS Power Control Loop every second SACCH block. Change-Id: If6cb8945645a2031f2b2ee65d9b9f51e75cd9af1 Related: SYS#5371
2021-02-19tests: Replace deprecated API log_set_print_filenamePau Espin Pedrol1-1/+1
Change-Id: Ifd1ee307252d19ae535d2234523036c319e4c0ec
2021-02-19tests: Explicitly drop category from logPau Espin Pedrol1-0/+2
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
2021-02-07power_control: implement handling of P_Con_INTERVAL parameterVadim Yanitskiy1-1/+53
Change-Id: Ibf9956b2c6d829b38e9fda7d1f29790036219f42 Related: SYS#4918
2021-01-21power_control: add test for inc / red step size limitationsVadim Yanitskiy1-0/+67
Change-Id: Ic2d4e144b0319d86daa9fbe38727b892081f0c37 Related: SYS#4918
2021-01-08power_control: rework handling of DL RxQual measurementsVadim Yanitskiy1-16/+21
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
2021-01-08power_control: use more reasonable reduce step sizeVadim Yanitskiy1-18/+26
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
2021-01-08power_control: migrate MS/BS control loops to the new paramsVadim Yanitskiy1-37/+39
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
2020-12-09power_control: make raise/lower step limitation configurableVadim Yanitskiy1-3/+19
Change-Id: Ic37742f46f533865043b3dbcf16ea702e1746f98 Related: SYS#4918
2020-12-06power_control: clarify units in 'struct bts_power_ctrl_params'Vadim Yanitskiy1-5/+5
Change-Id: Icb059ca1f555397be116a424800e4536883b9106 Related: SYS#4918
2020-12-06power_control: implement BS (Downlink) Power ControlVadim Yanitskiy1-0/+398
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