GSM Actix Analisis
-
Upload
yanharyo-budiharto -
Category
Documents
-
view
407 -
download
47
Transcript of GSM Actix Analisis
GSM Query Training
MCIIran
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 SignalStrength
Poor Voice Quality
No serving cellDominance
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 & ExercisesContinued…
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 ConfigurationCellrefs file set to the CELLREFS_SVS_QUERY.TXT fileGPS Interpolation set to disabledTime 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 dataLoad Speed Default set to Load allGSM 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 SoftwareStatistics Data – Information about handover interval and durationDedicated 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 SoftwareContinue…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 vendor’s 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 SoftwareContinue…
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 SoftwareContinued…
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 ServingCellDistance–distance, in meters, to the
current serving sector ServingCellLat–latitude of serving cellsite at each
point of the drive route ServingCellLon–longtitude of serving cellsite at
each point of the drive route ServingCellID/SectorID–Alphanumeric 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
ServingCellDistance
GSM_Um_Msg_Type
ServRxL
evSub
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 )
FilterA 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 moreuseful information
Example: Help Index Filters(Here you find all explanation and examples regarding Filter)
Filter Wizard
Making use of HELP to obtain moreuseful 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 FilterRight Click on StreamName
Click on Filter
Select the Filter you wish to turn on
Turn off a FilterRight 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 ManagerClick on Existing Analyses tabScroll down to Filter folderSelect the filter you want to deleteClick on Delete button to delete the filterClick 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 moreuseful 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 moreuseful 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 moreuseful 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!
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.
Use the 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.
Order of evaluation
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
Use Filters to Eliminate Messages that are Not Relevant
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.
Order of evaluation
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 moreuseful 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
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.
When to use state() function?
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.
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.
Impact of 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
solution—that is, the one that requires the fewest evaluations.
Reducing 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 evaluations
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.
Reduce the number of rows
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 scalability
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.
Consider event detection
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 way—for 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”
Beware the Count Distinct and Mode aggregation methods
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”).
Strings are slow
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.
Think laterally
Questions?