Project

General

Profile

Actions

Feature #1605

open

logging / ring buffer for ALERT messages from A-bis OML from the BTS side

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

Status:
In Progress
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

70%

Spec Reference:

Description

OML ALERT messages are currently not really used much. They should be used more from the BTS side, and the BSC component in the NITB should not only log them somewhere but possibly even keep an in-memory ring buffer for each BTS/TRX so one can inspect the most recent errors for those objects via the VTY.


Related issues

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

Actions
Actions #1

Updated by laforge over 7 years ago

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

Updated by laforge over 6 years ago

  • Project changed from OpenBSC to OsmoBSC
  • Category deleted (libbsc)
Actions #3

Updated by laforge over 5 years ago

  • Assignee set to osmith
Actions #4

Updated by laforge over 5 years ago

This is actually slightly similar to the "show last unsuccessful BTS connection attempts". In both cases we want to keep a ring-buffer of most recent events. However, the difference is that for ALERT, we want one FIFO ring buffer per BTS, while for the BTS connection attempts, we want one global ring buffer, and entries should be overwritten in case the same BTS attempts again...

Actions #5

Updated by osmith about 4 years ago

  • Status changed from New to In Progress
Actions #6

Updated by osmith almost 4 years ago

  • Description updated (diff)
  • % Done changed from 0 to 30

OML ALERT messages are currently not really used much. They should be used more from the BTS side

Nowadays, the BTS seems to make good use of the OML failure reports. Example patch

and the BSC component in the NITB should not only log them somewhere

I've verified that the BSC is logging these messages.

but possibly even keep an in-memory ring buffer for each BTS/TRX so one can inspect the most recent errors for those objects via the VTY.

This is what I'm working on now.

I realized that it is not possible to send OML failure reports from the TTCN-3 testsuite, only RSL error reports. So, for manual testing during development, I've added a test VTY command to osmo-bts-virtual to send an OML failure report to the BSC. (osmo-bts branch: osmith/alert-buffer)

This works, the OML failure reports arrive at the BSC and I found the place to handle them. I've added code to save it to a ring buffer and a VTY command to read it out. While testing, I'm currently getting segfaults when accessing the llist, although it is already initialized.

WIP branch for osmo-bsc: osmith/alert-buffer

Actions #7

Updated by laforge almost 4 years ago

On Fri, Mar 20, 2020 at 03:59:03PM +0000, osmith [REDMINE] wrote:

I realized that it is not possible to send OML failure reports from the TTCN-3 testsuite, only RSL error reports.

That's only half true. Since May 2019, library/AbisOML_* contains type
definitions, templates and an "Emulation" part for OML. Even
ts_OML_FailureEvtRep() exists. It's just that none of our existing
tests / testsuites uses it.

I currently don't see a reason why they couldn't be used. Sure, as a
first user you might run into bugs, but I think it should at least be
tried.

Actions #8

Updated by osmith almost 4 years ago

laforge wrote:

On Fri, Mar 20, 2020 at 03:59:03PM +0000, osmith [REDMINE] wrote:

I realized that it is not possible to send OML failure reports from the TTCN-3 testsuite, only RSL error reports.

That's only half true. Since May 2019, library/AbisOML_* contains type
definitions, templates and an "Emulation" part for OML. Even
ts_OML_FailureEvtRep() exists. It's just that none of our existing
tests / testsuites uses it.

Cool, I'll try this!

Actions #9

Updated by osmith almost 4 years ago

osmith wrote:

While testing, I'm currently getting segfaults when accessing the llist, although it is already initialized.

The wrong BTS pointer is getting passed, fix here: https://gerrit.osmocom.org/c/osmo-bsc/+/17569

Actions #10

Updated by osmith almost 4 years ago

  • % Done changed from 30 to 60

keep an in-memory ring buffer for each BTS/TRX so one can inspect the most recent errors for those objects via the VTY.

Patch submitted: https://gerrit.osmocom.org/c/osmo-bsc/+/17571

Another patch submitted with what I've been using for manual testing with OsmoBTS: https://gerrit.osmocom.org/c/osmo-bts/+/17573

Automated TTCN-3 test remains.

Actions #11

Updated by osmith almost 4 years ago

  • % Done changed from 60 to 70

Patches merged.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)