Obtaining Measurements
Available Languages
Table Of Contents
Types of Measurement Intervals
Noncarrier Measurement Production
Carrier-Based Measurement Production
Statistics Subsystem Functions
Configured vs. Dynamic Trunk Group Output
Preliminary vs. Final Measurements
Nonprovisioned Trunk Group Measurements
MGCP Dial and MGCP Scripting Handoff Measurements
Obtaining Measurements
Introduction
The Statistics module on the Cisco Billing and Measurements Server (BAMS) computes, augments, generates, and maintains performance indicators. Performance indicators amount to a history of traffic statistics on a telephone or data network. Counters are calculated for various events (for example, number of call attempts, call duration) for a particular time period. Each counter is associated with a time stamp and a key formed by the concatenation of several fields copied out of the Call Detail Record (CDR) being processed.
Counters that correspond to the same key within the same time period are added together, producing an accumulated count. For this reason, performance indicators are also known as accumulators. That is, "accumulators" and "counters" are used interchangeably to refer to performance indicators.
BAMS maintains counters for three different interval categories (real time, hourly, and daily intervals).
BAMS also maintains a flat file for each collection interval. In order for information to be timely, as soon as an interval boundary is reached, the buckets for that interval are written to disk. As the measurements are written, each measurement is checked against a user-defined threshold value and test condition.
Types of Measurements
Each measurement value represents an accumulation of activity that took place during the measurement interval. At any point in time, three intervals are being collected in parallel, in real-time, hourly, and daily. Measurement values are organized into measurement groups. There are two types of measurement groups: noncarrier and carrier-based. For each noncarrier group, 45 different measurements are accumulated. For each carrier-based group, eight different measurements are accumulated.
Types of Measurement Intervals
The Accumulation (ACC) task generates measurements for one variable, real-time interval, or period and two fixed-time intervals. At any moment in time, two collection windows are open for updating, the current window called "N," and the most recent window called "N-1." Each N and N-1 collection window consists of real-time, hourly, and daily counters. The two open windows are necessary because the Cisco Media Gateway Controller (MGC) does not produce a CDR at the first Initial Address Message (IAM) or seizure. Instead, it produces the CDR at the time of answer or abandonment of the call.
Because of the particular time points that are recorded by the Cisco MGC, an event might not be reported until after the collection interval has been closed, even though the event should have been credited to that interval. The one exception to the two-window rule is at startup, where only the current window is open. That remains the case until after the first interval boundary is crossed.
Real-Time Intervals
You can configure the real-time interval to any of the following durations: 5 minutes, 10 minutes, 15 minutes, 20 minutes, or 30 minutes. The default real-time interval is 15 minutes. All real-time measurements are stored in files whose names have the prefix acc_r.
Hourly Intervals
The hourly interval contains the sum of all of the real-time intervals that took place during the hour. For this reason, 60 minutes must be evenly divisible by the real-time interval length. All hourly measurements are stored in files whose names have the prefix acc_h.
Daily Intervals
The daily interval contains the sum of all of the hourly intervals that took place during the day. All daily measurements are stored in files whose names have the prefix acc_d.
Noncarrier Measurements
Noncarrier measurements are organized by trunk group. Table 11-1 lists these measurements and their mnemonics. It also describes each measurement's trigger time point and tag, derivation, and mapping.
Note
For a list of which measurements are suppressed or not pegged based on the PGW_DYNAMIC_UPDATE value, see "Setting the PGW Dynamic Update Mode" section.
Table 11-1 Noncarrier Measurements
Call Attempts Incoming
1010 or 1030 received, Tag 4100 or 4101.
BAM:IGR CALL ATT
Pegged when a 1010 CDB is recorded with 4008 or when 1030 recorded with 4008
Call Attempts Outgoing
1010 or 1030 received, Tag 4100 or 4101.
BAM:EGR CALL ATT
Pegged when a 1010 CDB is recorded with 4015 or when 1030 recorded with 4015. Suppressed in MGCP Dial or MGCP Scripting calls.
Outgoing Attempts Blocked
1030 or 1040 received, Tag 4100 or 4101.
BAM:EGR CALL BLKD
4015 populated, 1030 or 1040 with (Cause Code) Tag {2008 or 3008}== {21, 25, 27, 29, 34, 38, 41, 42, 44, 46, 47, 53, 63}. Suppressed in MGCP Dial or MGCP Scripting calls.
Failed Calls-Congestion
1030 or 1040 received, Tag 4100 or 4101.
BAM:TTL FAILED CONGEST
Peg for all 1030 or 1040 where {2008 or 3008} == {42, 44, 47}
Successful Calls Incoming
1040 or 1030 received, later of Tag 4106 or 4107.
BAM:IGR TERM NORM
Peg for all 1040 CDB or 1030 CDB where 4008 is populated and {2008 or 3008} == {16, 17, 18, 19, 31}
Successful Calls Outgoing
1040 or 1030 received, later of Tag 4106 or 4107.
BAM:EGR TERM NORM
Pegged when 1040 or 1030 CDB recorded with 4015 populated and {2008 or 3008} == {16, 17, 18, 19, 31}. Suppressed in MGCP Dial or MGCP Scripting calls.
Percent Trunk Group Usage Incoming
Starts when 1010 received (Tag 4100 or 4101). Closes when interval is closed or 1040 received.
BAM:IGR PCT TRK USE
Measured as a percentage of time that circuits are occupied based on the total number of circuits belonging to a trunk group over the provisioned interval of measurement. Any circuit on Tag 4008 triggers this measurement from CDB Tag 1010. The starting time point is the earlier of 4100 or 4101. The end timepoint is in the 1040 CDB and is the later of tag 4108 or 4109. When the PGW_DYNAMIC_UPDATE flag is set to true, this measurement is suppressed before a 1071 CDB is received on a trunk group. Also, it is suppressed for dynamically added trunk groups.
Percent Trunk Group Usage Outgoing
Starts when 1010 received (Tag 4100 or 4101). Closes when interval is closed or 1040 received.
BAM:EGR PCT TRK USE
Measured as a percentage of time that circuits are occupied based on the total number of circuits belonging to a trunk group over the provisioned interval of measurement. Any circuit on Tag 4015 triggers this measurement from CDB Tag 1010. The starting time point is the earlier of 4100 or 4101. The end timepoint is in the 1040 CDB and is the later of tag 4108 or 4109. When the PGW_DYNAMIC_UPDATE flag is set to true, this measurement is suppressed before a 1071 CDB is received on trunk group. Also, it is suppressed in MGCP Dial or MGCP Scripting mode. This measurements is always suppressed for dynamically added trunk groups.
Note
Maintenance Duration per Trunk Group
Starts when 1071 received (Tag 4100 or 4101). Closes when interval is closed or another 1071 received.
BAM:TTL MAINT USE
Only available with PGW release 9.4(1) or later and if the PGW_DYNAMIC_UPDATE flag is set to true. Measured as a percentage of time that circuits are occupied based on the total number of circuits belonging to a trunk group over the provisioned interval of measurement. When the 1071 CDB contains the number of circuits unavailable for a trunk group, BAMS is able to track the number of circuits out of service. This measurement is available only if the PGW_DYNAMIC_UPDATE flag is set to true and the trunk group is configured in the Trunk Group table. The measurement is suppressed before a 1071 is received. It is always suppressed for dynamically added trunk groups.
Total Traffic in Erlangs
Starts when 1010 received (Tag 4100 or 4101). Closes when interval is closed or 1040 received.
BAM:TTL ERLANGS
Measured as Erlangs for both Ingress and Egress for a trunk group. Use total seconds duration, from 1010 CDB, use timepoint in earlier of 4100 or 4101. For the end of the duration, use the later of 4108 or 4109. Erlangs = (total seconds) / (seconds in measured interval).
Example: For a one-hour measurement, with 99,000 secs measured, the formula would be (99,000)/(3600 secs) = 27.5 Erlangs.
If the same measurement occurred over a 15-minute interval, the formula would be (99,000)/
(900 secs) = 110 Erlangs.Total Calls Terminated Normally
1040 received (Tag 4106 or 4107)
BAM:TTL TERM NORM
Pegged when 1040 CDB recorded and release code in the set {16, 17, 18, 19, 31}
Calls Terminated Abnormally
1030 or 1040 received (Tag 4106 or 4107)
BAM:TTL TERM ABNORM
Pegged for any 1040 where {2008 or 3008} != {16, 17, 18, 19, 31} or for 1030 CDB with any release code.
Calls Terminated, Failed MGW or NAS
1030 or 1040 received (Tag 4106 or 4107)
BAM:TTL TERM FAILED MGW
Pegged for any 1030 or 1040 CDB where {2008 or 3008} == {29}
Calls Rejected
1030 CDB received (Tag 4100 or 4101)
BAM:TTL CALLS REJECTED
Pegged for any 1030 CDB where {2008 or 3008} == {21}
Calls Rejected, Unknown Dialed Number
1030 CDB received (Tag 4100 or 4101)
BAM:TTL REJECTED DIALNUM
Pegged for any 1030 CDB where {2008 or 3008} == {1, 5, 22, 28}
Calls Rejected, Other Reasons
1030 CDB received (Tag 4100 or 4101)
BAM:TTL REJECTED OTHER
Pegged for any 1030 CDB where {2008 or 3008} != {1,5,16,17,18,19,21,22,28,29}
Overflow, Outgoing Attempts Blocked
1030 CDB received (Tag 4100 or 4101)
BAM:EGR OFL BLKD
Pegged for 1030 CDB where 4015 is populated and {2008 or 3008} == {27, 34, 41, 42, 44, 47, 53, 63}. Suppressed in MGCP Dial or MGCP Scripting calls.
Total Sum of Usage Pegs per Trunk Group
1010 or 1030 CDB received (Tag 4100 or 4101)
BAM:TTL TRAFFIC USAGE PEGS
Pegged for any 1010 or 1030 CDB.
Tandem Routing Attempts, Outgoing
1010 or 1030 CDB received (Tag 4100 or 4101)
BAM:EGR TANDEM ATT
Pegged when Tag 4015 (trunk group) is marked T (tandem connection) for 1010 or 1030 CDB. Always suppressed for dynamically added trunk groups. Also suppressed in MGCP Dial or MGCP Scripting calls.
Tandem Completions, Outgoing
1010 CDB received (Tag 4100 or 4101)
BAM:EGR TANDEM COMPLT
Pegged when Tag 4015 (trunk group) is marked T (tandem connection) for 1010 CDB. Always suppressed for dynamically added trunk groups. Also suppressed in MGCP Dial or MGCP Scripting calls.
Tandem Attempts, Incoming
1010 or 1030 CDB received (Tag 4100 or 4101)
BAM:IGR TANDEM ATT
Pegged when Tag 4008 (trunk group) is marked T (tandem connection) for 1010 or 1030 CDB. Always suppressed for dynamically added trunk groups.
Tandem Completions, Incoming
1010 CDB received (Tag 4100 or 4101)
BAM:IGR TANDEM COMPLT
Pegged when Tag 4008 (trunk group) is marked T (tandem connection) for 1010 CDB. Always suppressed for dynamically added trunk groups.
Tandem Duration, Outgoing
1010 CDB received (Tag 4100 or 4101)
BAM:EGR TANDEM DUR
Duration measured when Tag 4015 (trunk group) is marked T (tandem connection) for 1010 CDB. Always suppressed for dynamically added trunk groups.
Tandem Duration, Incoming
Starts when 1010 received (Tag 4100 or 4101). Closes when interval is closed or 1040 received (tag 4108 or 4109).
BAM:IGR TANDEM DUR
Duration measured when Tag 4008 (trunk group) is marked T (tandem connection) for 1010 CDB. Start with earlier of timepoint in 4100 or 4101 of 1010 CDB, end with later of 4108 or 4109 in 1040 CDB. Always suppressed for dynamically added trunk groups.
Conversation Duration Ingress
Starts when 1010 received (Tag 4100 or 4101). Closes when interval is closed or 1040 received (tag 4108 or 4109).
BAM:IGR CONV
DURATIONDuration measured from the later of tag 4104 or 4105 in the 1010 CDB, until the earlier of tag 4106 or 4107, when tag 4008 is populated with a valid trunk group number.
Conversation Duration Egress
Starts when 1010 received (Tag 4100 or 4101). Closes when interval is closed or 1040 received (tag 4108 or 4109).
BAM:EGR CONV
DURATIONDuration measured from the later of tag 4104 or 4105 in the 1010 CDB, until the earlier of tag 4106 or 4107, when tag 4015 is populated with a valid trunk group number. Suppressed in MGCP Dial or MGCP Scripting calls.
Setup Duration Ingress
1010 or 1030 CDB received (Tag 4100 or 4101)
BAM:IGR SETUP
DURATIONDuration measured from timepoint in earlier of tag 4100 or 4101 of 1010 CDB end with later of 4102 or 4103 in 1010 CDB. For 1030 CDB, start with earlier of 4100 or 4101, and end with earlier of 4106 or 4107, when tag 4008 is populated with a valid trunk group number.
Setup Duration Egress
1010 or 1030 CDB received (Tag 4100 or 4101)
BAM:EGR SETUP DURATION
Duration measured from timepoint in earlier of tag 4100 or 4101 of 1010 CDB end with later of 4102 or 4103 in 1010 CDB. For 1030 CDB, start with earlier of 4100 or 4101, and end with earlier of 4106 or 4107, when tag 4015 is populated with a valid trunk group number. Suppressed in MGCP Dial or MGCP Scripting calls.
Teardown Duration Ingress
1030 or 1040 CDB received (Tag 4106 or 4107)
BAM:IGR TEARDOWN DURATION
Duration measured from timepoint in earlier of 4106 or 4107 end with later of 4108 or 4109, when tag 4008 is populated with a valid trunk group number.
Teardown Duration Egress
1030 or 1040 CDB received (Tag 4106 or 4107)
BAM:EGR TEARDOWN DURATION
Duration measured from timepoint in earlier of 4106 or 4107 end with later of 4108 or 4109, when tag 4015 is populated with valid trunk group number. Suppressed in MGCP Dial or MGCP Scripting calls.
Call Routing I Peg
1030 or 1010 CDB received (Tag 4100 or 4101)
BAM:TTL CALL
ROUTING IPegged when ingress and egress traffic terminations are maintained by the same gateway. This measurement is pegged when tag 4038 and tag 4039 are equal and neither tag 4069 nor 4073 equals 6 (EISUP).
Call Routing II Peg
1030 or 1010 CDB received (Tag 4100 or 4101)
BAM:TTL CALL
ROUTING IIPegged when ingress and egress traffic terminations are maintained by the different gateways, but under control of the same MGC. This measurement is pegged when tag 4038 and tag 4039 are not equal and neither tag 4069 nor 4073 equals 6.
Call Routing III Peg
1030 or 1010 CDB received (Tag 4100 or 4101)
BAM:TTL CALL
ROUTING IIIPegged when one side of a call originates or terminates under the control of a gateway connected to the MGC, but the other side of the call terminates in another network not under the control of the MGC. This measurement is pegged when either tag 4069 or 4073 equals 6.
Successful H.323 Terminating Pegs
1010 CDB received (Tag 4100 or 4101)
BAM:EGR SUCCESSFUL H.323
Pegged when a 1010 CDB is received with a tag 4073 and a value of 7.
Note
Successful H.323 Originating Pegs
1010 CDB received (Tag 4100 or 4101)
BAM:IGR SUCCESSFUL H.323
Pegged when a 1010 CDB is received with a tag 4069 and a value of 7.
Note
Unsuccessful H.323 Terminating Pegs
1030 CDB received (Tag 4100 or 4101)
BAM:EGR UNSUCCESSFUL H.323
Pegged when a 1030 CDB is received with a tag 4073 with a value of 7.
Note
Unsuccessful H.323 Originating Pegs
1030 CDB received (Tag 4100 or 4101)
BAM:IGR UNSUCCESSFUL H.323
Pegged when a 1030 CDB is received with a tag 4069 of value 7.
Note
Successful ISUP Terminating Pegs
1010 CDB received (Tag 4100 or 4101)
BAM:EGR SUCCESSFUL ISUP
Pegged when a 1010 CDB is received with a tag 4073 of value 0.
Successful ISUP Originating Pegs
1010 CDB received (Tag 4100 or 4101)
BAM:IGR SUCCESSFUL ISUP
Pegged when a 1010 CDB is received with a tag 4069 of value 0.
Unsuccessful ISUP Terminating Pegs
1030 CDB received (Tag 4100 or 4101)
BAM:EGR UNSUCCESSFUL ISUP
Pegged when a 1030 CDB is received with a tag 4073 of value 0.
Unsuccessful ISUP Originating Pegs
1030 CDB received (Tag 4100 or 4101)
BAM:IGR UNSUCCESSFUL ISUP
Pegged when a 1030 CDB is received with a tag 4069 of value 0.
ISDN Terminating Setup Message Delay Pegs
1010 or 1030 CDB received (Tag 4100 or 4101)
BAM:EGR ISDN SETUP MSG DELAY
Pegged when a 1010 or 1030 CDB is received with a tag 4073 with a value of 0, when the setup duration > 3000 ms. The setup duration is measured from timepoint in the earlier of tag 4100 or 4101 of a 1010 CDB. Setup ends with the later of 4102 or 4103.
ISDN Originating Setup Message Delay Pegs
1010 or 1030 CDB received (Tag 4100 or 4101)
BAM:IGR ISDN SETUP MSG DELAY
Pegged when a 1010 or 1030 CDB is received with a tag 4069 having a value of 0, when the setup duration > 3000 ms. The setup duration is measured from timepoint in the earlier of tag 4100 or 4101 of a 1010 CDB. Setup ends with the later of 4102 or 4103.
Number of Defined CICs during the Measurement Period
Start of measurement interval
BAM:TTL CIC DEFINED
Number of circuits provisioned in the Trunk Group table when the PGW_DYNAMIC_UPDATE flag is set to false. Or the value for the number of circuits in the trunk group received from the latest 1071 CDB when the PGW_DYNAMIC_UPDATE flag is set to true.
Suppressed before 1071 CDB is received on trunk group when the PGW_DYNAMIC_UPDATE flag is set to true. Always suppressed for dynamically added trunk groups.
Note
Average Number of Available CICs during the Measurement Period
1071 received
BAM:TTL AVLBL CIC
Total - (maintDuration ÷ intervalLength)
•
•
•
Only available if the PGW_DYNAMIC_UPDATE flag is set to true and trunk group is configured in the Trunk Group table. Suppressed before 1071 CDB is received on trunk group. Always suppressed for dynamically added trunk groups.
Carrier-Based Measurements
Carrier-based measurements are grouped by Trunk Group/Interexchange Carrier (IC). Table 11-2 lists these measurements with their mnemonics. It also describes each measurement's trigger time point and tag, derivation, and mapping.
Storage of Measurements
Both carrier-based and noncarrier measurements are stored internally in groups. Each group consists of all the measurements that belong to a particular key. These measurements are then put in subgroups according to interval. Each measurement group contains real-time, hourly, and daily measurements. There are two types of keys or measurement groups. These are noncarrier measurements and carrier-based measurements. Regardless of group type, measurements are held in memory for performance reasons. Up to two time periods for each key can reside in memory simultaneously. These are the current time period and the one preceding the current time period. Because memory is somewhat volatile, the counters must be written to disk to prevent loss of data. At the end of each real-time time period, the contents of memory are written to disk. This disk file is then available to be read at the next startup.
Noncarrier Measurement Production
Noncarrier measurements consist of 45 measurements or accumulators for each of the three intervals kept in memory. This results in 135 measurements for the current time period, plus a possible additional 135 measurements for the preceding time period.
Carrier-Based Measurement Production
Carrier measurements consist of eight measurements or accumulators for each of the three intervals kept in memory. This results in 24 measurements for the current time period, plus a possible additional 24 measurements for the preceding time period.
Memory Allocation
Depending on the operating mode, the system either preallocates counters for all of the configured measurement groups or it allocates counters as activity is detected in each measurement group.
Threshold Crossing Alarms
TCA Table
The Threshold Crossing Alarms (TCA) table contains values and conditions for each measurement that you wish to link to an alarm. These values and conditions are organized by trunk group or Trunk Group/IC (measurement group). Enter the measurement groups that are of concern. You need not populate every value and condition for a specified measurement group. A global measurement group can be specified to be used for all measurement groups that are not specifically entered.
Threshold String Values
Table 11-3 lists the condition value strings and the threshold value strings that you use to identify the condition and threshold values you set in an MML provisioning session with the TCA-TBL tag ID. For more information, see the "Updating the Threshold Crossing Alarms Table" section on page 5-23.
Threshold Crossing Conditions
Each threshold crossing condition is a code that checks the difference (if any) between the user-specified value and the current real-time measurement value. The condition is specified as a number between 0 and 4. Any other value is invalid. Table 11-4 defines the meaning of each condition value.
Condition Value Relationship
Table 11-4 lists condition values used for measurements.
Table 11-4 Condition Values
0
Ignore
1
Less Than (<)
2
Equal To (=)
3
Greater Than (>)
4
Not Equal To (!=)
Threshold Values
With the TCA-TBL tag ID, you specify the threshold value and the condition value to so that they generate an alarm if a specific measurement condition is reached. For example, for a given measurement, if the condition is set to 4 and the threshold value is set to 10, an alarm is generated if the measurement value is greater than 10. Threshold values are specified as positive integers.
Trunk Group Identification (Threshold Key)
Each threshold specification (threshold value and condition value) must be associated with a measurement group. If the Entered By tag specifies TAG/TRK, the measurement is organized by the trunk group number. If the Entered By tag specifies TAG/TRK/IC, the measurement is organized by trunk group number and an interexchange-carrier number. A special measurement group can be specified to apply to all TAG/TRK measurement groups that are not otherwise specified. This measurement group is identified by the name "global/0," where the TAG is "global" and the trunk group is "0."
Processing Logic
The same logic is used for processing all accumulation periods: computation is based on the time stamps from call detail records generated by the switch. The distinguishing factor among the different accumulation periods is the time period in which two events are considered to occur for the same counter. Counts for any given event are added to the accumulators for the time period that matches the time stamp of the event. More specifically, Table 11-2 identifies the time point for each event that is used to match the accumulator time period.
Three different levels at which statistics can be generated are as follows:
•
•
•
There are advantages and disadvantages to each of the above approaches. Statistics computed from CDR details result in more frequent updates, and thus a finer granularity of reporting. However, more records must also be processed. Thus, the volume of connections and the length of the switch-reporting interval can dramatically drive up the amount of processing required to make the statistics available. Conversely, computing statistics from aggregated or correlated CDRs provides a more efficient computation, but less timely statistics.
The following section applies to all accumulation types, periods, and levels.
Statistics Subsystem Functions
The Statistics subsystem provides the following functionality:
•
•
•
•
•
•
•
At any moment in time, two collection intervals are open for updating, the current interval, called "N," and the most recent interval, called "N-1." The two open intervals are necessary because the Cisco MGC does not produce a CDR at the first IAM or seizure; rather, it creates the first indication of a call at answer or abandonment. Because of the particular time points that are recorded by the Cisco MGC, there are some cases where an event is not reported until after the collection interval has been closed, yet the event should be credited to that interval. A bucket or interval shall never be credited for more than the total duration that is available during that interval, regardless of when the indication of the call was received.
A flat file is maintained for each collection interval. In order to provide timely information, buckets for an interval (the current interval, or N) are written as soon as an interval boundary is reached. At the same time, the previous interval (N-1), which may have been updated because of late reports for call abandonment, is rewritten to disk and is not updated again. Very late reports are written to the oldest collection period that is still open, which is always the N-1 interval. The one exception to this rule is at startup, when only the current period is open, until after the first interval boundary is crossed.
Keys and Counters
Keys and counters are stored in memory and written to a checkpoint file on a regular basis.
The key is a unique sequence number used to identify the specific collection of counters. The key fields are the trunk group number and the IC. Table 11-5 lists the key field names and their descriptions.
Counter Sets
Each counter set is made up of three groups of counters, one group for real time, one for hourly, and one for daily. The counters in each group represent running tallies of the specified statistics. Each group of counters represents only the current interval of the counter type (current real time interval, the current hour, the current day). Each counter statistic is credited to the time period in which it occurred. Note that there are different time periods. Hourly counters keep track of the statistics on hourly boundaries. If an event spans multiple hours, one counter for each hour spanned is created. For example, if a call is established at 11:50 and is disconnected at 12:15, one counter for the 11:00 hour is created with 10 minutes of conversation time credited to it, and a second one is created for the 12:00 hour with 15 minutes of conversation time.
Similarly, daily counters credit statistics on daily boundaries.
Frequency of Statistics
In addition to the rollup hourly and 24-hour statistics, which are tabulated with any of the previous options, the system also supports 5-, 10-, 15-, 20-, and 30-minute (real-time), hourly, and daily statistics.
Note
Statistics Output
After statistics have been collected, they are output to a flat file. For each real-time interval, an acc_rYYYYMMDDHHMM00 file is created. For each hourly interval, an acc_hYYYYMMDDHH0000 file is created. For each daily interval, an acc_dYYYYMMDD000000 file is created. These files are stored in the opt/CiscoBAMS/data/s0x/Measurements directory.
Note
The output files are generated as soon as the ACC task has finished processing the aug_acbc file (last file) for the given interval. This means that the ACC task generates a flat file for the real-time interval at the end of each set of files for the real-time interval (5, 10, 15, 20, or 30 minutes). The hourly output file is generated when the last interval file is processed for that hour. The daily output file is generated as soon as the last interval file for the day is processed. Each file is created on a real-time, 1-hour, and 24-hour basis. Each file contains all of the statistics gathered in the previous period.
In the following section, the term "trunk groups" is used to represent both TAG/Trunk Group and TAG/Trunk Group/IC.
Statistics are generated from CDBs produced by the Cisco MGC. Since the output is reported by TAG/Trunk Group or by TAG/Trunk Group/IC, measurements are produced only for trunk groups that have call activity starts (unless the system is running in configured mode and trunk groups are specified). Therefore, when the system is started, the statistics output files are empty until call activity begins. Regardless of call activity, the appropriate acc_x files are generated. These files can, however, be empty.
Note
Over the course of the day, the system continues to add to the trunk groups that are reported on, as call activity is received. Once added, a trunk group is reported on in every interval that follows, until the end of the day. At midnight, the system generates the acc_d (daily) file. This file contains all of the activity for the day for any trunk group that had call activity during the 24-hour period. Once the daily counts have been reported, the system attempts to clear out as many trunk groups from memory as possible. This step eliminates the need to report on trunk groups that are no longer active. The system purges any trunk group that does not currently have a threshold alarm asserted. These trunks groups must be retained so that the system does not assert additional alarms before the current alarm clears. If the system is running in configured mode, trunks specified in the Trunk Group table are not purged either.
Acc_x files produced after midnight contain only trunk groups that have had call activity after midnight and trunk groups that have threshold crossing alarms asserted. If the system is running in configured mode, trunks specified in the Trunk Group table are also reported.
Since the data is stored in flat files, you can configure MSC to purge outdated statistics.
Example from a MGC acc_h file:
0,972477302,3600,203,"occurrences","BAM:EGR CALL ATT","TG8004"Statistics Output Format
The format for the statistics output mirrors the SS7-type statistics format created on the Cisco MGC. The format is comma-delimited, and appears in the order shown in Table 11-6.
Threshold Crossing Alarms
Each measurement instance can be monitored with a threshold crossing alarm. Threshold values that are permitted are Ignore, Less Than, Equal To, and Greater Than. The system identifies threshold value sets by the TAG and the trunk group number. Each threshold value set consists of a value and a check or test for each measurement category. Threshold value sets can be partially populated to check only one or any number of categories for a trunk group. Any unpopulated category is treated as an Ignore condition.
If no threshold value set has been specified for a given TAG/trunk group, the measurements are checked against a global threshold value set. Like trunk group-specific threshold value sets, the global threshold value set can be partially populated. There is no requirement to specify a global threshold value set. If none is specified, and no specific threshold value set has been entered, then no threshold checks are performed. If a threshold value set has been specified for a given TAG/trunk group, no global test is performed on any categories in that TAG/trunk group.
As measurements are tested against the threshold value set, each time a measurement crosses the threshold value, a minor alarm is generated (ACC227). The text of the alarm contains the strings defined in "Troubleshooting Cisco BAMS," the measured value, the test condition, and the threshold value.
When the threshold is crossed in the opposite direction, a clear alarm is generated containing the same text as the ACC227 alarm. For example, if the test is greater than 5 and the measurement is 8, the minor alarm is generated. If on the next check, the measurement is 10, no new minor alarm is generated. If the measurement drops to 3, the clear alarm is generated. When the system is started, the memory of all alarms is cleared. For example, suppose the measurement is 8 and the system is stopped. When the system first tests the measurement (after restarting), if the value is 8, a minor alarm is generated.
The following special conditions apply to threshold crossing alarms:
•
•
•
•
•
•
•
•
Note
Zero Counts
The ACC task can operate in several different configurations with respect to zero counts. One configuration parameter outputs or suppresses all measurements that are equal to zero. The other configuration parameter selects all dynamic measurement group output or configured measurement group output regardless of activity.
Zero Count Suppression
Within each trunk group or trunk group/IC (measurement group), some measurements might not accumulate. For instance, if a trunk group is configured as an outgoing trunk, the ingress measurements are never pegged and the ingress durations are never anything other than zero. The ACC task provides a command-line switch to suppress these values. By default, if a measurement group has one measurement that is greater than zero, all measurements for the group are included in the output file. A command-line switch can override this feature and only non-zero values within each measurement group are output. If rounding or truncation causes an output measurement value to be zero, the ACC task treats the measurement as a zero and suppresses it if that feature is active.
Configured vs. Dynamic Trunk Group Output
Dynamic measurement groups are output only if they contain at least one non-zero measurement since midnight or have an alarm asserted. This is known as dynamic output. In BAMS, an MML option enables you to output all configured measurement groups only, regardless of measurement values (configured mode), to output dynamic measurement groups only (dynamic mode), or to output both configured and dynamic measurement groups. (For more information, see the dynamicaccumes field in the "Updating the Node Parameters Table" section on page 5-10.) This is a dynamic parameter that is reread at the start of each measurement interval. The trunk groups are also dynamic and are reloaded at the start of each measurement interval. If BAMS is not set for configured mode (dynamic mode, or both) any activity detected on a nonconfigured trunk causes the trunk group to be added dynamically (as if in dynamic mode) and measurements are output.
If a trunk group is removed from the configuration, it no longer generates output if it has no counts accumulated for the day. The trunk group continues to be output if any counts for the day have accumulated. Likewise, if a trunk group is not configured and counts accumulate for that unconfigured trunk group (dynamic addition), the measurements for that trunk group are output for the remainder of the day.
The only distinction between a configured trunk with counts removed and a dynamic trunk with counts is that at the end of the day, the dynamic trunk has its pending alarms cleared if there are any. If a dynamically added trunk has an alarm pending at the end of the day, it continues to be reported into the next day and the alarm clears only when the threshold is crossed in the reverse direction.
Changing the overall mode to dynamic from configured causes any trunk groups with no counts accumulated for the day and no alarms to be removed from the output list. All other trunks are changed to dynamic. At midnight, all trunks are then treated as dynamic in the manner described above.
If the system is changed from dynamic to configured, all of the configured trunks are marked as configured, and any other trunks being reported prior to the mode change remain dynamic. All carrier-based measurements are dynamic. These cannot be preconfigured.
Rounding of Measurements
All measurements that are output as a percentage are rounded up or down to the nearest percent. This causes any percentage measurement that is less than 0.5 to round down to zero. The displayed value is zero, internally, but the ACC task maintains the decimal portion of the percentage. Under this condition, the ACC task considers the group to have at least one non-zero measurement. If the system is configured to suppress zero counts (with the NODEPARMS tag ID), the measurement is not displayed.
Truncation of Measurements
All measurements that are output as a duration are truncated to seconds. The ACC task performs all calculations to the millisecond. The truncation is applied only to the output measurement value. Any real-time duration that contains milliseconds is added to the hourly and daily totals with the milliseconds intact.
Last Interval Update
Introduction
Due to the manner in which the VSC produces data, BAMS must sometimes update the measurement data that was output in the previous interval. The VSC does not generate an event when a line is seized. The first event produced is an answer or an abort. Because of this, it is possible for a seizure to take place in one interval, and the answer or abort to take place in the next interval. When this happens, the ACC task determines what pegs or setup durations should be credited to an interval that has already been processed. Then the ACC task applies the measurements to the previously closed interval.
Preliminary vs. Final Measurements
The measurements for each interval are written twice. The first time the measurement file is written, the values are as accurate as possible, given the data provided by the VSC to that point. A measurement file that receives data at this time is located in a Measurements.tmp directory. This write takes place as quickly as the system can process the data following the detection of data that belongs to the next interval. Because some events might not have been signaled by the VSC (seizure), the counts might not be 100 percent accurate.
When the system detects data from the following interval, the system again processes the measurements. At this time, if events are present for calls that began in an interval prior to the current one, the prior interval measurement data is updated. This is the last time that the ACC task writes to the previous interval. Since during any interval, the ACC task will make the final write to the previous interval before making the preliminary write to the current interval, the data in any output file is final when a measurement file exists for a later interval. Final measurements files are located in the Measurements directory.
Interval-Update Rules
BAMS follows these rules when performing last-interval updates:
•
•
•
•
•
•
•
Nonprovisioned Trunk Group Measurements
Measurements data is written for calls in which the trunk group is not provisioned in the Trunk Group table on BAMS. However, the following special rules apply to nonprovisioned trunk group measurements:
•
•
•
MGCP Dial and MGCP Scripting Handoff Measurements
In MGCP Dial and MGCP Script Handoff calls, the Egress trunk group (4015), Egress SigPath (4070), and Egress BearChan (4072) fields are not populated. Thus special treatment is required for these calls. A MGCP Dial or MGCP Scripting call is defined as a call where Egress Protocol (CDE Tag 4073 from 1010 or 1030 CDE) equals 9 or 10.
When processing MGCP Dial and MGCP Script calls, BAMS does not peg the following Egress measurements:
•
•
•
•
•
•
•
•
•
•
Feedback