GSM Query Training

MCI 1/8 3/8

Course Structure (2.5 days)

Introduction to the Analysis Manager Query types overview Query building Commonly-used functions Analysing information held in different Layer 3 messages Formatting results Exporting queries to create report templates Tips and Tricks for faster and more efficient query building

What do we troubleshoot?
Event Detection & Drive Test Analysis
Dropped Call Call Setup Failure Coverage Problem Handover Problem Interference
Poor Signal Strength Poor Voice Quality No serving cell Dominance Missing neighbor Cross Feeder

Query Examples & Exercises

Coverage Holes
(bad RxLev coverage-idle, bad server coverage)

Interference Analysis
(Cell BCCHs in areas with good coverage but poor quality)

Server Dominance Analysis

(Areas where the server is weaker than the strongest neighbour; too many strong signals)

Coverage Island Analysis

(Display the distribution of the Timing Advance for quick coverage island analysis)

File and MS Analysis

(Generate statistics for each call in the logfile)

Query Examples & Exercises

Continued

Dropped Call Statistics & Analysis

(Analyse each dropped call to report possible diagnosis)

Merge Handset Data Analysis

(Generate statistics at each call setup from both drive test files)

Call Sequence Messaging

(Analyse the Layer 3 messaging for call setup procedures)

Create Reports Template

(Single & Multiple Files Report Template)

Before We Begin (page 9) Change the Configuration

Cellrefs file set to the CELLREFS_SVS_QUERY.TXT file GPS Interpolation set to disabled Time offsets from GMT should both be set to 0 (for switch and mobile) Binning set to message = 1. Scanner Load Mode set to Load all scanner data Load Speed Default set to Load all GSM Bands Used set to 900, 1800 and 1900. GPS Transformation set to Default (degrees) In the Tools > Display Thresholds window, ensure the values are set to the defaults.

GSM Data group in Actix Software

Statistics Data Information about handover interval and duration Dedicated Radio Link Once a call has been established, parameters that are associated with the cell serving the call are contained here. Device Info Information about the specifications of the mobile making the call. Serving Cell Parameters Information about the serving cell identity, serving BCCH, and BSIC. Downlink Measurements Serving RxLev and RxQual measurements made by the mobile, which are also broken out by ARFCN.

GSM Data group in Actix Software

Continue
Neighbor Cell Info BCCH, BSIC, and RxLev for each neighbor. In addition, all neighbor measurements are broken out by channel number. Target Cell Info Information about the target cell for a handoff including BCCH and BSIC. Event Data Call events triggered by Layer 3 messaging or registered by the drive test vendors equipment. If an event is not present in the tree, it did not occur in the file. GPRS Measurements Metrics associated with GPRS data calls, including throughput, coding scheme, channel usage, TBF information and events can be found here.

GSM Data group in Actix Software

Continue

AMR Measurements Call setup and inband signaling measurements extracted from AMR-enabled handsets are contained in this group. Vendor Specific Measurements that are specific to the particular collection device used. Specific events registered by the T+M vendors hardware not derived from layer 3 messaging by Analyzer are included here.

GSM Scanner Data group in Actix Software

Actix Software supports these GSM scanners:
TEMS scanner NEMO Seegull Comarco baseline XK series scanner devices etc

You can drill down to each group to find out more about the scanner data

Independent Node Data group in Actix Software

(Technology & vendor independent measurements)
Device Info contains settings for the mobile device on which data is logged. GPS Data contains mobile longitude, latitude, distance travelled, and speed. Message Info The date and time for the start of the data stream can be found in this group. This information is useful when building report templates. File Info contains label and timestamp information for the logfile under investigation.

Independent Node Data group in Actix Software

Continued

Site Data Node

If a valid cellref and a logfile are loaded, Actix software will automatically calculate these measurements take from both drive test and the cell site information ServingCellDistancedistance, in meters, to the current serving sector ServingCellLatlatitude of serving cellsite at each point of the drive route ServingCellLonlongtitude of serving cellsite at each point of the drive route ServingCellID/SectorIDAlphanumeric identity from the cellref file of the serving site name and sector name NeighborCellDistance/Lat/Long/CellID/SectorID Same info as above for each neighbor position along the drive

Parameter & Format Groups

Parameters (for frequent use) page 10 & 11 Useful Format Groups (for frequent use) page 46

How to find/search attributes?

Tool Find attributes or Press Ctrl-Shift-F

GSM_Um_Msg_Type

Queries
Queries are simple or complex expressions used to extract meaningful performance data, based on user-defined thresholds or the value of other expressions. The result of the query helps you to highlight possible radio problems, generate KPI statistics or investigate problems.

Analysis Manager
Central point for managing queries Allows new query to be written, edited can deleted Allows existing queries to be imported (retrieved) and exported (saved)
Tool Analysis Manager, or press Ctrl-A to go to Analysis Manager

6 types of Queries
Filter Binned (Time-Series ) Crosstab (Multi-Dimensional Statistics ) Histogram Statistic Event (Event-Triggered Window Statistics )

Filter
A filter analysis tests data on a single criterion and displays the data only if the criterion is met

Example 1: To quickly identify areas with bad RxLev coverage (idle and dedicated mode)
ServRxLevEither < -95 dBm

Example 2: Interference:
ServRxLevSub > -90 AND ServRxQualSub > 3

Making use of HELP to obtain more useful information

Example: Help Index Filters (Here you find all explanation and examples regarding Filter)

Filter Wizard

Making use of HELP to obtain more useful information

Example: Help Index state function, overview (Here you find all explanation and examples with logfiles + cellrefs regarding array indexer) You can also find the state() function explanation in page 41

Turn on a Filter
Right Click on StreamName Click on Filter Select the Filter you wish to turn on

Turn off a Filter

Right Click on StreamName Click on Filter Select the filter marked with you wish to turn off

Delete a Filter
Press Ctrl-A to go to Analysis Manager Click on Existing Analyses tab Scroll down to Filter folder Select the filter you want to delete Click on Delete button to delete the filter Click on OK button to confirm and exit

Binned Query
The Binned Query allows you to define a new parameter based on existing parameters, using functions and inequalities.

Expression Builder

Format Group
Format groups control how information is displayed to the user in Analyzer. To find out which format to use, when to use, make use of the HELP Index format groups, queries

Making use of HELP to obtain more useful information

Example: Help Index building expressions (This explains how you build and edit an expression using the Expression builder)

Making use of HELP to obtain more useful information

Example: Help Index array indexer queries (Here you find all explanation and examples with logfiles + cellrefs regarding array indexer)
Binned Queries, creating

Histogram
Histogram query processes data for a single dimension into a bar chart, which is good for producing a high-level view of the data. This data is available for any time-series data displayed in a workbook.

Example: Application Measurement (Throughput) RxLevSub Call Setup Time Analysis (to look at the Statistics)

Statistic
Statistic query allows you to generate data based on the statistics available for a single dimension. It is useful for generating a high-level view for system metrics purposes. These return the Mean, Mode, Median, Maximum, Minimum, Count, Standard Deviation and Variance of the parameter or expression used.

Crosstab Query (Multidimensional Statistical Queries)

provides high-level overviews, typically of the state of the network. processes the sequential message data and extract and calculate summary information (called statistics), which is broken down by one or more dimensions (such as region and serving cell).

Crosstab Query (continued)

Dimension
An attribute that is used to define how the data is grouped in a crosstab query.

Statistic
The results that you would like to include for each dimension, where the parameter you choose will be displayed as the columns in the Statistic Explorer

(i.e.: mean ServRxLevSub, Count/Total # of dropped calls)

Filter
The filter button on the Statistics Explorer may be used to quickly filter query results in the Statistics Explorer and in any other data view

Crosstab Query (continued)

Crosstab Query Wizard

Making use of HELP to obtain more useful information

Example: Help SEARCH building expressions (This explains how you build and edit an expression using the Expression builder) Help SEARCH Event Query Functions Demo

REMEMBER!!!
Always view and display the result of your query after building a few dimensions and statistics DO NOT WAIT UNTIL YOU HAVE CREATED THE WHOLE CROSSTAB QUERY!!! It will be very difficult to back track!

Use the order of evaluation

When Crosstab and event queries are processed, Analyzer evaluates each message in turn in the following order: Filter If the message does not pass the filter, evaluation stops and Analyzer immediately moves on to the next message. Dimensions Each dimension is evaluated in turn in the order in which they appear in the Analysis Manager dialog box. When the evaluation of one dimension fails, the evaluation stops and Analyzer moves on to the next message (example of Attach failure report). Statistics The statistics are evaluated for every row and are also evaluated in the order in which they appear in the Analysis Manager dialog box. For each statistic, the filter is evaluated first and then the statistic expression.

Order of evaluation
The following diagram shows the order of evaluation for a crosstab query that has: - two dimensions - two statistics

- no filters
Sometimes speed up a query by reordering the dimensions.

Use Filters to Eliminate Messages that are Not Relevant

Often dimension expressions are too general to be of use for screening out messages
(for example Cell ID or IMSI are set in most of the messages).

If your query is only concerned with one or two message types: By making a filter that tests for them, you will immediately eliminate all of the other message types This can hugely reduce the number of evaluations because no further evaluations will be performed on the eliminated messages

Order of evaluation
That's where placing a filter at the top level (on the query itself) comes in: Note that in an event query, the combination of trigger expression and window act as a filter.

Statistic

Event Query
Also known as window queries or triggered queries is a special type of crosstab query that are used to create a list of individual occurrences of a problem so that users can drill down into the details of what was going at that time. Generally you use an event query to create a list of failure or warning events, such as dropped calls, handover failures, or throughput measurements that are less than a given threshold. You specify the problem you want to list as the trigger (sometimes called the triggering event). It can be any attribute or expression, although typically it will be an event attribute.

Standard Drive Test Analysis

When you create the event query, you specify the triggering event and whether you want to investigate a period (called the window) before, after, or both before and after the triggering event. Typically you would then define statistics to be calculated on the messages that appear in that window.

Event Query Wizard

Discriminated Event Query

An event query for which a discriminator has been specified. The discriminator is an attribute (i.e. Call ID or Session ID) that is used to identify messages that belong to a particular call or session Running the query at load time triggers the tracking and indexing of the messages for each separate call or session, so that they can subsequently be loaded into Actix Software as a separate stream for detailed analysis Discriminated event queries are usually used with protocol link data, in which the messages from multiple calls and sessions are multiplexed and interleaved, or with Repository Manager.

Discriminated Event Query

(Continued)

Note that adding a discriminator will make the query run more slowly and so discriminators should not be used when not really necessary. For example, users should not normally create discriminated queries for use with drive test data.

Making use of HELP to obtain more useful information

Example: Help SEARCH Event Query Functions Demo

Statistical Aggregation Methods

Expression and Function groups

Help Index filtering, expressions (Here you can find all the available functions to be used in building your query)

state() Function
Returns the value of an attribute at the current message position or, if that has not been set, the previous valid value. The state function is useful when working with attributes that are not set in every message such as those that record an instantaneous measurement of signal strength.

Tips for query optimisation

When to use state() function?

Should use the state function on the dimensions rather than the statistics because you are more likely to create dimensions using values (such as the serving cell) that are set only when the value changes and partly because using the state function in statistics can sometimes distort the results. The main places where it is valid to use the state function in a statistic is when retrieving, for example, the last value, of an attribute in an event query or when retrieving the value of a threshold for use in a comparison operation. Using the state function is slower than not using it, so do not use it when it's not necessary.

When NOT to use state() function?

When you are accumulating values that you know from the spec are set at the same message point. For example, when you create a crosstab query entirely from values set in measurement report messages. Avoid using the state function with an averaging operation.

Impact of the Number of Evaluations

The first thing to understand is what is an evaluation: each sub-expression within a complex expression is a separate evaluation so simplifying a complex expression will reduce the number of evaluations. For example, consider this complex expression for determining the serving cell:
default(state(ServingSectorID),Sector with SC + default(Uu_ActiveSet_SC[0],Undefined))

This can be broken down into the following sub-expressions:

Obviously the overall complex expression will take longer to evaluate than any one of these sub-expression on its own.

Reducing the Number of Evaluations

That is what happens when you run a crosstab query:
the tool passes each message to the query the message then passes through the query until it's either excluded or the evaluation of all of the statistics is complete Therefore, the fewer the evaluations, the faster the query If you want your query to run fast, you should try to find the simplest solutionthat is, the one that requires the fewest evaluations.

Reduce the number of evaluations

For expressions of comparable complexity, each evaluation takes about the same length of time. Often you will find that there is more than one way of arriving at a result.

You can therefore speed up queries by reducing the number of evaluations that take place or reducing the number of sub-expressions in a complex expression One of the main ways of doing this is to make the order of evaluation work for you (see next point).

Reduce the number of rows

Each message is matched against each unique value in each dimension, so the more unique values there are in a dimension, the slower the query will be.
An example of reducing the number of unique values in a dimension is for example using a function like mround:

substitute (ServRxLevFull) with mround(ServRxLevFull, 5)

to round the values to the nearest multiple of five.

Consider scalability
A query that works well on your test data may not work in the field!
For example, you might be tempted to create a query that lists every call and this might work well on your test files. However, when run against five hours of data collected from a protocol link serving a busy urban area, the query might produce millions of rows and the tool will grind to a halt.

You also need to think of the size of the output dataset

For example an excessive number of dimensions creates a huge dataset so consider splitting a big query into several more simple queries.

Consider event detection

Instead of creating a list of calls and iterating across them looking for the interesting ones, it's generally better to create event queries based on the events you are interested in Example of failures during attach: use the failure events as trigger points If necessary, write an event diagram to detect the event to be used as the trigger in the event query. Event diagrams (especially simple ones) are generally much faster than queries.

Consider event detection

For example, rather than create a dimension or statistic with a complicated expression that tracks the gap between GPRS packets:
If((Time prev_time_where(IsValid(Task_Packets_Cum_IncRetr_DL))) > 1000, (Time prev_time_where(IsValid(Task_Packets_Cum_IncRetr_DL))), Null)

With this filter: IsValid(Task_Packets_Cum_IncRetr_DL)

it would usually be preferable to create an event diagram that tracks the gap between packets and sets an event if the gap is greater than a specified threshold. Then you could create an event query using that event as the trigger.

Beware the Count Distinct and Mode aggregation methods

The Count Distinct and Mode aggregation methods require a count to be maintained of every value that is found in the data
That can have a serious negative impact on performance when used in queries that are run against large volumes of data, particularly when the range of potential values being evaluated is large and can grow indefinitely (for example, when the values are IMSIs) When necessary, consider whether you can get the equivalent information in a different wayfor example, by using a separate histogram query rather than a crosstab query If this is not possible, because, for example, you need to break down the results by a dimension (such as the cell), make sure that you minimize the number of dimensions (see active subscribers

Strings are slow

strings are much slower to evaluate than numerical values avoid basing dimensions on string values, because the lookup for strings is slow. If you need to dimension on a string value, see if there is a numeric value that you could use instead. The query will be faster if you dimension on a numeric value and make the string value a statistic (you can use format groups) to render numeric data as strings in the output.

For example, you can use the Service_Protocol_Type format group to render progressive numbers into protocol names (see Subscribers per Application). This will make the query faster than using the function, which actually converts the time to a string.
Sometimes it is impossible to avoid string, though (see APN usage).

Think laterally
When you create queries it's easy to think of the table you want in Excel and then create dimensions for the rows and statistics for the columns. However, this might not always be the most efficient way to create the query Sometimes it might be better to construct it in a different way. For example, suppose you want to create a table that has a column for every message type and rows that show the count. Rather than creating a statistic for each message type, it would be more efficient to simply use the message type as the dimension.

Questions?