Project

General

Profile

Bug #2317

multibts setup produce unnecessary OML warning

Added by msuraev 21 days ago. Updated 15 days ago.

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

50%

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

open-bsc.cfg-oml (4.8 KB) msuraev, 06/06/2017 12:47 PM

osmo-bts.cfg-oml (923 Bytes) msuraev, 06/06/2017 12:47 PM

open-bsc.cfg-oml-rev (4.8 KB) msuraev, 06/06/2017 01:02 PM


Related issues

Related to OpenBSC - Bug #1614: better identification of BTS model / capabilities to BSC Stalled 02/23/2016

History

#1 Updated by msuraev 21 days 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.

#2 Updated by msuraev 21 days ago

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

#3 Updated by laforge 21 days 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.

#4 Updated by msuraev 15 days ago

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

Gerrit 2868 has fix ready for review.

Also available in: Atom PDF