Project

General

Profile

Actions

Bug #3351

closed

OML Channel OPSTART ACK of bts 1..N all end up handled for bts 0

Added by neels almost 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
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

Blocks OsmoBSC - Bug #2283: Inter-BSC hand-over is missing (BSC side)Resolvedneels05/22/2017

Actions
Actions #1

Updated by neels almost 6 years ago

  • Blocks Bug #2283: Inter-BSC hand-over is missing (BSC side) added
Actions #2

Updated by laforge almost 6 years ago

  • Status changed from New to In Progress
  • Assignee set to neels
Actions #3

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

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

Actions #5

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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)