Hey Vadim,
Just now I came across this code, with an early return in case of BCCH. But right below that, BCCH is still mentioned in the comment, and there are more IEs being parsed.
So I get the impression the early return may prevent that OSMO_MIN limiting for BCCH, and that may not be intended?
/* Osmocom specific extension for BCCH carrier power reduction */ if (dch->chan_nr == RSL_CHAN_BCCH) { int rc = bts_set_c0_pwr_red(trx->bts, new); if (rc != 0) { const uint8_t cause = (rc == -ENOTSUP) ? RSL_ERR_SERV_OPT_UNIMPL : RSL_ERR_IE_CONTENT; return rsl_tx_error_report(trx, cause, &dch->chan_nr, NULL, msg); }
return 0; }
/* BS power reduction is generally not allowed on BCCH/CCCH carrier. * However, we allow it in the BCCH carrier power reduction operation. * Constrain BS power value by the maximum reduction for this timeslot. */ if (trx->bts->c0 == trx) new = OSMO_MIN(new, lchan->ts->c0_power_red_db);
/* 9.3.32 (TLV) BS Power Parameters IE (vendor specific) */ if ((ie = TLVP_GET(&tp, RSL_IE_BS_POWER_PARAM)) != NULL) {
https://git.osmocom.org/osmo-bts/tree/src/common/rsl.c?id=6611e7f3059d26794a...
Hi Neels,
On 8/2/21 12:06 AM, Neels Hofmeyr wrote:
Just now I came across this code, with an early return in case of BCCH. But right below that, BCCH is still mentioned in the comment, and there are more IEs being parsed.
So I get the impression the early return may prevent that OSMO_MIN limiting for BCCH, and that may not be intended?
in rsl_rx_bs_pwr_ctrl(), we actually handle these different cases:
a) power reduction on *inactive* logical channels of the BCCH carrier, b) power reduction on *active* logical channels of the BCCH carrier, c) power reduction on *active* logical channels of a non-BCCH carrier.
Case a) is handled in bts_set_c0_pwr_red(). This function iterates over all timeslots and sets power reduction values depending on their pchan combinations.
Case b) actually depends on a), because ts->c0_power_red_db is set in bts_set_c0_pwr_red(). The idea is that b) is not allowed unless the BTS is operating in the power saving mode.
So, this is why the OSMO_MIN limiting is not relevant to a).
Case c) is not related to the question brought in this thread.
Regards, Vadim.
On Thu, Aug 12, 2021 at 10:00:37AM +0600, Vadim Yanitskiy wrote:
in rsl_rx_bs_pwr_ctrl(), we actually handle these different cases:
a) power reduction on *inactive* logical channels of the BCCH carrier, b) power reduction on *active* logical channels of the BCCH carrier, c) power reduction on *active* logical channels of a non-BCCH carrier.
Case a) is handled in bts_set_c0_pwr_red(). This function iterates over all timeslots and sets power reduction values depending on their pchan combinations.
Case b) actually depends on a), because ts->c0_power_red_db is set in bts_set_c0_pwr_red(). The idea is that b) is not allowed unless the BTS is operating in the power saving mode.
sorry i tried but i don't really understand in depth ... but me understanding is not required. If you think this is not obvious to someone familiar with BCCH power management, then maybe adding a code comment explaining could be nice?
~N
-
Neels Hofmeyr -
Vadim Yanitskiy