Trending UDC expression syntax

The following syntax for the trend and projectTime functions illustrates the structure that is used for each function.

trend(trend_sbh_kpi,busy_hour,regression_type,min_datapoints,number_regression_intervals)

projectTime(trend_sbh_kpi,busy_hour,regression_type,min_datapoints,num_regression_intervals,limit)

More than one trending function can be used in the same report. For example, functions, see Trending UDC expression syntax.

trend_sbh_kpi
Stored busy hour KPI field to use. Only stored busy hour KPIs at the focal entity can be used. A stored busy hour KPI is the KPI against whose busy hours the trend is calculated. A stored busy hour KPI is defined with a busy hour interval: the hour with the greatest value for a defined period (daily, weekly, or monthly). Stored busy hour KPIs are predefined. When you create a trending UDC, you select stored busy hour KPIs that has already been defined. When you select a stored busy hour KPI field, trend_sbh and busy_hour are entered for the expression.
busy_hour
The busy hour definition that is used to determine the busy hour for the SBH KPI.
regression_type
The regression algorithm to use: LINEAR, LOGARITHMIC, EXPONENTIAL. Each regression type uses a method to correlate data. In the case where the data set for a trending report contains values that must be excluded before regression is calculated. These are the values from bursty, erroneous, or bad data in the set.

To ensure that the best possible trend is being calculated these values (outliers) are excluded by using correlation coefficients.

Table 1. Regression types and correlation coefficients
Regression Type Correlation Coefficient
Linear Pearson
Logarithmic Spearman
Exponential Spearman

A Pearson co-relation is used where there is a linear relationship. For example, where a value increases linearly over time such as total calls or percentage capacity. A Spearman co-relation is used where the growth of the value over time is not linear, such as Erlang calculations.

min_datapoint
Integer. The minimum number of periods for a trend to be valid. The minimum number of periods represents the minimum number of stored busy hour values that must be available to be calculated. For example, if the number of data points is 3 and the busy hour is a daily stored busy hour, then there must be at least three days of stored busy hour data available. A value of 2 or greater must be used.
num_regression_intervals
Integer. The number of periods of the interval to use when you calculate the trend. The period that is used is determined by the busy hour interval. For example, if the busy hour interval is weeks and the number or periods to use is 14, then the stored busy hour KPI value is trended over 14 weeks.
limit
Float projectTime only. The value to project the trend against. Used to calculate the number of days between the current trend and the limit. This value can be represented by a constant, or by a traffic KPI (raw, Pcalc, or UDC). If a UDC is used, it must be defined at the same entity level as the trending UDC. The following functions are not supported for UDCs used to specify the limit:
  • NumToString
  • StringToInt
  • InGroup
  • IsNull
  • NullValue
  • decode
  • protect
  • nullInt
  • nullFloat
  • DataAvailKPI
  • DataAvailBlock
  • projectTime
  • trend
Examples
trend([Cell]![{Neutral.tch.sbhv.daily._%_blocking}], "Cell_TCH_Traffic_TEC_busy_hour","Linear" ,21,30). Trend %blocking based on its value at the busy hour over the last 30 days, with a minimum of 21 data points required. It means that at least 21 busy hours must be available to be calculated.projectTime([Cell]![{Neutral.tch.sbhv.daily._%_blocking}], "Cell_TCH_Traffic_TEC_busy_hour", "Linear",20,30, 1.5) Trend over the last 30 days of busy hour data to return the number of days until the limit of 1.5% is breached for %blocking.
Discovering why there is null in the result set
When you trend reports are run, null results can be returned for various reasons. Some of the reasons why a null result is returned can be demonstrated by running a separate SBH report for the KPI that forms the basis of the trending report. The following table lists some of the more common reasons for null results.
Table 2. Trending null results - reasons
Description Affects Reason
Trend gradient too small projectTime If the trend gradient is nearly flat. The limit that is breached extends too far in to the future.
Data that not correlated enough trend and projectTime

Trending data can be usefully interpreted only if the data is related enough.

If data is found not to be sufficiently correlated, a correlation coefficient (Pearson for linear or Spearman for non-linear) is used to remove outliers and the data is recalculated. If the data is still not sufficiently correlated, a null result is returned.
Not enough data points trend and projectTime

A trend value must be based on a set minimum number of data points. Usually at least 10. If this number is not reached, a null result is returned.

Consider changing the UDC used in the report to use more intervals, or use less data points. See Trending functions, for more information.
Negative numbers trend and projectTime for exponential regression Negative numbers cannot be included for reports, which use an exponential function. Where there are both negative and positive numbers, negative numbers are ignored. A trend is calculated on the positive numbers if there are enough data points.
Negative limit projectTime for exponential regression Negative numbers cannot be included for reports which use an exponential function.
Limit is in the past projectTime for exponential regression If the limit is a negative number, a projected time cannot be calculated.