Project

General

Profile

Actions

Bug #2317

closed

multibts setup produce unnecessary OML warning

Added by msuraev almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
06/06/2017
Due date:
% Done:

100%

Spec Reference:

Description

The setup described in https://projects.osmocom.org/projects/openbsc/wiki/Multi-BTS_with_handover currently gives misleading warnings:

BSC:
BTS 1: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Process stopped, Additional Text=Formatted O&M with BTS 1 out of range (0:0xFF).

BTS:
<0001> oml.c:75 Reporting FAILURE to BSC: Formatted O&M with BTS 1 out of range (0:0xFF)
<0001> oml.c:372 Sending FOM NACK with cause BTS no. unknown.

Logs are produced when osmo-bts-trx (configured as bts 1 in openbsc) is trying to connect to BSC. Using the same configuration with bts 0 and bts 1 reversed gives no such warning.

The setup seems to be functional but this error message should be removed nevertheless - there's no 1:1 mapping between bts numbers in openbsc and osmobts configs.

For the reference, command-line arguments used while testing:
./openbsc/src/osmo-nitb/osmo-nitb -c ~/.config/osmocom/open-bsc.cfg-oml -l ~/.config/osmocom/hlr.sqlite3 -P
./src/osmo-bts-trx/osmo-bts-trx -c ~/.config/osmocom/osmo-bts.cfg-oml -t 2 -i 127.0.0.8


Files

open-bsc.cfg-oml open-bsc.cfg-oml 4.8 KB msuraev, 06/06/2017 12:47 PM
osmo-bts.cfg-oml osmo-bts.cfg-oml 923 Bytes msuraev, 06/06/2017 12:47 PM
open-bsc.cfg-oml-rev open-bsc.cfg-oml-rev 4.8 KB msuraev, 06/06/2017 01:02 PM

Related issues

Related to OsmoBSC - Bug #1614: better identification of BTS model / capabilities to BSCStalled02/23/2016

Actions
Actions #1

Updated by msuraev almost 7 years ago

The reason seems to be down_fom() in OsmoBTS' oml.c:
...
if (foh->obj_inst.bts_nr != 0 && foh->obj_inst.bts_nr != 0xff) {
...
return oml_fom_ack_nack(msg, NM_NACK_BTSNR_UNKN);
}

Not sure if we can just drop this check or some adjustment on OpenBSC side is required as well.

There's also similar check in down_mom() so whatever fix we come up with should be applied to both.

Actions #2

Updated by msuraev almost 7 years ago

  • Related to Bug #1614: better identification of BTS model / capabilities to BSC added
Actions #3

Updated by laforge almost 7 years ago

  • Assignee set to msuraev

msuraev wrote:

The reason seems to be down_fom() in OsmoBTS' oml.c:
...
if (foh->obj_inst.bts_nr != 0 && foh->obj_inst.bts_nr != 0xff) {
...
return oml_fom_ack_nack(msg, NM_NACK_BTSNR_UNKN);
}

The above is not the reason but it is the consequence. It is the BSC side which is sending a wrong BTS number in the OML FOM header.

An A-bis OML link exists between a Site ("Cell Tower") and possibly multiple BTSs behind that link.

In the "multiple E1/T1 BTS" case this is actually a usual/common configuration to avoid having to use one separate E1 timeslot for each BTS, but to use a single E1 TS for multiple BTSs.

In the Abis/IP case this is actually never used to our knowledge. Each BTS will always establish a separate TCP connection for OML, so within the OML Formatted Object Messages header (fom_hdr) thre bts_nr field should always be set to zero.

Not sure if we can just drop this check or some adjustment on OpenBSC side is required as well.

dropping the check in OsmoBTS would be a work-around but not a solution to the actual bug.

Actions #4

Updated by msuraev almost 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

Gerrit 2868 has fix ready for review.

Actions #5

Updated by laforge over 6 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

gerrit patch merged.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)