Feature #1615: make use of OML Alert - OsmoBTS - Open Source Mobile Communications

please check the related patches by minh in gerrit, which unfortunately have been abandoned. Let's get at least the core support for generating alarms cleaned up and merged, and then add a few basic alarm cases.

Actions

Copy link

#6

Updated by laforge about 7 years ago

Priority changed from Normal to High

Actions

Copy link

#7

Updated by laforge about 7 years ago

Related to Feature #1857: aggregate and report OML ALERT messages received from BTSs added

Actions

Copy link

#8

Updated by msuraev almost 7 years ago

Status changed from New to In Progress
% Done changed from 0 to 10

Basic support has been sent for review in gerrit # 1519-1522.

Actions

Copy link

#9

Updated by msuraev almost 7 years ago

Status changed from In Progress to Stalled

Example BTS alerts were sent for review in gerrit 1525.

Actions

Copy link

#10

Updated by msuraev almost 7 years ago

% Done changed from 10 to 20

Support for simple OML alerts have been merged: so far we only supports "push" mode - when BTS face particular error Alarm is immediately sent to BSC. What's missing is:
- support for "pull" mode (NM_MT_REP_OUTST*)
- threshold support (NM_MT_SET_ALARM_THRES*)
- propagation of PCU alarms to BSC via BTS
- sensors error related alarms

The last 2 points are rather straightforward, the first 2 will require some state/configuration stored somewhere. Would be nice to have detailed example of what kind of alarms and how shall be reported in "pull" mode above.

Actions

Copy link

#11

Updated by laforge almost 7 years ago

On Mon, Jan 09, 2017 at 09:19:48AM +0000, msuraev [REDMINE] wrote:

Support for simple OML alerts have been merged

great.

What's missing is:
- support for "pull" mode (NM_MT_REP_OUTST*)
- threshold support (NM_MT_SET_ALARM_THRES*)

I don't think we need the above two.

- propagation of PCU alarms to BSC via BTS
- sensors error related alarms

yes, those two are quite more important. The PCU interface can easily
be extended b an additional message type for those alarms.

However, in terms of environmental/sensor alarms, we need a way how an
external process can originate/create such alarms.

Our old idea for this was to extend the osmobts-mgr into something that
includes an 'OML router / proxy' functionality between the BSC and
osmo-bts. This would also be required for stacked sysmBTS acting as one
multi-TRX BTS, but there never was a pressing need to support this.

So I think in the context of this ticket, a simpler and less intrusive
mechanism would probably make sense. Maybe a CTRL command to
generate/push an OML ALERT from external program? Any ideas?

--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

Actions

Copy link

#12

Updated by msuraev almost 7 years ago

laforge wrote:

However, in terms of environmental/sensor alarms, we need a way how an
external process can originate/create such alarms.

Is there a way to access those programmatically from *bts code? How such events are handled now? Is there some script/command which I should adopt to use ctrl interface?

So I think in the context of this ticket, a simpler and less intrusive
mechanism would probably make sense. Maybe a CTRL command to
generate/push an OML ALERT from external program? Any ideas?

Sounds good to me - it's also useful for debugging.

Actions

Copy link

#13

Updated by laforge almost 7 years ago

msuraev wrote:

laforge wrote:

However, in terms of environmental/sensor alarms, we need a way how an
external process can originate/create such alarms.

Is there a way to access those programmatically from *bts code? How such events are handled now? Is there some script/command which I should adopt to use ctrl interface?

See sysmobts_mgr_temp.c for example on how this is done in the sysmoBTS 2050.

In general, we should have some generic way how other processes can report alarms. The rest ist then up to the particular hardware vendor.

Actions

Copy link

#14

Updated by msuraev almost 7 years ago

Status changed from Stalled to In Progress

Gerrit # 1567-1570 were submitted for review.

Actions

Copy link

#15

Updated by msuraev almost 7 years ago

Status changed from In Progress to Stalled

Actions

Copy link

#16

Updated by msuraev almost 7 years ago

% Done changed from 20 to 30

Gerrit 1629, 1895-1897 have been merged. Gerrit 1630 is under review.

Actions

Copy link

#17

Updated by msuraev over 6 years ago

% Done changed from 30 to 60

Actions

Copy link

#18

Updated by msuraev over 6 years ago

Status changed from Stalled to In Progress
% Done changed from 60 to 70

Gerrit 1630 has been merged, alarms from PCU are underway.

Actions

Copy link

#19

Updated by msuraev over 6 years ago

Checklist item protocol / PHY related errors added
Checklist item power supply related errors added
Checklist item status information from the RF transmitter added
Checklist item over-temperature of any of the on-board temperature sensors added

Actions

Copy link

#20

Updated by msuraev over 6 years ago

Checklist item propagation of PCU alarms to BSC via BTS added
Status changed from In Progress to Stalled

We have 2 options for propagating PCU alarms to BSC:
1) use bts' ctrl interface from pcu to send alarms as external
2) extend bts-pcu socket protocol with oml-specific messages

Not sure which one would be better.

Actions

Copy link

#21

Updated by laforge over 6 years ago

Hi Max,

On Tue, Mar 07, 2017 at 05:55:49PM +0000, msuraev [REDMINE] wrote:

We have 2 options for propagating PCU alarms to BSC:
1) use bts' ctrl interface from pcu to send alarms as external
2) extend bts-pcu socket protocol with oml-specific messages

Not sure which one would be better.

I think it's better to extend the bts-pcu protocol, as this can then be
identical in pcu+bts setups as well as pcu+bsc setups (ericsson).

Actions

Copy link

#22