The second step in creating a new Spotlight project template involves defining how you want the data to be stored. You can choose to combine all of the data (this is the default) or to separate it into silos called devices. Essentially, you should separate the data into multiple devices when combining it would be statistically invalid and the structure of the attributes and KPIs and the statistics in the reports do not provide a mechanism for separating the data.
11.2.1 How many devices do I need?
Each additional device adds a performance overhead, and so ideally, you should create the smallest number of devices that are required to separate the data in such a way that the KPIs and reports will provide statistically valid results. When determining how many devices to create, you need to consider how and why the data was logged:
The simplest scenario is when the data was logged by one handset and optionally one scanner in a single drive test unit. In this scenario, it is generally safe to combine the data from both logging devices into a single Spotlight device, because generally, the handset and scanner data is stored in different attributes and the KPIs and statistics are based on one type of attribute or another and therefore provide a means of separating the two types of data. However, you might want to separate the handset and scanner data into separate devices for convenience or clarity.
Another common scenario is when data is logged by two handsets and one scanner in a single drive test unit. Typically, one handset does asuccession of short (approximately 90-second) calls separated by 30 seconds of idle time. The other handset is for "long calls", in which the handset stays in call until the call drops, whereupon the dialer immediately starts a new long call. Typically, the short calls provide data for event KPIs, such as the percentage of call setups that were successful, etc., whereas the long calls provide data for measuring the radio performance. Combining the data would normally give misleading results. For example, the long call data would by definition have an almost 100% dropped call rate and so if used for event KPIs, it would skew the dropped call rate. For
2 this scenario, you should therefore create separate devices for the short
and long call data.
A similar scenario occurs when a single drive test unit has two devices, but one was used for voice calls and the other for data. Like scanner and handset data, generally, data logged from voice and data calls is stored in separate attributes, and KPIs and statistics are typically based on one type or the other. However, for clarity it is generally advisable to separate the data into different logical devices. This avoids any risk of combining data inappropriately and thereby creating invalid KPIs.
All of the drive test scenarios that we have considered so far involve a single drive test unit (that is, one vehicle plus logging equipment). When there are multiple drive test units driving different routes on the same days, there is no reason why you should not combine data logged for the same purpose in the different drive test units. For example, it wouldtypically be valid to combine short call data collected by different drive test units on the same days in different parts of a city or state. However, if the data was logged for different purposes (such as the short and long call data described above), you should generally separate it into different logical devices, for the reasons explained earlier.
Sometimes you may want to base optimization and troubleshooting work on benchmarking data, which is data that has been collected from several different operators' networks simultaneously in order that the KPIs from the various networks can be compared. In this scenario, you would be interested in the data from your own network only. When Spotlight is to be used for this purpose, provided all of the data for that network was logged for the same purpose, you would normally store it in one device. However, you need to create a suitable filter for the device (as described below) in order to exclude all of the data from the other networks.11.2.2 Adding a device
When you create a new project template, by default, Spotlight creates a single all-purpose device that has no filter. If you want to separate data into multiple devices, you must specify a filter for each one. The filter identifies the data streams that are to be loaded into that device. For example, suppose you define two devices, A and B. When you subsequently select data files to load into the project, data streams that match the filter for device A will be loaded into device A, data streams that match the filter for device B will be loaded into device B, and data streams that do not match either filter will not be loaded. Note that data streams that match the filter for device A and B will be loaded into both devices.
2 1 You create a new device by clicking the Add Device button, which opens
this dialog:
2 Device Name - This is used to identify the device wherever it is used, so try to make the name meaningful.
3 Filter - This defines a single sequence of characters that must be present in the stream's long name in order for it to be loaded into this device. The long name is composed of the stream name preceded by the file name like this:
FileName:StreamName.
4 Import From File - You can use this button to browse to a typical log file that will be loaded into the project. When you select the file, Spotlight lists the name of every data stream that it contains. When you select a name in the list, Spotlight inserts the stream name into the Filter box above. Typically, you would then edit it in the Filter box, in order to make the filter more generally applicable.
2
11.2.3 More on device filters
Setting up good device filters takes some thought. Typically, you would use the Import from File button on several of the log files that you want to use in the project, in order to examine the pattern of their stream names. Some stream names include the handset's identifier, such as the mobile identification number (MIN) or phone number, and sometimes you can use this as the filter.
For example, suppose you are setting up a project template that will be used for troubleshooting your network's data from a benchmarking study, in which five handsets were used to log data from five different networks in one drive test unit (vehicle). If the stream names include the phone numbers, you could base the filter on the phone number of the handset that was attached to your network. However, suppose you have several drive test units logging the data and you want to combine your network data from all of the units. Using the phone
numbers will not achieve this, because even if everything else is the same in each drive test unit, the phone numbers will always be different.
Typically, the logging equipment has a number of slots into which the handsets are plugged. Sometimes the slots can be configured with a label (such as the name of the network), and these are generally incorporated into the stream names. If the slots in each drive test unit are given the same labels in all of the drive test units, you could base the filter on the label.
Alternatively, the slots might have an identifying number, which often appears in parentheses in the stream name, such as (0), (1), etc. These are often used successfully as filters. However, for this to work correctly, the handsets for your network would need to be in the same slot in all of the drive tests units.
When filtering on the stream name part of the stream, long names cannot provide the results you require - you might need to consider filtering on the file name part of the long name. If necessary, you could rename the files. For example, consider a benchmarking study, in which the data for each network is written out to different files. You could include the name or ID of the network in the log file names and then base the stream name filter on the network name or ID.
If necessary, you might need to rename the files manually or using a script. This technique can be particularly useful when working with TEMS data.
2