Feature #1615
closedmake use of OML Alert
Added by laforge about 8 years ago. Updated almost 7 years ago.
100%
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
- 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
Updated by laforge almost 8 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.
Updated by neels almost 8 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)
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.
Updated by laforge over 7 years ago
- Related to Feature #1857: aggregate and report OML ALERT messages received from BTSs added
Updated by msuraev over 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.
Updated by msuraev over 7 years ago
- Status changed from In Progress to Stalled
Example BTS alerts were sent for review in gerrit 1525.
Updated by msuraev over 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.
Updated by laforge over 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)
Updated by msuraev over 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.
Updated by laforge over 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.
Updated by msuraev over 7 years ago
- Status changed from Stalled to In Progress
Gerrit # 1567-1570 were submitted for review.
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.
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.
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
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.
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 messagesNot 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).
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?
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.
Updated by msuraev about 7 years ago
- Checklist item deleted (
power supply related errors) - Checklist item deleted (
status information from the RF transmitter)
Updated by msuraev almost 7 years ago
- Checklist item propagation of PCU alarms to BSC via BTS set to Done
Updated by msuraev almost 7 years ago
- Status changed from Stalled to Resolved
- % Done changed from 90 to 100
Everything has been merged.
