Feature #1615
make use of OML Alert
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
Associated revisions
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
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
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
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
Alarm on various errors
Send OML Failure Report for unsupported BTS attributes and other errors.
Change-Id: Ic163bcfb6361a8ebd39e0bc0f238ef51e2cb214e
Related: OS#1615
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
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
libosmogsm.map: fix typo
Change-Id: I71413fbe703e459782a235e5b1d8487265de3780
Related: OS#1615
Improve OML failure report
- clearly separate report parts
- use textual representation for failure cause if possible
Change-Id: I7a98a77011463021d0edd6ecfab1680e211f7e16
Related: OS#1615
Improve OML failure report
- clearly separate report parts
- use textual representation for failure cause if possible
Change-Id: I7a98a77011463021d0edd6ecfab1680e211f7e16
Related: OS#1615
OML: add external alerts
Add special cause for alerts produced by external processes.
Change-Id: Idd7ee085321f8172c72ecfdba320186049f4d988
Related: OS#1615
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
Add ctrl command to send OML alert
Change-Id: I228cb71ab945e19e3747843469a52f577ee32f97
Related: OS#1615
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
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
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
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
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
Save PCU version reported by BTS
When BTS reports PCU disconnect - clear it.
Change-Id: Idb32c73036413ee912f633604150ee17b611cfa7
Related: OS#1615
Save PCU version reported by BTS
When BTS reports PCU disconnect - clear it.
Change-Id: Idb32c73036413ee912f633604150ee17b611cfa7
Related: OS#1615
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 <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 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 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).
#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)
#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
Add OML definitions from OsmoBTS
Change-Id: I9c3bc15662949654e7bba6aad5488c69ee7d0c45
Related: OS#1615