Project

General

Profile

Actions

Bug #4623

closed

VTY max_power_red value change should propagate over OML to the BTS

Added by pespin almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
A-bis OML
Target version:
-
Start date:
06/19/2020
Due date:
% Done:

0%

Spec Reference:

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.

Actions #1

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.

Actions #2

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
Actions #3

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?

Actions #4

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.

Actions #5

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?

Actions #6

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.

Actions #7

Updated by pespin almost 4 years ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)