Actions
Bug #3351
closedOML Channel OPSTART ACK of bts 1..N all end up handled for bts 0
Start date:
06/15/2018
Due date:
% Done:
100%
Spec Reference:
Description
I noticed this when testing the new lchan FSM, which actually waits for OML opstart of the timeslot before setting the pchan values.
BSC test TC_ho_int sets up two BTSes, but with the new lchan FSM it always sees BTS 1's timeslots as uninitialized and cannot pick a TCH/F from it.
I also noticed that I get repeated OPSTART ACKs for BTS 0's timeslots.
To verify, I added a debug printf to osmo-bsc
commit c06e6aae716f991399b4dce923509e9ba5d28414 Author: Neels Hofmeyr <neels@hofmeyr.de> Date: Fri Jun 15 18:04:30 2018 +0200 debug printfs Change-Id: Id6cf8ca0024ea2e161218f2419b4ade750370ee6 diff --git a/src/osmo-bsc/bts_ipaccess_nanobts.c b/src/osmo-bsc/bts_ipaccess_nanobts.c index 843f264ae..4006fa76d 100644 --- a/src/osmo-bsc/bts_ipaccess_nanobts.c +++ b/src/osmo-bsc/bts_ipaccess_nanobts.c @@ -324,6 +324,9 @@ static void nm_rx_opstart_ack_chan(struct abis_om_fom_hdr *foh) return; } + printf("XXXXXXXXXXXXXX %s %u-%u-%u\n", + __func__, + ts->trx->bts->nr, ts->trx->nr, ts->nr); gsm_ts_check_init(ts); } diff --git a/src/osmo-bsc/osmo_bsc_main.c b/src/osmo-bsc/osmo_bsc_main.c index 69db32e55..399ce816d 100644 --- a/src/osmo-bsc/osmo_bsc_main.c +++ b/src/osmo-bsc/osmo_bsc_main.c @@ -295,6 +295,11 @@ static void bootstrap_rsl(struct gsm_bts_trx *trx) for (i = 0; i < ARRAY_SIZE(trx->ts); i++) { struct gsm_bts_trx_ts *ts = &trx->ts[i]; + printf("XXXXXXXXXXXXXX %s %u-%u-%u %u-%u-%u\n", + __func__, + trx->bts->nr, trx->nr, i, + ts->trx->bts->nr, ts->trx->nr, ts->nr); + generate_ma_for_ts(ts); gsm_ts_check_init(ts); }
When starting up bts 0, I get
XXXXXXXXXXXXXX bootstrap_rsl 0-0-0 0-0-0 XXXXXXXXXXXXXX bootstrap_rsl 0-0-1 0-0-1 XXXXXXXXXXXXXX bootstrap_rsl 0-0-2 0-0-2 XXXXXXXXXXXXXX bootstrap_rsl 0-0-3 0-0-3 XXXXXXXXXXXXXX bootstrap_rsl 0-0-4 0-0-4 XXXXXXXXXXXXXX bootstrap_rsl 0-0-5 0-0-5 XXXXXXXXXXXXXX bootstrap_rsl 0-0-6 0-0-6 XXXXXXXXXXXXXX bootstrap_rsl 0-0-7 0-0-7 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-0 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-1 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-2 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-3 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-4 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-5 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-6 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-7
But then, when I start bts 1 a little later, I get
XXXXXXXXXXXXXX bootstrap_rsl 1-0-0 1-0-0 XXXXXXXXXXXXXX bootstrap_rsl 1-0-1 1-0-1 XXXXXXXXXXXXXX bootstrap_rsl 1-0-2 1-0-2 XXXXXXXXXXXXXX bootstrap_rsl 1-0-3 1-0-3 XXXXXXXXXXXXXX bootstrap_rsl 1-0-4 1-0-4 XXXXXXXXXXXXXX bootstrap_rsl 1-0-5 1-0-5 XXXXXXXXXXXXXX bootstrap_rsl 1-0-6 1-0-6 XXXXXXXXXXXXXX bootstrap_rsl 1-0-7 1-0-7 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-0 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-1 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-2 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-3 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-4 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-5 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-6 XXXXXXXXXXXXXX nm_rx_opstart_ack_chan 0-0-7
i.e. the RSL bootstrap correctly goes to bts 1, while the OML opstarts happen for bts 0 instead.
Related issues
Actions