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

#2 Updated by laforge almost 3 years ago

Status changed from New to In Progress

there is some work to that regard contributed by Minh from Nutaq, see https://gerrit.osmocom.org/#/c/255/ and related patches in that series.

#3 Updated by laforge almost 3 years ago

Assignee set to neels

#4 Updated by neels almost 3 years ago

Status changed from In Progress to New

Was assigned to me in "In Progress" state, but this ticket is not in my immediate awareness yet.
Setting to "New". ("Stalled" would be more accurate)

#5 Updated by laforge over 2 years ago

Assignee changed from neels to msuraev

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.

#6 Updated by laforge over 2 years ago

Priority changed from Normal to High

#7 Updated by laforge over 2 years ago

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

#8 Updated by msuraev over 2 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.

#9 Updated by msuraev over 2 years ago

Status changed from In Progress to Stalled

Example BTS alerts were sent for review in gerrit 1525.

#10 Updated by msuraev over 2 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.

#11 Updated by laforge over 2 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)

#12 Updated by msuraev over 2 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.

#13 Updated by laforge over 2 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.

#14 Updated by msuraev over 2 years ago

Status changed from Stalled to In Progress

Gerrit # 1567-1570 were submitted for review.

#15 Updated by msuraev over 2 years ago

Status changed from In Progress to Stalled

#16 Updated by msuraev over 2 years ago

% Done changed from 20 to 30

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

#17 Updated by msuraev over 2 years ago

% Done changed from 30 to 60

#18 Updated by msuraev over 2 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.

#19 Updated by msuraev over 2 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

#20 Updated by msuraev over 2 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.

#21 Updated by laforge over 2 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).