Project

General

Profile

Feature #1615

make use of OML Alert

Added by laforge about 5 years ago. Updated almost 4 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

Associated revisions

Revision 0bee65c0 (diff)
Added by max about 4 years ago

Add OML definitions from OsmoBTS

Change-Id: I9c3bc15662949654e7bba6aad5488c69ee7d0c45
Related: OS#1615

Revision 592fcc97 (diff)
Added by mqng2 about 4 years ago

Add cause enum for OML fail reports

Add 3GPP TS 12.21 §9.4.43 Probable Cause values of type 03 (Manufacturer
specific values).

Max's note: renamed to make it clear that values are vendor-specific.

Related: OS#1615
Change-Id: Ie9ba4b53fb19a151447aec9ea309284e20613585

Revision 07352fee (diff)
Added by max about 4 years ago

Add event cause string descriptions

Add human-readable descriptions to event causes from 3GPP TS 12.21 §
9.4.43.

Change-Id: Id173c978616c98b7831fbafb5401064257f1cf73
Related: OS#1615

Revision ecbcdf52 (diff)
Added by max about 4 years ago

Add OML Failure Event Report support

Add 3GPP TS 12.21 § 8.8.2 Failure Event Report function which pack given
vararg string and parameters into msgb.

Change-Id: I58c198d8ea588432c62520928b08f0b2a7035e93
Related: OS#1615

Revision c038cb79 (diff)
Added by max about 4 years ago

Add Abis OML failure event reporting

Send 3GPP TS 12.21 § 8.8.2 Abis/OML failure event report.

Change-Id: Ib1170edca2207752984a554d7a6a57c224f6d5f5
Related: OS#1615

Revision ec11a859 (diff)
Added by max about 4 years ago

Alarm on various errors

Send OML Failure Report for unsupported BTS attributes and other errors.

Change-Id: Ic163bcfb6361a8ebd39e0bc0f238ef51e2cb214e
Related: OS#1615

Revision 85908a9c (diff)
Added by max about 4 years ago

Add value strings for Probable Cause Type

Add string representation of Probable Cause Type from 3GPP TS 12.21 §
9.4.43.

Change-Id: I9fe14ed3b5398f59dd06a509e4d419e074cc20a7
Related: OS#1615

Revision 1251afe2 (diff)
Added by max about 4 years ago

Add abis_nm_fail_evt_vrep() function

It accept fixed number of arguments including va_list instead of variable
number of arguments in abis_nm_fail_evt_rep() - similar to vprintff() vs
printf().

Related: OS#1615
Change-Id: Ib293dec1c2de9b664584a8456c782ea7b6dd8555

Revision 6e8c1724 (diff)
Added by max about 4 years ago

libosmogsm.map: fix typo

Change-Id: I71413fbe703e459782a235e5b1d8487265de3780
Related: OS#1615

Revision a5e36930 (diff)
Added by max about 4 years ago

Improve OML failure report

  • clearly separate report parts
  • use textual representation for failure cause if possible

Change-Id: I7a98a77011463021d0edd6ecfab1680e211f7e16
Related: OS#1615

Revision 5a9d8bc9 (diff)
Added by max about 4 years ago

Improve OML failure report

  • clearly separate report parts
  • use textual representation for failure cause if possible

Change-Id: I7a98a77011463021d0edd6ecfab1680e211f7e16
Related: OS#1615

Revision 319f321d (diff)
Added by max about 4 years ago

OML: add external alerts

Add special cause for alerts produced by external processes.

Change-Id: Idd7ee085321f8172c72ecfdba320186049f4d988
Related: OS#1615

Revision 871e0bec (diff)
Added by max about 4 years ago

OML: internalize failure reporting

  • make oml_tx_failure_event_rep() static and use osmo_signal_dispatch()
    wrapped into oml_fail_rep() to trigger event reports outside of oml.c
    instead of directly calling into OML layer
  • remove unnecessary formatting from text messages

Related: OS#1615
Change-Id: I738555c547926e97b325ab53763c0076c42309bc

Revision f65b57a7 (diff)
Added by max about 4 years ago

Add ctrl command to send OML alert

Change-Id: I228cb71ab945e19e3747843469a52f577ee32f97
Related: OS#1615

Revision fa9e05e7 (diff)
Added by max about 4 years ago

Expand and expose ctrl connection allocation

Add function for allocating CTRL connection to public headers and
replace call to previous static function with it. Add doxygen docs for
this function.

It's useful if we need to allocate ctrl connection but don't need to
bind to any interfaces: when we act as ctrl client.

Related: OS#1615
Change-Id: I522ed809cbebfd3d7dd08b4ed9137b39ff192e32

Revision 4acc98e6 (diff)
Added by max about 4 years ago

Use oml-alert CTRL command for temp report

Send temperature reports via OML alert facility exposed by CTRL
protocol.

Change-Id: If29fbd0ab01fefc76e87b90cf1fbc81b2089ba76
Related: OS#1615

Revision 9756c469 (diff)
Added by max almost 4 years ago

Fix client-side ctrl interface helpers

  • remove unused ctrl_interface_connect() which is not part of public API
  • add default read callback to osmo_ctrl_conn_alloc()

Change-Id: Iaa209e34a849ce0dfe2e29b482c3208ade1a32a4
Related: OS#1615

Revision 70c7d416 (diff)
Added by max almost 4 years ago

Use value_string for ctrl_type

Use value_string for enum ctrl_type instead of custom code. Add
corresponding unit tests.

Related: OS#1615
Change-Id: Icd4e96dd9f00876cb70b43cfcf42ab4f10311b28

Revision 2ed3659c (diff)
Added by max almost 4 years ago

Handle replies in ctrl_cmd_handle()

Previously *_REPLY and ERROR messages were not explicitly handled which
would lead to sending error in response to them which in turn would
prompt other party to send error as well which would result in infinite
cycle.

Handle it explicitly by logging message id and other relevant data.

Change-Id: Id96f3a2fc81fa4549f49556d83f062c6b2f59e28
Related: OS#1615

Revision a18001d5 (diff)
Added by max almost 4 years ago

Save PCU version reported by BTS

When BTS reports PCU disconnect - clear it.

Change-Id: Idb32c73036413ee912f633604150ee17b611cfa7
Related: OS#1615

Revision c9f43c1f (diff)
Added by max almost 4 years ago

Save PCU version reported by BTS

When BTS reports PCU disconnect - clear it.

Change-Id: Idb32c73036413ee912f633604150ee17b611cfa7
Related: OS#1615

Revision 9d5ec1af (diff)
Added by max almost 4 years ago

Signal to BSC when PCU disconnects

While at it - do not serialize NULL as a string when delivering OML
Failure Report.

Change-Id: I41a731bd719aee0bbb98d3236405fb3a7f3ddec0
Related: OS#1615

History

#2 Updated by laforge over 4 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 over 4 years ago

  • Assignee set to neels

#4 Updated by neels over 4 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 4 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 4 years ago

  • Priority changed from Normal to High

#7 Updated by laforge over 4 years ago

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

#8 Updated by msuraev about 4 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 about 4 years ago

  • Status changed from In Progress to Stalled

Example BTS alerts were sent for review in gerrit 1525.

#10 Updated by msuraev about 4 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 about 4 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)

#12 Updated by msuraev about 4 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 about 4 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 about 4 years ago

  • Status changed from Stalled to In Progress

Gerrit # 1567-1570 were submitted for review.

#15 Updated by msuraev about 4 years ago

  • Status changed from In Progress to Stalled

#16 Updated by msuraev about 4 years ago

  • % Done changed from 20 to 30

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

#17 Updated by msuraev almost 4 years ago

  • % Done changed from 30 to 60

#18 Updated by msuraev almost 4 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 almost 4 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 almost 4 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 almost 4 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).

#22 Updated by msuraev almost 4 years ago

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

#23 Updated by laforge almost 4 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.

#24 Updated by msuraev almost 4 years ago

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

#25 Updated by msuraev almost 4 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.

#26 Updated by msuraev almost 4 years ago

2086 is merged, 2087 is under review.

#27 Updated by msuraev almost 4 years ago

  • % Done changed from 80 to 90

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

#28 Updated by msuraev almost 4 years ago

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

#29 Updated by msuraev almost 4 years ago

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

Everything has been merged.

#30 Updated by laforge almost 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)