Project

General

Profile

Bug #2486

show BTS up/down status + BTS uptime in BSC VTY + CTRL

Added by laforge 3 months ago. Updated 13 days ago.

Status:
Stalled
Priority:
Urgent
Assignee:
Target version:
-
Start date:
09/03/2017
Due date:
% Done:

70%

Spec Reference:

Description

An operator wants to clearly see if a given BTS is fully up+running, degraded or disconnected.

If it's up + running, he wants to see the uptime of the BTS since its last re-connect.

This information should be accesible both via VTY as well as CTRL

History

#1 Updated by laforge about 2 months ago

  • Assignee set to msuraev

#2 Updated by msuraev about 2 months ago

  • % Done changed from 0 to 10

It's implemented to some degree in the latest master of OsmoBSC:

OsmoBSC> sh bts 0
BTS 0 is of sysmobts type in band DCS1800, has CI 20909 LAC 200, BSIC 0 (NCC=0, BCC=0) and 1 TRX
...
Early Classmark Sending: forbidden
  Unit ID: 6969/0/0, OML Stream ID 0xff
  NM State: Oper 'Enabled', Admin 'Unlocked', Avail 'OK'
...
  OML Link state: connected 0 days 0 hours 0 min. 3 sec.
...

I can expose this over CTRL interface but there're few things to clarify first:
  • is current representation ok or it's better to reformat, show differently etc?
  • current implementation does not take into account leap year (after >= 1 year of uptime it might be 1 day inaccurate) - shall I try fixing it?
  • right now we show OML as either connected or disconnected. When shall we show "degraded" status?
  • shall we consider anything else in addition to OML?

#3 Updated by laforge about 2 months ago

Hi Max,

thanks for the status update.

On Fri, Oct 06, 2017 at 02:49:26PM +0000, msuraev [REDMINE] wrote:

I can expose this over CTRL interface but there're few things to clarify first:
  • is current representation ok or it's better to reformat, show differently etc?

I think the plain integer number of seconds would be best for a programmatic interface like CTRL

  • current implementation does not take into account leap year (after >= 1 year of uptime it might be 1 day inaccurate) - shall I try fixing it?

I think it doesn't matter, we can ignore this.

  • right now we show OML as either connected or disconnected. When shall we show "degraded" status?

If OML is connected but somehow not all MO's in the right state. Should
probably be a per-bts-model specific function that determines this. Can
be very simplistic at first, but then expanded later on.

Loss of RSL while OML is connected would also be degraded.

  • shall we consider anything else in addition to OML?

see above, I think for RSL it's should simply lead to "degraded"

#4 Updated by msuraev about 2 months ago

  • Status changed from New to In Progress

Thanks for clarification.

laforge wrote:

If OML is connected but somehow not all MO's in the right state. Should
probably be a per-bts-model specific function that determines this. Can
be very simplistic at first, but then expanded later on.

Is there some sort of MO list for some BTS model which I can use as an example for such check?

#5 Updated by laforge about 2 months ago

On Fri, Oct 06, 2017 at 03:54:52PM +0000, msuraev [REDMINE] wrote:

Issue #2486 has been updated by msuraev.

Status changed from New to In Progress

Thanks for clarification.

laforge wrote:

If OML is connected but somehow not all MO's in the right state. Should
probably be a per-bts-model specific function that determines this. Can
be very simplistic at first, but then expanded later on.

Is there some sort of MO list for some BTS model which I can use as an example for such check?

start simpleat first, extend later: Start with sysmoBTS :)

#6 Updated by msuraev about 1 month ago

  • % Done changed from 10 to 20

Check for OML link state which takes into consideration RSL link is available in gerrit 4169.
Note: this information is already available via CTRL in "oml-connection-state" RO command.

#7 Updated by msuraev about 1 month ago

  • % Done changed from 20 to 60

Gerrit 4169 has been merged. Ctrl command to get uptime (in seconds) is available in gerrit 4197.

#8 Updated by msuraev about 1 month ago

Gerrit 4169 has been merged.

Not sure what else can be checked for "degraded" state in case of sysmobts. In case of osmo-bts-trx we can also check for osmo-trx connectivity for example.

Also, documentation for ctrl commands (maybe vty too) needs update - I'll work on that first.

#9 Updated by laforge about 1 month ago

On Wed, Oct 11, 2017 at 02:14:25PM +0000, msuraev [REDMINE] wrote:

Not sure what else can be checked for "degraded" state in case of sysmobts.

I would presume the state of all the various OML MOs (managed objects). Unless they're
all in their expected state, state is degraded.

In case of osmo-bts-trx we can also check for osmo-trx connectivity for example.

If we miss a clock indication from osmo-trx for 1.8 seconds, we kill osmo-bts, so I think
there's no point in indicating a different status in the short time period in between.

#10 Updated by msuraev 18 days ago

  • Status changed from In Progress to Stalled
  • % Done changed from 60 to 70

Gerrit 4197 has been merged. Example use:
./bsc_control.py -d localhost -p 4249 -g bts.0.oml-connection-state

#11 Updated by msuraev 18 days ago

Gerrit 4648 sent for review with documentation update.

#12 Updated by msuraev 18 days ago

laforge wrote:

I would presume the state of all the various OML MOs (managed objects). Unless they're
all in their expected state, state is degraded.

If state is 'locked' for some MO - shall it be considered as "degraded"?

#13 Updated by laforge 18 days ago

On Thu, Nov 02, 2017 at 02:56:27PM +0000, msuraev [REDMINE] wrote:

Issue #2486 has been updated by msuraev.

laforge wrote:

I would presume the state of all the various OML MOs (managed objects). Unless they're
all in their expected state, state is degraded.

If state is 'locked' for some MO - shall it be considered as "degraded"?

I would argue yes.

In my dreams, at some point in the future the individual MOs would then
have osmo_fsm and one could inquire their detailed state via CTRL. But the overall
state is degraded in the situation you describe.

#14 Updated by laforge 13 days ago

  • Priority changed from Normal to High

#15 Updated by laforge 13 days ago

  • Priority changed from High to Urgent

Also available in: Atom PDF