- gerrit-log - lists.osmocom.org

[M] Change in pysim[master]: esim/http_json_api: add alternative API interface
by laforge 09 Feb '26

09 Feb '26

laforge has submitted this change. ( https://gerrit.osmocom.org/c/pysim/+/42043?usp=email ) Change subject: esim/http_json_api: add alternative API interface ...................................................................... esim/http_json_api: add alternative API interface unfortunately the API changes introduced in change I277aa90fddb5171c4bf6c3436259aa371d30d092 broke the API interface of http_json_api.py. This was taken into account and necessary to introduce add the server functionality next to the already existing client functionality. The changes to the API were minimal and all code locations that use http_json_api.py were re-aligned. Unfortunately it was not clear at this point in time that there are out-of-tree projects that could be affected by API changes in http_json_api.py To mitigate the problem this patch introduces an alternative API interface to the JsonHttpApiFunction base class. This alternative API interface works like the old API interface when the class is instantiated in the original way. To make use of the revised client the API use has to pass an additional keyword argument that defines the role. Related: SYS#7866 Change-Id: I2a5d4b59b12e08d5eae7a1215814d3a69c8921f6 --- M pySim/esim/http_json_api.py 1 file changed, 51 insertions(+), 3 deletions(-) Approvals: laforge: Looks good to me, approved Jenkins Builder: Verified diff --git a/pySim/esim/http_json_api.py b/pySim/esim/http_json_api.py index 28022ff..94e60cb 100644 --- a/pySim/esim/http_json_api.py +++ b/pySim/esim/http_json_api.py @@ -19,6 +19,7 @@ import requests import logging import json +from re import match from typing import Optional import base64 from twisted.web.server import Request @@ -210,18 +211,65 @@ # additional custom HTTP headers (server responses) extra_http_res_headers = {} + def __new__(cls, *args, role = None, **kwargs): + """ + Args: + args: (see JsonHttpApiClient and JsonHttpApiServer) + role: role ('server' or 'client') in which the JsonHttpApiFunction should be created. + kwargs: (see JsonHttpApiClient and JsonHttpApiServer) + """ + + # Create a dictionary with the class attributes of this class (the properties listed above and the encode_ + # decode_ methods below). The dictionary will not include any dunder/magic methods + cls_attr = { attr_name: getattr(cls, attr_name) for attr_name in dir(cls) if not match("__.*__", attr_name) } + + # Normal instantiation as JsonHttpApiFunction: + if len(args) == 0: + return type(cls.__name__, (abc.ABC,), cls_attr)() + + # Instantiation as as JsonHttpApiFunction with a JsonHttpApiClient or JsonHttpApiServer base + role = kwargs.get('role', 'legacy_client') + if role == 'legacy_client': + # Deprecated: With the advent of the server role (JsonHttpApiServer) the API had to be changed. To maintain + # compatibility with existing code (out-of-tree) the original behaviour and API interface and behaviour had + # to be preserved. Already existing JsonHttpApiFunction definitions will still work and the related objects + # may still be created on the original way: my_api_func = MyApiFunc(url_prefix, func_req_id, self.session) + logger.warning('implicit role (falling back to legacy JsonHttpApiClient) is deprecated, please specify role explcitly') + result = type(cls.__name__, (JsonHttpApiClient,), cls_attr)(None, *args, **kwargs) + result.api_func = result + result.legacy = True + return result + elif role == 'client': + # Create a JsonHttpApiFunction in client role + # Example: my_api_func = MyApiFunc(url_prefix, func_req_id, self.session, role='client') + result = type(cls.__name__, (JsonHttpApiClient,), cls_attr)(None, *args, **kwargs) + result.api_func = result + return result + elif role == 'server': + # Create a JsonHttpApiFunction in server role + # Example: my_api_func = MyApiFunc(url_prefix, func_req_id, self.session, role='server') + result = type(cls.__name__, (JsonHttpApiServer,), cls_attr)(None, *args, **kwargs) + result.api_func = result + return result + else: + raise ValueError('Invalid role \'%s\' specified' % role) + def encode_client(self, data: dict) -> dict: """Validate an encode input dict into JSON-serializable dict for request body.""" output = {} - for p in self.input_mandatory: if not p in data: raise ValueError('Mandatory input parameter %s missing' % p) for p, v in data.items(): p_class = self.input_params.get(p) if not p_class: - logger.warning('Unexpected/unsupported input parameter %s=%s', p, v) - output[p] = v + # pySim/esim/http_json_api.py:269:47: E1101: Instance of 'JsonHttpApiFunction' has no 'legacy' member (no-member) + # pylint: disable=no-member + if hasattr(self, 'legacy') and self.legacy: + output[p] = JsonRequestHeader.encode(v) + else: + logger.warning('Unexpected/unsupported input parameter %s=%s', p, v) + output[p] = v else: output[p] = p_class.encode(v) return output -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42043?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: I2a5d4b59b12e08d5eae7a1215814d3a69c8921f6 Gerrit-Change-Number: 42043 Gerrit-PatchSet: 6 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>

1 0

[M] Change in pysim[master]: esim/http_json_api: add alternative API interface
by laforge 09 Feb '26

09 Feb '26

Attention is currently required from: dexter, neels. laforge has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/pysim/+/42043?usp=email ) Change subject: esim/http_json_api: add alternative API interface ...................................................................... Patch Set 5: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/pysim/+/42043?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: pysim Gerrit-Branch: master Gerrit-Change-Id: I2a5d4b59b12e08d5eae7a1215814d3a69c8921f6 Gerrit-Change-Number: 42043 Gerrit-PatchSet: 5 Gerrit-Owner: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Mon, 09 Feb 2026 12:42:26 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[XS] Change in osmo-ci[master]: Osmocom_OBS_sync: fix failing on new scmsync tag
by osmith 09 Feb '26

09 Feb '26

osmith has uploaded a new patch set (#2). ( https://gerrit.osmocom.org/c/osmo-ci/+/42087?usp=email ) Change subject: Osmocom_OBS_sync: fix failing on new scmsync tag ...................................................................... Osmocom_OBS_sync: fix failing on new scmsync tag The openSUSE OBS instance has added an scmsync tag to their debian 13 meta config: <scmsync>https://src.opensuse.org/obs/debian#13</scmsync> This feature is not supported by the stable OBS version yet (they run current master), and so the sync fails with: project validation error: 6:0: ERROR: Element project has extra content: scmsync Remove the tag to fix this. Related: https://build.opensuse.org/projects/Debian:13/meta Change-Id: Ia2d2ce3a2eeda9a0ed7ce7c7de54293081b44f4e --- M scripts/obs/sync_obs_projects.py 1 file changed, 6 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ci refs/changes/87/42087/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-ci/+/42087?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-ci Gerrit-Branch: master Gerrit-Change-Id: Ia2d2ce3a2eeda9a0ed7ce7c7de54293081b44f4e Gerrit-Change-Number: 42087 Gerrit-PatchSet: 2 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-CC: Jenkins Builder

1 0

[XS] Change in osmo-ci[master]: Osmocom_OBS_sync: fix failing on new scmsync tag
by osmith 09 Feb '26

09 Feb '26

osmith has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ci/+/42087?usp=email ) Change subject: Osmocom_OBS_sync: fix failing on new scmsync tag ...................................................................... Osmocom_OBS_sync: fix failing on new scmsync tag The openSUSE OBS instance has added an scmsync tag to their debian 13 meta config: <scmsync>https://src.opensuse.org/obs/debian#13</scmsync> This feature is not supported by the stable OBS version yet (they run current master), and so the sync fails with: project validation error: 6:0: ERROR: Element project has extra content: scmsync Remove the tag to fix this. Change-Id: Ia2d2ce3a2eeda9a0ed7ce7c7de54293081b44f4e --- M scripts/obs/sync_obs_projects.py 1 file changed, 6 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ci refs/changes/87/42087/1 diff --git a/scripts/obs/sync_obs_projects.py b/scripts/obs/sync_obs_projects.py index a82a47c..1067a98 100755 --- a/scripts/obs/sync_obs_projects.py +++ b/scripts/obs/sync_obs_projects.py @@ -170,6 +170,12 @@ assert root.get("name") == project root.set("name", project_new) + # Remove <scmsync> tag: build.opensuse.org runs current master of OBS, the + # stable version doesn't have this feature yet and errors with: + # "ERROR: Element project has extra content: scmsync" + for scmsync in root.findall(".scmsync"): + root.remove(scmsync) + for description in root.findall("description"): href = f"{lib.args.weburl}/project/show/{project}" description.text = ( -- To view, visit https://gerrit.osmocom.org/c/osmo-ci/+/42087?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ci Gerrit-Branch: master Gerrit-Change-Id: Ia2d2ce3a2eeda9a0ed7ce7c7de54293081b44f4e Gerrit-Change-Number: 42087 Gerrit-PatchSet: 1 Gerrit-Owner: osmith <osmith(a)sysmocom.de>

1 0

[XS] Change in osmo-ttcn3-hacks[master]: bts: fix TC_rsl_ms_pwr_dyn_ass_updown: simulate a good C/I value
by laforge 09 Feb '26

09 Feb '26

laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42067?usp=email ) Change subject: bts: fix TC_rsl_ms_pwr_dyn_ass_updown: simulate a good C/I value ...................................................................... bts: fix TC_rsl_ms_pwr_dyn_ass_updown: simulate a good C/I value Now that we populate the UL SACCH cache in advance, trxcon is sending ms-pwr-lvl 7 in the first UL SACCH block (as expected). This suddenly makes the testcase fail, because now the MS power loop is perfectly happy about the received input values and does not order any changes to the current MS power level anymore, contrary to our expectations. Why? Short answer: because of C/I (curr 6, avg 6) being outside of the good range (thresh 13..17). The MS power loop intentionally avoids reducing Tx power because that would potentially degrade the link quality (C/I) even further. Solution: let's order fake_trx.py to simulate a C/I value that is within the thresholds. This alone does not fix the testcase yet, another fix follows. Change-Id: I8926fc925e930bc2703210931b613988161a72da Related: c246f207 ("bts: f_est_dchan(): populate UL SACCH cache") Related: OS#6945 --- M bts/BTS_Tests.ttcn 1 file changed, 8 insertions(+), 0 deletions(-) Approvals: laforge: Looks good to me, approved pespin: Looks good to me, but someone else must approve Jenkins Builder: Verified diff --git a/bts/BTS_Tests.ttcn b/bts/BTS_Tests.ttcn index e355d75..dc2c7f1 100644 --- a/bts/BTS_Tests.ttcn +++ b/bts/BTS_Tests.ttcn @@ -748,6 +748,11 @@ ret := f_TRXC_transceive(BTS_TRXC, g_bts_trxc_conn_id, ts_TRXC_FAKE_TIMING(toffs256)); } +private function f_trxc_fake_ci(int16_t ci) runs on ConnHdlr { + var TrxcMessage ret; + ret := f_TRXC_transceive(BTS_TRXC, g_bts_trxc_conn_id, ts_TRXC_FAKE_CI(ci)); +} + /* first function started in ConnHdlr component */ private function f_handler_init(void_fn fn, charstring id, ConnHdlrPars pars) runs on ConnHdlr { @@ -3123,6 +3128,9 @@ var uint5_t pwr_var := 7; var SacchL1Header l1h; + /* Simulate a good C/I value of 15 dB (default thresh 13..17 dB). + * This enables the MS power loop to decrease Tx power (if needed). */ + f_trxc_fake_ci(150); /* 15 dB == 150 cB */ f_trxc_fake_rssi(rxlev2dbm(10)); f_l1_tune(L1CTL); RSL.clear; -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42067?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I8926fc925e930bc2703210931b613988161a72da Gerrit-Change-Number: 42067 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

[M] Change in osmo-ttcn3-hacks[master]: bts: f_verify_ramp_up(): fix RxLev / dBm mixup
by laforge 09 Feb '26

09 Feb '26

laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42022?usp=email ) Change subject: bts: f_verify_ramp_up(): fix RxLev / dBm mixup ...................................................................... bts: f_verify_ramp_up(): fix RxLev / dBm mixup Comparing RxLev and dBm values is comparing apples to oranges. It's just a lucky coincidence that fake_trx is using RF path loss value of 110 dB, which is also the offset between RxLev and dBm. * Add `mp_rf_path_loss` matching the default value (110 dB) in fake_trx. * Add `f_bts_max_rx_level_dbm()` calculating the expected Rx power level. * Apply `rxlev2dbm()` on `l1_dl.dl_info.rx_level` whenever needed. * Clarify the units in verdict / logging messages. Change-Id: I818d18d6e0711247b73ee1f336133e2ed3f6e2cb Related: OS#6939 --- M bts/BTS_Tests.ttcn 1 file changed, 52 insertions(+), 44 deletions(-) Approvals: laforge: Looks good to me, approved pespin: Looks good to me, but someone else must approve Jenkins Builder: Verified diff --git a/bts/BTS_Tests.ttcn b/bts/BTS_Tests.ttcn index fb186b7..e355d75 100644 --- a/bts/BTS_Tests.ttcn +++ b/bts/BTS_Tests.ttcn @@ -115,6 +115,7 @@ integer mp_ms_power_level_exp := 7; integer mp_bts_tx_nom_pwr_exp := 50; /* Expected Tx Nominal Output Power of the BTS, in dBm */ integer mp_bts_tx_pwr_att_exp := 20; /* Expected Tx Power attenuation wrt to Tx Nominal Output Power, in dB */ + integer mp_rf_path_loss := 110; /* RF path loss, in dB */ integer mp_ms_actual_ta_exp := 0; integer mp_timing_offset_256syms_exp := 512; integer mp_uplink_power_target := -75; @@ -2740,16 +2741,21 @@ f_L1CTL_DM_REL_REQ(L1CTL, g_chan_nr); } +/* calculate max. Rx power level (in dBm) expected on the Um interface */ +private function f_bts_max_rx_level_dbm() return integer { + return mp_bts_tx_nom_pwr_exp - mp_bts_tx_pwr_att_exp - mp_rf_path_loss; +} + /* Wait until the BTS has reached full tx power (nominal tx power minus configured attenuation) */ -private function f_wait_ramp_up() runs on ConnHdlr return integer { +private function f_wait_ramp_up() runs on ConnHdlr { var L1ctlMessage l1_dl; - var integer max_rx_lvl := mp_bts_tx_nom_pwr_exp - mp_bts_tx_pwr_att_exp; + var integer max_rx_lvl := f_bts_max_rx_level_dbm(); timer Tup := 10.0; Tup.start; alt { [] L1CTL.receive(tr_L1CTL_DATA_IND(t_RslChanNr_BCCH(0), ?)) -> value l1_dl { - var GsmRxLev rx_lvl := l1_dl.dl_info.rx_level; - log("Received rx_level=", rx_lvl); + var integer rx_lvl := rxlev2dbm(l1_dl.dl_info.rx_level); + log("BCCH RxLev ", rx_lvl, " dBm"); if (rx_lvl != max_rx_lvl) { repeat; @@ -2758,11 +2764,10 @@ } [] L1CTL.receive { repeat; } [] Tup.timeout { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - log2str("Didn't reach full power ", max_rx_lvl)); + setverdict(fail, "Didn't reach full power ", max_rx_lvl, " dBm"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); } } - return max_rx_lvl; } /* verify BTS ramps power up to full tx power (nominal tx power minus configured attenuation) */ @@ -2770,37 +2775,37 @@ var L1ctlMessage l1_dl; var integer initial_rx_lvl := -1; var integer last_rx_lvl := -1; - var integer max_rx_lvl := mp_bts_tx_nom_pwr_exp - mp_bts_tx_pwr_att_exp; + var integer max_rx_lvl := f_bts_max_rx_level_dbm(); timer T := 2.0; alt { [] L1CTL.receive(tr_L1CTL_DATA_IND(t_RslChanNr_BCCH(0), ?)) -> value l1_dl { - var GsmRxLev rx_lvl := l1_dl.dl_info.rx_level; - log("Received rx_level=", rx_lvl); + var integer rx_lvl := rxlev2dbm(l1_dl.dl_info.rx_level); + log("BCCH RxLev ", rx_lvl, " dBm"); if (initial_rx_lvl == -1) { initial_rx_lvl := rx_lvl; last_rx_lvl := rx_lvl; /* Expect a somehow low value during first received messages */ if (initial_rx_lvl >= max_rx_lvl / 2) { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - log2str("Detected high initial tx power during ramp up: ", - initial_rx_lvl , ", full power is ", max_rx_lvl)); + setverdict(fail, "Detected high initial Tx power during ramp up: ", + initial_rx_lvl , " dBm (full power is ", max_rx_lvl, " dBm)"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); } } /* received Rx level bigger than maximum allowed power by CN */ if (rx_lvl > max_rx_lvl) { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - log2str("Detected Tx power higher than full power: ", - rx_lvl , " > ", max_rx_lvl)); + setverdict(fail, "Detected Tx power higher than full power: ", + rx_lvl , " > ", max_rx_lvl, " dBm"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); } /* Make sure it never decreases, since we are rumping up */ if (last_rx_lvl > rx_lvl) { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - log2str("Detected Tx power decrease during ramp up: ", - last_rx_lvl , " -> ", rx_lvl)); + setverdict(fail, "Detected Tx power decrease during ramp up: ", + last_rx_lvl , " -> ", rx_lvl, " dBm"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); } if (rx_lvl == max_rx_lvl and not T.running) { @@ -2819,11 +2824,11 @@ /* We didn't increase tx power during ramp up */ if (initial_rx_lvl < last_rx_lvl) { - log("Tx power increased during ramp up: ", initial_rx_lvl , " -> ", last_rx_lvl); + log("Tx power increased during ramp up: ", initial_rx_lvl , " -> ", last_rx_lvl, " dBm"); } else { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - log2str("No Tx power increase during whole ramp up: ", - initial_rx_lvl , " -> ", last_rx_lvl)); + setverdict(fail, "No Tx power increase during whole ramp up: ", + initial_rx_lvl , " -> ", last_rx_lvl, " dBm"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); } } @@ -2836,21 +2841,21 @@ Tdown.start; alt { [] L1CTL.receive(tr_L1CTL_DATA_IND(t_RslChanNr_BCCH(0), ?)) -> value l1_dl { - var GsmRxLev rx_lvl := l1_dl.dl_info.rx_level; - log("Received rx_level=", rx_lvl); + var integer rx_lvl := rxlev2dbm(l1_dl.dl_info.rx_level); + log("BCCH RxLev ", rx_lvl, " dBm"); /* received Rx level bigger than maximum allowed power by CN */ if (rx_lvl > max_rx_lvl) { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - log2str("Detected Tx power higher than full power: ", - rx_lvl , " > ", max_rx_lvl)); + setverdict(fail, "Detected Tx power higher than full power: ", + rx_lvl , " > ", max_rx_lvl, " dBm"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); } /* Make sure it never increases, since we are rumping down */ if (last_rx_lvl < rx_lvl) { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - log2str("Detected Tx power increase during ramp up: ", - last_rx_lvl , " -> ", rx_lvl)); + setverdict(fail, "Detected Tx power increase during ramp down: ", + last_rx_lvl , " -> ", rx_lvl, " dBm"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); } last_rx_lvl := rx_lvl; @@ -2866,16 +2871,16 @@ /* We didn't increase tx power during ramp down */ if (max_rx_lvl > last_rx_lvl) { - log("Tx power decreased during ramp down: ", max_rx_lvl , " -> ", last_rx_lvl); + log("Tx power decreased during ramp down: ", max_rx_lvl , " -> ", last_rx_lvl, " dBm"); } else { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - log2str("No Tx power decrease during whole ramp down: ", - max_rx_lvl , " -> ", last_rx_lvl)); + setverdict(fail, "No Tx power decrease during whole ramp down: ", + max_rx_lvl , " -> ", last_rx_lvl, " dBm"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); } } /* verify BTS power down to rx_level 0 without ramping */ -private function f_verify_power_down(integer max_rx_lvl) runs on ConnHdlr { +private function f_verify_power_down(GsmRxLev max_rx_lvl) runs on ConnHdlr { var L1ctlMessage l1_dl; var boolean first_data_ind := true; @@ -2885,7 +2890,7 @@ [first_data_ind == true] L1CTL.receive(tr_L1CTL_DATA_IND(t_RslChanNr_BCCH(0), ?)) -> value l1_dl { first_data_ind := false; var GsmRxLev rx_lvl := l1_dl.dl_info.rx_level; - log("Received rx_level=", rx_lvl); + log("BCCH RxLev ", rx_lvl); /* The first data indication could still have the original power level */ if (rx_lvl != 0 and rx_lvl != max_rx_lvl) { @@ -2897,7 +2902,7 @@ } [first_data_ind == false] L1CTL.receive(tr_L1CTL_DATA_IND(t_RslChanNr_BCCH(0), ?)) -> value l1_dl { var GsmRxLev rx_lvl := l1_dl.dl_info.rx_level; - log("Received rx_level=", rx_lvl); + log("BCCH RxLev ", rx_lvl); /* Expect immediate power off so either rx_level == 0 or no report at all because TRX was shut down already */ @@ -2942,11 +2947,13 @@ RSL.clear; /* Wait until BTS is started and at full power */ - var integer max_rx_lvl := f_wait_ramp_up(); - log("Reached nominal level ", max_rx_lvl, ", shutting down OML link"); + f_wait_ramp_up(); + + var integer max_rx_lvl := f_bts_max_rx_level_dbm(); + log("Reached nominal level ", max_rx_lvl, " dBm, shutting down OML link"); f_vty_transceive(BSCVTY, "drop bts connection 0 oml"); - f_verify_power_down(max_rx_lvl); + f_verify_power_down(dbm2rxlev(max_rx_lvl)); setverdict(pass); } @@ -2974,13 +2981,14 @@ RSL.clear; /* Wait until BTS is started and at full power */ - var integer max_rx_lvl := f_wait_ramp_up(); - log("Reached nominal level ", max_rx_lvl, ", changing ADM state to LOCKED"); + f_wait_ramp_up(); + var integer max_rx_lvl := f_bts_max_rx_level_dbm(); + log("Reached nominal level ", max_rx_lvl, " dBm, changing ADM state to LOCKED"); log("ADM STATE UNLOCKED->LOCKED"); f_vty_enter_cfg_trx(BSCVTY); f_vty_transceive(BSCVTY, "rf_locked 1"); - f_verify_ramp_down(max_rx_lvl); + f_verify_ramp_down(dbm2rxlev(max_rx_lvl)); /* Let some time after we received 0dBm, then check we don't receive BCCH * anymore because scheduler has stopped after ramping down */ -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42022?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I818d18d6e0711247b73ee1f336133e2ed3f6e2cb Gerrit-Change-Number: 42022 Gerrit-PatchSet: 4 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

[S] Change in osmo-ttcn3-hacks[master]: bts: fix TC_rsl_ms_pwr_dyn_ass_updown: adjust the timers
by laforge 09 Feb '26

09 Feb '26

laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42068?usp=email ) Change subject: bts: fix TC_rsl_ms_pwr_dyn_ass_updown: adjust the timers ...................................................................... bts: fix TC_rsl_ms_pwr_dyn_ass_updown: adjust the timers This testcase predates major changes to the MS power control logic in osmo-bts and was passing thanks to a coincidence (broken UL SACCH cache in trxcon). Specifically, the MS power loop is now using P_Con_INTERVAL=4 by default. This means that the power control decision is intentionally delayed and a change may occur only once in a period of 4 SACCH blocks (N=4 is ~1.92s). Adjust the timer values to take this into account. Take a chance to move comments in-place and expand them with more details. This patch makes TC_rsl_ms_pwr_dyn_ass_updown pass again. Change-Id: I36d87c12f49ec13003b708d768285aa6840e81eb Related: OS#6945 --- M bts/BTS_Tests.ttcn 1 file changed, 12 insertions(+), 8 deletions(-) Approvals: laforge: Looks good to me, approved Jenkins Builder: Verified pespin: Looks good to me, but someone else must approve diff --git a/bts/BTS_Tests.ttcn b/bts/BTS_Tests.ttcn index dc2c7f1..3b820c0 100644 --- a/bts/BTS_Tests.ttcn +++ b/bts/BTS_Tests.ttcn @@ -3121,9 +3121,7 @@ Misc_Helpers.f_shutdown(__BFILE__, __LINE__); } -/* Target level -100, first rssi -90, ms power 7, expected increase to 7+6 within 6 seconds, - * second rssi -110, ms power 7+6, expected decrease to 7 within 6 seconds. - * These power levels are valid for all bands and require no special handling. */ +/* Test if dynamic MS power control can reduce and increase MS power based on UL RxLev */ private function f_TC_rsl_ms_pwr_dyn_ass_updown(charstring id) runs on ConnHdlr { var uint5_t pwr_var := 7; var SacchL1Header l1h; @@ -3143,13 +3141,16 @@ valueof(t_RSL_IE(RSL_IE_MS_POWER_PARAM, RSL_IE_Body:{ms_power_params := pp})) }; - /* establish with power parameters */ + /* Establish a dchan with power parameters, enabling dynamic MS power control */ f_est_dchan(more_ies := addl_ies); - /* set a high value to ensure L1 power control level increases */ + /* 1) Simulate a higher UL RxLev value (-90 dBm) than the target (-100 dBm). + * The MS power loop is expected to reduce Tx power (by raising MS power level). + * Given the default P_Con_INTERVAL=4 (~1.92s) and Pow_Red_Step_Size=2 dB, + * change from 7 (16 dBm) to 13 (4 dBm) should take 6 steps or ~11.52s. */ f_trxc_fake_rssi(rxlev2dbm(20)); - timer T2 := 6.0; + timer T2 := 6.0 * 1.92 + 0.5; /* +0.5 is a safety margin */ T2.start; alt { [] as_l1_sacch_l1h(l1h) { @@ -3167,10 +3168,13 @@ } } - /* set a low value to ensure L1 power control level decreases */ + /* 2) Simulate a low UL RxLev value (-110 dBm). + * The MS power loop is expected to increase Tx power (by lowering MS power level). + * Given the default P_Con_INTERVAL=4 (~1.92s) and Pow_Incr_Step_Size=4 dB, + * change from 13 (4 dBm) to 7 (16 dBm) should take 3 steps or ~5.76s. */ f_trxc_fake_rssi(rxlev2dbm(0)); - timer T4 := 6.0; + timer T4 := 3.0 * 1.92 + 0.5; /* +0.5 is a safety margin */ T4.start; alt { [] as_l1_sacch_l1h(l1h) { -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42068?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I36d87c12f49ec13003b708d768285aa6840e81eb Gerrit-Change-Number: 42068 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

[S] Change in osmo-ttcn3-hacks[master]: bts: TC_rsl_ms_pwr_dyn_ass_updown: misc improvements
by laforge 09 Feb '26

09 Feb '26

laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42069?usp=email ) Change subject: bts: TC_rsl_ms_pwr_dyn_ass_updown: misc improvements ...................................................................... bts: TC_rsl_ms_pwr_dyn_ass_updown: misc improvements Change-Id: Iae3fa5f09d68bd472f7236bf882f5b168d87384a Related: OS#6945 --- M bts/BTS_Tests.ttcn 1 file changed, 5 insertions(+), 5 deletions(-) Approvals: laforge: Looks good to me, approved pespin: Looks good to me, but someone else must approve Jenkins Builder: Verified diff --git a/bts/BTS_Tests.ttcn b/bts/BTS_Tests.ttcn index 3b820c0..9646df4 100644 --- a/bts/BTS_Tests.ttcn +++ b/bts/BTS_Tests.ttcn @@ -3123,7 +3123,7 @@ /* Test if dynamic MS power control can reduce and increase MS power based on UL RxLev */ private function f_TC_rsl_ms_pwr_dyn_ass_updown(charstring id) runs on ConnHdlr { - var uint5_t pwr_var := 7; + const uint5_t pwr_var := 7; var SacchL1Header l1h; /* Simulate a good C/I value of 15 dB (default thresh 13..17 dB). @@ -3163,8 +3163,8 @@ } [] L1CTL.receive { repeat; } [] T2.timeout { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - "Power Level in L1 header has not increased sufficiently"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, + "MS Power Level has not reached 13 (4 dBm)"); } } @@ -3188,8 +3188,8 @@ } [] L1CTL.receive { repeat; } [] T4.timeout { - Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, - "Power Level in L1 header has not decreased sufficiently"); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, + "MS Power Level has not reached 7 (16 dBm)"); } } -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42069?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Iae3fa5f09d68bd472f7236bf882f5b168d87384a Gerrit-Change-Number: 42069 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

[S] Change in osmo-ttcn3-hacks[master]: bts: TC_rsl_ms_pwr_dyn_ass_updown: misc improvements
by laforge 09 Feb '26

09 Feb '26

Attention is currently required from: fixeria. laforge has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42069?usp=email ) Change subject: bts: TC_rsl_ms_pwr_dyn_ass_updown: misc improvements ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42069?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Iae3fa5f09d68bd472f7236bf882f5b168d87384a Gerrit-Change-Number: 42069 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Mon, 09 Feb 2026 12:41:17 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[S] Change in osmo-ttcn3-hacks[master]: bts: fix TC_rsl_ms_pwr_dyn_ass_updown: adjust the timers
by laforge 09 Feb '26

09 Feb '26

Attention is currently required from: fixeria. laforge has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42068?usp=email ) Change subject: bts: fix TC_rsl_ms_pwr_dyn_ass_updown: adjust the timers ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/42068?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I36d87c12f49ec13003b708d768285aa6840e81eb Gerrit-Change-Number: 42068 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Mon, 09 Feb 2026 12:41:06 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

2026

2025

2024

2023

2022

gerrit-log