Project

General

Profile

Bug #2317

multibts setup produce unnecessary OML warning

Added by msuraev 5 months ago. Updated 3 months 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

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 5 months 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 5 months ago

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

#3 Updated by laforge 5 months 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 4 months ago

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

Gerrit 2868 has fix ready for review.

#5 Updated by laforge 3 months ago

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

gerrit patch merged.

Also available in: Atom PDF