Bug #4623
closedVTY max_power_red value change should propagate over OML to the BTS
0%
Description
Current VTY implementation of "max_power_red" command is not updating the setting over OML, as described by this comment:
DEFUN(cfg_trx_max_power_red, cfg_trx_max_power_red_cmd, "max_power_red <0-100>", "Reduction of maximum BS RF Power (relative to nominal power)\n" "Reduction of maximum BS RF Power in dB\n") { int maxpwr_r = atoi(argv[0]); struct gsm_bts_trx *trx = vty->index; int upper_limit = 24; /* default 12.21 max power red. */ /* FIXME: check if our BTS type supports more than 12 */ if (maxpwr_r < 0 || maxpwr_r > upper_limit) { vty_out(vty, "%% Power %d dB is not in the valid range%s", maxpwr_r, VTY_NEWLINE); return CMD_WARNING; } if (maxpwr_r & 1) { vty_out(vty, "%% Power %d dB is not an even value%s", maxpwr_r, VTY_NEWLINE); return CMD_WARNING; } trx->max_power_red = maxpwr_r; /* FIXME: make sure we update this using OML */ <--------- SEE HERE return CMD_SUCCESS; }
On the other hand, there seems to be a CTRL iface command which can do it, in bsc_ctrl_commands.c:
static int set_trx_max_power(struct ctrl_cmd *cmd, void *_data) { struct gsm_bts_trx *trx = cmd->node; int old_power; /* remember the old value, set the new one */ old_power = trx->max_power_red; trx->max_power_red = atoi(cmd->value); /* Maybe update the value */ if (old_power != trx->max_power_red) { LOGP(DCTRL, LOGL_NOTICE, "%s updating max_pwr_red(%d)\n", gsm_trx_name(trx), trx->max_power_red); abis_nm_update_max_power_red(trx); } return get_trx_max_power(cmd, _data); } CTRL_CMD_DEFINE(trx_max_power, "max-power-reduction");
So the key here seems to use abis_nm_update_max_power_red(trx);
as done by set_trx_max_power(). However, it seems the abis_nm_update_max_power_red
unconditionally sends an OML message, and I'm not sure if extra checks should be done in OML to avoid it being sent eg during startup of osmo-bsc when the cmd line is read. Some comments here from someone with more OML knowledge is welcome.
Updated by laforge almost 4 years ago
well, this is not any different than most of the BTS/TRX configuration in OsmoBSC: It becomes
active when the OML link is re-started and not before.
So I don't think there is anything specific to fix, to be honest.
Updated by laforge almost 4 years ago
- Status changed from New to Feedback
- Assignee changed from laforge to pespin
- Priority changed from Normal to Low
Updated by pespin almost 4 years ago
I don't fully understand you comment. Do you mean there's no way to "push" the new config after it has been configured without dropping and reconnecting the oml link?
If that's the case we may want to simply add a vty_out() command specifying how to do with the VTY.
I see there's something similar already for CTRL iface:
"src/osmo-bsc/bsc_ctrl_commands.c:192: ipaccess_drop_oml(bts, "ctrl bts.apply-configuration");".
In vty we also have "drop bts connection <0-65535> (oml|rsl)".
So then we could print:
vty_out("%% Use 'drop bts connection %d oml' to apply the new value%s', VTY_NEWLINE);
Comments?
Updated by laforge almost 4 years ago
On Mon, Jun 22, 2020 at 06:06:31PM +0000, pespin [REDMINE] wrote:
I don't fully understand you comment. Do you mean there's no way to "push" the new config after it has been configured without dropping and reconnecting the oml link?
this is the case for all OML-configured settings, and it has always been the case since 2008.
If that's the case we may want to simply add a vty_out() command specifying how to do with the VTY.
There is a completely different task (currently assigned to Hoernchen) to annotate the VTY
with when exactly a given config change becomes effective. Once all VTY commands have received
such annotations, we can do whatever we want with it (display the message you indicated, ...)
Comments?
Please don't try to conflate a generic implementation aspect that affects the BSC
for 12 years now with the specific topic you're working on.
Updated by pespin almost 4 years ago
- Assignee deleted (
pespin)
ACK, then I'm unassigning the ticket. Shall we close the ticket and leave it as a part of the job of the ticket you mentioned assigned to Hoernchen?
Updated by laforge almost 4 years ago
On Tue, Jun 23, 2020 at 09:43:22AM +0000, pespin [REDMINE] wrote:
ACK, then I'm unassigning the ticket. Shall we close the ticket and leave it as a part of the job of the ticket you mentioned assigned to Hoernchen?
exactly.