Project

General

Profile

Actions

Feature #1615

closed

make use of OML Alert

Added by laforge about 8 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

100%

Spec Reference:

Description

A-bis OML has the capability of reporting alarms / errors towards the BSC for centralized reporting. We don't really use this in OsmoBTS so far.

The messages involved in this are
  • NM_MT_REP_OUTST_ALARMS
  • NM_MT_REP_OUTST_ALARMS_ACK
  • NM_MT_REP_OUTST_ALARMS_NACK
  • NM_MT_FAILURE_EVENT_REP
  • NM_MT_SET_ALARM_THRES
  • NM_MT_SET_ALARM_THRES_ACK
  • NM_MT_SET_ALARM_THRES_NACK
We should make use of this mechanism to report various alerms/errors to the BSC, including
  • over-temperature of any of the on-board temperature sensors
  • possible status information from the RF transmitter (too much reflected power measured, indicating antenna/cabling problems)
  • power supply related errors
  • protocol / PHY related errors

Checklist

  • protocol / PHY related errors
  • over-temperature of any of the on-board temperature sensors
  • propagation of PCU alarms to BSC via BTS

Related issues

Related to OsmoBSC - Feature #1857: aggregate and report OML ALERT messages received from BTSsNew11/18/2016

Actions
Actions #2

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

Actions #3

Updated by laforge over 7 years ago

  • Assignee set to neels
Actions #4

Updated by neels over 7 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)

Actions #5

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

Actions #6

Updated by laforge over 7 years ago

  • Priority changed from Normal to High
Actions #7

Updated by laforge over 7 years ago

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

Updated by msuraev about 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 #9

Updated by msuraev about 7 years ago

  • Status changed from In Progress to Stalled

Example BTS alerts were sent for review in gerrit 1525.

Actions #10

Updated by msuraev about 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 #11

Updated by laforge about 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 <> http://laforge.gnumonks.org/ ============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

Actions #12

Updated by msuraev about 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 #13

Updated by laforge about 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 #14

Updated by msuraev about 7 years ago

  • Status changed from Stalled to In Progress

Gerrit # 1567-1570 were submitted for review.

Actions #15

Updated by msuraev about 7 years ago

  • Status changed from In Progress to Stalled
Actions #16

Updated by msuraev about 7 years ago

  • % Done changed from 20 to 30

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

Actions #17

Updated by msuraev about 7 years ago

  • % Done changed from 30 to 60
Actions #18

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

Updated by msuraev about 7 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 #20

Updated by msuraev about 7 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 #21

Updated by laforge about 7 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 #22

Updated by msuraev about 7 years ago

How can we programmatically obtain "power supply related errors" and "status information from the RF transmitter"? How is that handled now?

Actions #23

Updated by laforge about 7 years ago

On Thu, Mar 09, 2017 at 11:50:16AM +0000, msuraev [REDMINE] wrote:

How can we programmatically obtain "power supply related errors" and
"status information from the RF transmitter"? How is that handled now?

this mostly relates only to the SOB-BTS, where such features were
planned. We can ignore this for now.

Actions #24

Updated by msuraev about 7 years ago

  • Checklist item deleted (power supply related errors)
  • Checklist item deleted (status information from the RF transmitter)
Actions #25

Updated by msuraev almost 7 years ago

  • % Done changed from 70 to 80

OsmoPCU part for supporting OML alerts has been merged in gerrit 2071, OsmoBTS part is under review in gerrit 2086 and 2087.

Actions #26

Updated by msuraev almost 7 years ago

2086 is merged, 2087 is under review.

Actions #27

Updated by msuraev almost 7 years ago

  • % Done changed from 80 to 90

Gerrit 2087 has been merged, 2288 and 2289 are under review.

Actions #28

Updated by msuraev almost 7 years ago

  • Checklist item propagation of PCU alarms to BSC via BTS set to Done
Actions #29

Updated by msuraev almost 7 years ago

  • Status changed from Stalled to Resolved
  • % Done changed from 90 to 100

Everything has been merged.

Actions #30

Updated by laforge almost 7 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)