Bug #2317
closedmultibts setup produce unnecessary OML warning
100%
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
Related issues
Updated by msuraev over 6 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.
Updated by msuraev over 6 years ago
- Related to Bug #1614: better identification of BTS model / capabilities to BSC added
Updated by laforge over 6 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.
Updated by msuraev over 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
Gerrit 2868 has fix ready for review.
Updated by laforge over 6 years ago
- Status changed from In Progress to Closed
- % Done changed from 50 to 100
gerrit patch merged.
