4.2. Service Availability¶
Service Availability is a statistic parameter that is a numeric expression of a provided service quality. The availability formula is given in the ANSI/SCTE 168-6 recommendation:
where:
Monitoring Time — time of monitoring;
Error Seconds — number of Error Seconds detected during monitoring time.
The formula considers the monitoring time but not the service provision time, because we can reliably tell about presence or absence of errors only during the service monitoring. In the Boro system, availability calculation is divided into 15-minute (900 sec.) intervals, results of which are saved in the database. 15-minute intervals can be combined in the bigger one, e.g., an hourly or daily report. A monitoring time will differ from 24 hours (86400 sec.) in case:
a monitoring task is stopped;
a probe lost connection with the service and statistics cannot be recovered;
an analysis task crashes or hangs.
The idea behind error registration is that any incident occurring within a given second of time makes that second an error, even if the duration of the incident is much shorter than a second (e.g., a single packet loss). The ANSI/SCTE 168-6 recommendation refers to key metrics related to QoS availability: packet loss, signal loss, jitter. However, Boro provides the extended number of key metrics that are available in Project Settings ➝ KPI ➝ Service Availability. In fact, key metrics are similar to triggers of the notification system but have slightly different default settings. Additionally, the BadSource (No signal) metric is deprived of the opportunity to use the protective threshold, i.e., even a second absence of a signal will be considered as an error. An important point: the calculation of Error Seconds is carried out taking into account the overlapping of triggers, i.e., the number of Error Seconds cannot exceed the monitoring duration.
The user chooses by himself which errors should be taken into account for Service Availability calculation. You can use different combinations of key metrics for different types of analyzed protocols through the use of various KPI profiles. Please note that the triggers are divided into QoS and QoE groups, so the Boro system calculates three types of availability: QoS, QoE, and Total. This grouping enables us to identify more accurately what area is affected with a problem. As previously mentioned, availability is always calculated by taking into account the overlapping of all selected triggers, including the total availability.
To ease the identification of the quality degradation issues, the user can adjust the color scheme in Project Settings ➝ KPI ➝ Service Availability. The color scheme is used to paint graphs and mini graphs with trends. The set of used colors is similar to the system Alarm Severity color scheme. The default values of availability threshold are not regulated by any standard and can be configured by the user according to the company’s terms of service policy.
The Service Availability is displayed in the views:
Note
To calculate and display the Service Availability, you should apply the Availability profile in the settings of each task.