Bug #3351
closedOML Channel OPSTART ACK of bts 1..N all end up handled for bts 0
100%
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
Updated by neels almost 6 years ago
- Blocks Bug #2283: Inter-BSC hand-over is missing (BSC side) added
Updated by laforge almost 6 years ago
- Status changed from New to In Progress
- Assignee set to neels
Updated by laforge almost 6 years ago
18:58 < neels> so, I see a BTS number in the FOM header, which always comes in as 0. How does it work, is osmo-bsc supposed to tell the BTS a BTS number first, and we might send 0 to each BTS? 18:59 < neels> * the FOM header that the BTS sends to the BSC in OML messages 19:00 <@LaF0rge> bts->num != bts->nr afaik 19:00 <@LaF0rge> the number in the FOM heaer is just the BTS number in this particular Abis link 19:00 <@LaF0rge> that's *not* the number of the bts in our configuratoin 19:01 <@LaF0rge> in classic E1 Abis you can have any number of BTSs daisy-chained and that's what the FOM header is for. 19:01 <@LaF0rge> typically you have three BTSs at one site (three sectors) and those then have different numbers in the FOM header 19:02 <@LaF0rge> neels: we have gsm_bts.nr (the one from the vty "bts NR") and gsm_bts.bts_nr (which is the one in the FOM header) 19:02 <@LaF0rge> neels: the naming isn't very intuitive, but there's a comment /* number of this BTS on given E1 link */ 19:03 < neels> ok, so in Abis/IP each BTS has its own IPA link, and we need to identify the bts->nr by that 19:04 < neels> (seeing OML sent to the same port, 3002, but coming from different sources obviously) 19:04 <@LaF0rge> yes, in abis/ip the mapping is done via the unit_id, and then AFAIK we always only have FOM BTS nr 0 19:05 < neels> yes, that's what I'm seeing. And I see we always send 0xff from osmo-bsc 19:05 <@LaF0rge> 0xff as BTS number ?!? 19:05 < neels> * FOM BTS NR = 0xff 19:05 < neels> sry 19:05 <@LaF0rge> 0xFF means 'not applicable', so I think it actually could mean 'all bts'. 19:05 < neels> BTS=0xff, TRX=0xff, TS=0xff actually 19:06 < neels> yea 19:06 <@LaF0rge> 0xFf normally only appears in TRX and TS 19:06 <@LaF0rge> so if you're talking to an object that is bts-global, TRX+TS are 0xFF. Or if it's a per-TRX object, then TS_NR=0xFF
Updated by neels almost 6 years ago
- Subject changed from OML bootstrap of bts 1..N all end up handled for bts 0 to OML Channel OPSTART ACK of bts 1..N all end up handled for bts 0
- % Done changed from 0 to 90
This is actually recently introduced when implementing the timeslot init code in the first place.
Fix: https://gerrit.osmocom.org/#/c/osmo-bsc/+/9650
Updated by laforge almost 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
fix was merged one week ago, please make sure tickets are reflecting this state.