SI Generation and multi-trx setup

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

jolly andreas at eversberg.eu
Tue Oct 9 10:56:54 UTC 2012


hi holger,

since all SI (5 and 6) are equal for all TRX of BTS, the si_valid should
stay part of BTS structure. resetting it will break the static
assignment feature via VTY.

the first part of my patch ensures that only generated SI are set to
valid. other static SI may be valid or not, as specified via VTY.

the second part calls rsl_si() with only the required SI.

i think it is good to keep your error check at rsl_si().

regards,

andreas



Holger Hans Peter Freyther wrote:
> Hi Andreas, Harald,
>
> the recent "SI generation" fix broke multi trx setups. This is because
> when the first (c0) TRX is going up bts->si_valid will include SI2 and
> other SIs scheduled on the BCCH and once the second trx is going up the
> code decides it only needs to generate the SI5 (and more).
>
> But si_valid still includes SI2 and it will be set on the second trx. I
> have fixed it locally by setting si_valid to 0 early in the set_system_infos
> routine and added a warning for this case.
>
> How should this be properly fixed for master? Will the content of a specific
> SI differ from TRX0 to TRX1 of a BTS? Should the si_valid be moved to the
> trx data structure?
>
> I have attached my local patch and would like to have a review for it.
>
> comments? ideas?
>
> 	holger
>
>
> >From bde31667fdd182268fe2172c8c5e21b0c7d085c1 Mon Sep 17 00:00:00 2001
> From: Holger Hans Peter Freyther <zecke at selfish.org>
> Date: Mon, 8 Oct 2012 22:12:13 +0200
> Subject: [PATCH] bsc_init: Forget which SIs are valid for the trx.
>
> The recent commit to improve the SI generation lead to setting
> the BCCH SIs for all TRX in a multi-trx setup. This is because
> we create the SIs globally but si_valid appears to be limited
> to the 'current' trx. Warn if we attempt to set SIs for the BCCH
> on a trx that does not have a BCCH.
> ---
>  openbsc/src/libbsc/bsc_init.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c
> index e05aec7..7a60e04 100644
> --- a/openbsc/src/libbsc/bsc_init.c
> +++ b/openbsc/src/libbsc/bsc_init.c
> @@ -129,6 +129,11 @@ static int rsl_si(struct gsm_bts_trx *trx, enum osmo_sysinfo_type i, int si_len)
>  					       GSM_BTS_SI(bts, i), si_len);
>  		break;
>  	default:
> +		if (bts->c0 != trx)
> +			LOGP(DRR, LOGL_ERROR,
> +				"Attempting to set BCCH SI%s on wrong BTS/TRX (%d/%d)\n",
> +				get_value_string(osmo_sitype_strs, i),
> +				bts->nr, trx->nr);
>  		rc = rsl_bcch_info(trx, osmo_sitype2rsl(i),
>  				   GSM_BTS_SI(bts, i), si_len);
>  		break;
> @@ -149,6 +154,9 @@ static int set_system_infos(struct gsm_bts_trx *trx)
>  			ms_pwr_ctl_lvl(bts->band, bts->ms_max_power);
>  	bts->si_common.cell_sel_par.neci = bts->network->neci;
>  
> +	/* Zero, forget the state of the SIs */
> +	bts->si_valid = 0;
> +
>  	/* First, we determine which of the SI messages we actually need */
>  
>  	if (trx == bts->c0) {
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: si-fix.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20121009/9f6fd619/attachment.ksh>


More information about the OpenBSC mailing list