aboutsummaryrefslogtreecommitdiffstats
path: root/tests
AgeCommit message (Collapse)AuthorFilesLines
2021-11-04measurement: pass *mr to lchan_bs_pwr_ctrl()Vadim Yanitskiy3-81/+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-20MS Power Control Loop: Fix oscillations within good MS Power LevelsPau Espin Pedrol3-18/+18
Related: SYS#4917 Change-Id: Ib33a94eba92004f9327c91e020a506dfa9a957c3
2021-09-17tests: MS Power Control Loop: Show oscillation among good power levelsPau Espin Pedrol3-5/+54
This test showcases the current issue where the loop keeps bouncing between 2 good MS Power Level values due to the loop "accepting" and "reporting back" the previously considered good MS Power Level announced/used by the MS. Hence, upon report back from the network, the MS will switch to this new MS Power Level, and same thing will ocurr over and over. Related: SYS#4917 Change-Id: I16ed7fe8a123b99008e0c041d2f3e4232057d55c
2021-09-14Support configuring TA loop SACCH block ratePau Espin Pedrol2-1/+6
Similar to what is already provided for power control loops. However, there's no existing way to communicate TA control parameters from the BSC to the BTS, so implement them locally in BTS vty. Related: SYS#5371 Change-Id: I9fa71f836bb9a79b0ef2567bfcfdf38ff217840b
2021-09-14Power Control Loop: Set P_CON_INTERVAL to 1 by defaultPau Espin Pedrol2-3/+11
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-09-13MS Power Control Loop: Feed UL C/I from correct measurement periodPau Espin Pedrol1-1/+1
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
2021-09-13lchan: Move TA CTRL param to its own substructPau Espin Pedrol2-244/+244
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
2021-09-13ta_control: Allow switching TA quickerPau Espin Pedrol1-230/+230
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
2021-09-13TA loop: Take into account UL SACCH 'Actual Timing advance' fieldPau Espin Pedrol1-5/+1
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
2021-09-11early IA: change default X15 timer to 0 msNeels Hofmeyr1-5/+5
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
2021-09-11early IMM ASS: add configurable delay for RR IMM ASSNeels Hofmeyr1-5/+21
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
2021-09-03MS/BS Power Control Loop: Fix downscaling averaging bugPau Espin Pedrol3-7/+7
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
2021-09-03MS/BS Power Control Loop: Do RxLEV meas avg & delta calculations directly on ↵Pau Espin Pedrol3-37/+35
RxLevels 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
2021-09-03BS Power Control Loop: Support EWMA average algo for RxQual measPau Espin Pedrol1-95/+95
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
2021-09-03BS Power Control Loop: refactor lchan_bs_pwr_ctrl() to look similar to ↵Pau Espin Pedrol1-92/+95
lchan_ms_pwr_ctrl() 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
2021-09-03MS Power Control Loop: Improve loggingPau Espin Pedrol1-60/+60
Change-Id: I8babd42566c41935079fd414d930ebf2d737892e
2021-09-03MS Power Control Loop: Take C/I into accountPau Espin Pedrol3-118/+208
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
2021-09-02sched_lchan_tch_x: use functions to determine AMR tranmssion phasePhilipp Maier5-1/+321
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
2021-08-18add osmo_tdef groups, exposing T timers on VTY configNeels Hofmeyr1-0/+40
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
2021-08-18add VTY transcript testingNeels Hofmeyr2-1/+266
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
2021-06-23osmo-bts-trx: indicate A5/4 support, handle Kc128Eric Wild1-3/+3
Change-Id: Ib8e04fe79f30b443a54c38f395a7a3626ff97c45 Related: SYS#5324
2021-06-01[VAMOS] rsl: call bts_supports_cm() from rsl_handle_chan_mod_ie()Vadim Yanitskiy1-10/+34
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
2021-05-25bts: Clean up TS selection in sign_link_upPau Espin Pedrol1-3/+4
Change-Id: I0c92dfd05bf2ae40887980ef10b7e4c679213b6a
2021-05-11[VAMOS] Merge bts_trx_init() into gsm_bts_trx_alloc()Vadim Yanitskiy2-8/+0
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
2021-05-09[VAMOS] struct gsm_bts_trx: fix the PHY instance pointerVadim Yanitskiy1-1/+4
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
2021-02-19tests: Replace deprecated API log_set_print_filenamePau Espin Pedrol3-3/+3
Change-Id: Ifd1ee307252d19ae535d2234523036c319e4c0ec
2021-02-19tests: Explicitly drop category from logPau Espin Pedrol3-0/+6
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-15ta_control: make 'struct bts_ul_meas' parameters constVadim Yanitskiy1-1/+1
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
2021-02-07power_control: implement handling of P_Con_INTERVAL parameterVadim Yanitskiy6-1/+284
Change-Id: Ibf9956b2c6d829b38e9fda7d1f29790036219f42 Related: SYS#4918
2021-01-24power_control: clarify the meaning of 'delta' in logging messagesVadim Yanitskiy1-76/+76
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
2021-01-21power_control: add test for inc / red step size limitationsVadim Yanitskiy3-0/+189
Change-Id: Ic2d4e144b0319d86daa9fbe38727b892081f0c37 Related: SYS#4918
2021-01-20power_control: fix: properly print 'delta' applied to attenuationVadim Yanitskiy1-30/+30
Change-Id: I178df05c1a4cb982279b21d07bd69f75b44928da Related: SYS#4918
2021-01-20power_control: print current RxLev and lower/upper thresholdsVadim Yanitskiy1-53/+53
This makes the logging messages easier to read and understand. Change-Id: I5f8c987054b2b01acdb9f525d06ca15bbc577070 Related: SYS#4918
2021-01-08power_control: rework handling of DL RxQual measurementsVadim Yanitskiy3-64/+81
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 Yanitskiy5-78/+121
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: generalize measurement pre-processing stateVadim Yanitskiy1-2/+3
This way EWMA based filtering can also be applied to RxQual. Change-Id: I439c00b394da670e314f217b3246cc85ce8213c6 Related: SYS#4918, SYS#4917
2021-01-08power_control: migrate MS/BS control loops to the new paramsVadim Yanitskiy3-76/+88
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 Yanitskiy4-28/+49
Change-Id: Ic37742f46f533865043b3dbcf16ea702e1746f98 Related: SYS#4918
2020-12-06power_control: clarify units in 'struct bts_power_ctrl_params'Vadim Yanitskiy2-20/+20
Change-Id: Icb059ca1f555397be116a424800e4536883b9106 Related: SYS#4918
2020-12-06power_control: implement BS (Downlink) Power ControlVadim Yanitskiy5-2/+727
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
2020-12-04power_control: do not log averaged RSSI values as 'rx-current'Vadim Yanitskiy1-4/+4
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
2020-12-04power_control: remove a logging statement and early returnVadim Yanitskiy1-9/+9
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
2020-12-04power_control: lchan_ul_pf_ewma(): do not use lchan->meas.res_nrVadim Yanitskiy1-1/+1
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
2020-12-04power_control: generalize power control state structureVadim Yanitskiy1-1/+1
Change-Id: I8c6ad8d14349e8a05084c2912644c5202f951f52 Related: SYS#4918
2020-12-02tests/power: rename s/power_test/ms_power_loop_test/Vadim Yanitskiy5-8/+8
There will also be bs_power_loop test soon. Change-Id: I3f58eb85e44825a159af58948f01d9ffd75bceec Related: SYS#4918
2020-12-02bts: add Downlink power control parametersVadim Yanitskiy1-0/+1
Change-Id: I724f661e9ce5dd75f95fb7b270a89b2e2a73c951 Related: SYS#4918
2020-12-02bts: rename MS_UL_PF_ALGO_{NONE,EWMA} to BTS_PF_ALGO_{NONE,EWMA}Vadim Yanitskiy1-1/+1
Change-Id: I580512eea1d329a4d25ccbd6fc2ab98b083ec51d Related: SYS#4918
2020-12-02struct gsm_bts: move ul_power_{target,hysteresis} to ul_power_ctrlVadim Yanitskiy1-14/+14
Change-Id: I3886c7aedf3870536f1750f864cf698302ddf2df Related: SYS#4918
2020-10-26measurement: fix expected number of measurementsPhilipp Maier1-0/+1
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
2020-10-19power_control: tolerate small deviations from 'rx-target'Vadim Yanitskiy3-3/+54
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-22 09:45:41 +0000