Total Analysis Package TAP Essentialtm & TAP Mosaic A System Overview

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Disclaimer Every effort has been made in the preparation of this document to ensure the accuracy of information presented. However, the information contained herein is provided on an as-is basis with no warranties whatsoever, either expressed or implied. Wadaro Limited are not, and will not be held, liable for damages caused or alleged to be caused either directly or indirectly by the contents of this document. Wadaro Limited has endeavoured to provide trademark information about all the companies and products mentioned in this document by the appropriate use of stylised text. However, Wadaro Limited cannot guarantee accuracy of this information. License License is hereby granted to use this document for personal use only. No license is granted to any other intellectual property. No part of this document may be transmitted, reproduced, stored in a retrieval system in any form or by any means, without prior written permission of Wadaro Limited.

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 2 of 24

Contents 1 2 3 4 Document scope .............................................................................................. 4 Abbreviations .................................................................................................. 4 Introduction to TAP .......................................................................................... 5 Client aspects.................................................................................................. 6 4.1 General .................................................................................................... 6 4.1.1 The impact on a subscriber by implementing TAP in their terminal ........... 6 4.1.2 The impact on the network to implement TAP ....................................... 7 4.1.3 TAP Essential .................................................................................... 7 4.1.4 TAP Mosaic ....................................................................................... 7 4.2 Implementation of TAP Clients .................................................................... 8 4.3 Typical Client operation and features ........................................................... 8 4.3.1 Message compression ........................................................................ 8 4.3.2 Message header ................................................................................ 9 4.4 Probability driven upload of Event Notifications ............................................. 9 4.5 Events Notifications & KPIs ....................................................................... 10 4.5.1 Event Notifications ........................................................................... 10 4.5.2 Key performance indicators .............................................................. 11 4.6 Configuration Options .............................................................................. 13 4.7 Sampling ................................................................................................ 14 4.8 SMS Traffic ............................................................................................. 16 Server aspects .............................................................................................. 17 5.1 General .................................................................................................. 17 5.2 TAP Server ............................................................................................. 17 5.3 TAD Server ............................................................................................. 18 Integration with the network to be monitored ................................................... 18 6.1 SMSCs ................................................................................................... 18 6.2 3GPP TS 03.38 compliant OTA platforms .................................................... 18 6.3 Cell site database .................................................................................... 19 Reporting ..................................................................................................... 20 Privacy ......................................................................................................... 24 8.1 Irreversible subscriber anonymity .............................................................. 24 8.2 Anonymity but with support for fleets of subscribers .................................... 24 8.3 Permission based tracking of subscriber experience ..................................... 24

7 8

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 3 of 24

1 Document scope
The purpose of this document is to provide an overview of the Wadaro TAP Customer Experience Monitoring solution. Sample aspects addressed by this document include; What is TAP? Client aspects o TAP Essentialtm o TAP Mosaic Server aspects o The TAP Server o The TAD Server Interconnect with mobile networks o SMS o USSD o Secure Over-the-Air platforms Operational use of TAP o Reporting o Secure control of the TAP Client Privacy

2 Abbreviations
CEM EN GERAN ICCID IMEI IMSI LAC MCC MNC MO MT NMS NMR QoS RAT SAT SIM TAC TAD TOD TPI UTRAN Customer Experience Monitoring Event Notification GSM EDGE Radio Access Network Integrated Circuit Card ID (SIM Serial Number) International Mobile Equipment Identity International Mobile Subscriber Identity Location Area Code Mobile Country Code Mobile Network Code Mobile Originated Mobile Terminated Network Management System Network Measurement Results Quality of Service Radio Access Technology SIM Application Toolkit Subscriber Identity Module Type Allocation Code Type Approval Database Time of Day (absolute year, month, day, time zone, hour and minutes) Terminal Profile Information UMTS Terrestrial Radio Access Network

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 4 of 24

3 Introduction to TAP
TAP is a Network Experience Monitoring (NEM) solution that provides network operators with a first order view of their service performance just as it is perceived by the end subscriber. This view is achieved by applying a crowd sourcing technique to gather Key Performance Indicators (KPI) directly from each and every subscriber terminal. By gathering information from all subscriber terminals, reporting is characterised by the following; Natural service consumption by average subscribers Standard terminals found in retail or otherwise Continuous monitoring Total geographic coverage to include roamed & in-building usage Total network coverage Support for dynamic handover between Access Technologies (e.g. 2G, 3G, UMA, femtocell, etc)

TAP comprises 2 aspects; Client and Server. The TAP Client application is available in 2 basic types, TAP Essential and TAP Mosaic. Both are implemented in Software within the SIM card. The TAP Essential Client is intended for installation in the SIM card when it is manufactured by the SIM vendor. TAP Mosaic is comprised of a number of small Clients that can be installed in SIM cards at time of manufacture but are primarily designed for Over-the-Air (OTA) installation. The TAP Server is common across both TAP Essential and TAP Mosaic and can either be hosted off network by Wadaro, hosted off network by a local hosting partner or integrated within the mobile network as required.

TAP Client inside subscriber terminals processes raw performance data into KPI

Information from TAP is applied in various business processes within the mobile network operator e.g. Network operations Planning Customer Care Terminal Procurement Finance Marketing

KPI are uploaded to the TAP Server

Figure 1

High level view of TAP Essential

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 5 of 24

4 Client aspects
4.1 General

TAP Clients make use of standard features of the SIM Application Toolkit (SAT) interface to gather unprocessed data from the host terminal. This data identifies the terminal, the serving network and indicates the performance of both. The data is processed within the SIM card by the TAP Client into derived performance information and, subject to rules determined by the home operator, uploads this information to the TAP Server. The TAP Client is event driven. An example of an Event is a voice call. An A party subscriber dials the number of a B party, a voice call is established for a period of time and then the call terminates. If the TAP Client is configured to capture call Events then an Event Notification is raised which fully describes the performance of the call. Each Event notification is qualified by the following information; When the Event occurred (date and time) Where the subscriber was when the Event occurred (Cell Global ID) What make and model of terminal was in use when the Event occurred What was the MSISDN of the subscriber when the Event occurred

Depending on the type of Event recorded, further information is also provided. For example, if the Event was a voice call then the TAP Client would also report the following; The duration of the call Was the call Mobile Originated or Mobile Terminated Call termination cause (normal, NetLoss, NetFail)

Please note that each of the Event Notifications is fully described in section 4.5 below. The TAP Client Software is implemented as a Javacard Applet to run in Javacard compliant SIM cards. TAP has been successfully installed in SIM cards from several vendors to include those from Safran Morpho, Gemalto, Oberthur, Giesecke & Devrient, Logos, Sitronics & DZ card. The TAP Client implementation strictly adheres to pertinent standards and coding guidelines for Javacard Applets and the use of SIM Application Toolkit (SAT). No proprietary extensions or code is used. Currently, Wadaro offers TAP Clients that conform to 3GPP release 5 and release 6 specifications. Cards conforming to future releases of specification will also be supported as they come to market. 4.1.1 The impact on a subscriber by implementing TAP in their terminal

Subscribers are totally unaware of the presence of TAP in their terminals. Nothing is presented on the terminal screen There is no degradation of terminal performance There is no excessive use of the air interface (SMS bearer service) There is no perceptible advance in battery drain

By ensuring that TAP Clients transmit data in SMS to a zero-cost rated MSISDN or short code, the subscriber is not charged for the SMS originated by the TAP Client. Generally, USSD is a bearer service that is not charged for by any operator and can also be used as an alternative to SMS.
Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 6 of 24

4.1.2

The impact on the network to implement TAP

TAP has been designed to generate as little physical data as possible whilst, at the same time, offering as much information as possible. The objective met is one whereby networks are not flooded with redundant monitoring data traffic and overall data traffic volumes can be precisely controlled. Control of data volumes is achieved by having all TAP Clients adhere to configuration data that determines what Events are monitored and how much detail is provided for each Event. Some example controls include; Enabling or disabling of the Client Only transmitting a BOOT notification (see section 4.5) when the SIM card is installed in a new terminal but otherwise remaining dormant until enabled Selectively recording a subset of all the possible Event Notifications Enabling or disabling support for roaming o No monitoring o Monitoring but only with upload of data when subscriptions return to the home network o Monitoring with upload whilst on a visited network

As raw signal data is processed within the SIM card into Key Performance Indicators (KPI), TAP can be considered as a massively distributed solution. Unlike a traditional solution such as Core Network probing, the central infrastructure (the TAP Server) is not computationally intensive and does not require high data bandwidth capability. As a result of this, network operators do not need to deploy significant IT resource to implement TAP; 4.1.3 No interconnect required with Network Elements Only commonplace office IT type support is required to maintain TAP As SIM cards operate independently of the TAP Server, TAP itself is intrinsically fault tolerant TAP Essential

Essential Clients are designed for installation in SIM cards during card manufacture and are fully featured Applets with OTA control. Please refer to section 4.5 for a list of Event Notifications supported by TAP Essential. 4.1.4 TAP Mosaic

To enable the Over-the-Air installation of TAP Clients into existing SIM cards, Wadaro offers Mosaic. Each Mosaic Client offers a subset of all the possible Event Notifications listed in section 4.5. By deploying a random selection of Mosaic Applets, comparable reporting is available for network monitoring and terminal performance profiling. Please note: TAP Mosaic Applets can also be installed at time of manufacture by the SIM vendor particularly if there is little free storage in the card. Some example Mosaic Applet variants include the following; TAP Mosaic variant Boot logger Coverage Call start MO Call drop

Description Used to track the presence of devices on the network and qualify them by make and model Reports where there is and where there is no coverage Reports on the performance of call set-up Reports only on call terminations to include cause codes Page 7 of 24

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

TAP Mosaic variant Call counter

Description Maintains a summary record of call performance for periodic upload

4.2

Implementation of TAP Clients

Installing TAP Applets is a simple task. Wadaro provides the network operator and/or SIM vendor with an installation package that includes sufficient documentation and diagnostic code to help a competent resource (e.g. A SIM vendor Technical Consultant) to quickly install the TAP Applet. Typical milestone activities required to accept a TAP Client into a production SIM card (e.g. addition to a card profile) include; Enabling SIM cards o Installation of the TAP Applet into pre-production sample cards o Enable 2G SIM service 28 (SST28:Call control) and o Enable 3G USIM service 30 (UST30: Call control by USIM) in the card A live trial of TAP. This usually involves network operator staff and/or customers participating in the trial by swapping their existing SIM card for a new TAP enabled card. Existing subscriptions are transferred to TAP enabled SIM cards for the duration of the trial Specifying what TAP configuration information is to be installed into SIM cards by the SIM vendor.

Some aspects of a Client implementation that must be considered prior to installation include; The TAP Applet needs to the only Applet that uses Call Control The TAP Essential Client is circa 18k in size. TAP Mosaic Clients start at a size of 4k The documentation that is included in an installation pack contains details of the file permissions required by the TAP Applets

4.3

Typical Client operation and features

This section provides a high level view of some technical aspects of the operation of TAP Clients. 4.3.1 Message compression

TAP makes efficient use of RAN when communicating information between the Client and the Server. Both Client and Server compress as much information as is possible into each communication (SMS for the Client and/or Server, USSD for the Client). Each time the Client determines that a Notification is to be sent to the Server, the Notification is first packed into a message buffer. Subsequently, further Notifications are added until the message buffer is full and the message is then transmitted to the Server. Each message occupies a single 160 character SMS and is encoded in base64, filename safe variant [RFC3548] to ensure that it will pass through all networks without being modified or barred. For USSD, each message length is variable depending on TAP system configuration and the same encoding used in SMS messages is applied.

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 8 of 24

4.3.2

Message header

Each message uploaded to the Server contains information that identifies the sending Client, the host terminal for that Client and other information (see below) necessary for the system to include the Client in service monitoring. fingerprint Prevents the processing of unsolicited SMS. TAP is not wholly reliant on this fingerprint to avoid unwanted messages as further protection is provided by the use of Class 2 SMS and, if required by the target operator, 3GPP TS 03.48 encoding. The date and time (TOD) maintained by the terminal when the message was originated. A message sequencing number. Hash value for the configuration data currently maintained by the Client. If this hash value does not match one of the same recorded by the Server then TAP will send a currently required configuration to the Client. A disambiguating identity A list of all the Notifications packed into the message

handsetTimestamp messageSequence configurationHash

iccidHash eventList

4.4

Probability driven upload of Event Notifications

Each notification type has an associated probability factor stored in the configuration of the Client. Each probability factor determines whether a Notification is to be packed into a communications buffer that is eventually uploaded to the TAP Server when the buffer becomes full. By setting each probability factor for each Notification type, Network Operators can control the volume of monitoring data traffic transferred over the Radio Access Network (RAN) to the TAP Server. However, TAP is required to produce diverse subscriber base reporting of good as well as poor service. This reporting comes from a wide variety of handsets, geographically distributed, with a representative set of usage patterns. So it is desirable to have the maximum number of terminals reporting in a network. Therefore, each terminal only reports a proportion of the observed service events to the server (unless the Network Operator sets a Notification probability factor such that every Notification is uploaded). That proportion is set by the probability factor which controls the true/false return ratio of a randomising function.
0 0 .. 3 0 0 .. 1 0 0 20 - 1 Probability factor = 0 21 - 1 Probability factor = 1 22 - 1 Probability factor = 2

Figure 2

Use of probability to trigger upload of Notifications

The diagram above depicts how the Notification probability determines the range of values that can be generated by a randomising function. If the generated random number is 0 then the notification is packed into a message buffer for transmission to the TAP Server. For example, if the Notification probability is set to 2, the randomising function returns a value in the range 0 to 3 (2 2-1) so the Notification has a 1 in 4 chance of being packed into the message buffer.

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 9 of 24

If the Notification probability is set to 0, the value returned will always be 0 and that Notification will always be packed into the message buffer. Each Notification transmitted to the TAP server includes its associated probability factor. This arrangement allows TAP to vary the probability factor for a Notification per active monitoring Client whilst maintaining the weight of each reported Notification correctly. Using this method above, the operator can control the volume of RAN traffic produced by TAP without losing fidelity in the information presented. Examples of how Notification probabilities are set would include; 1. High values so that normal service Notifications are infrequent 2. Low values so that abnormal service Notifications are frequent 3. Low values generally for high value subscribers 4. High values generally for low value subscribers

4.5

Events Notifications & KPIs

This section describes the event notifications reported from the applet and the modelling of KPIs from that data. Notifications are not KPIs but provide the raw information from which KPIs can be derived. 4.5.1 Event Notifications

The following notification types are sent by the SIM client: Notification BOOT TSN DNN Database types BOOT IMEI LOST Client Essential & Mosaic Essential & Mosaic Essential & Mosaic Essential Summary Identifies the terminal, when it was switched on, when it first gained access to a serving network and where Terminal Serial Number correctly identify the make and model of terminal Dropped Network Notification Records two endpoints between which the terminal received no service. This information provides a view of holes in network coverage Cell Handoff Notification - provides a record of cell handoffs and has 2 uses; 1. A single CHN is separated into 2 individual handoffs and are used as a scaling factor to assessing the significance of the inter-cell DNNs 2. The time in/out of the Cell-ID is used to derive a figure for cell population as a scaling measure for assessing the significance of intra-cell DNNs Dropped Voice Call This Event Notification reports call termination with cause. When a voice call terminates, the network conditions at termination of the call, and any cause information captured by the TAP Client are recorded. Call State Change - This event records state changes in the call sequence. The event is stored in its original form from which the TAP Server may generate a corresponding TVC record. Some Mosaic variants may be able to create TVC events locally Page 10 of 24

CHN

HANDOFF

DVC

TVC

Essential

CSC

CSC

Mosaic

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Notification MCN

Database types MCN

Client Mosaic

CPN

CPN

Essential

ACNS

LOST

Essential

TTFS

BOOT

Essential

Summary Mosaic Counter Notification - Editions of Mosaic that send result as counters use this event. The event is sent at regular scheduled intervals. The event includes partial elements of the TAP Essential CPN Call Performance Notifications report call performance and coverage counters. Measurements are made on all calls and the event is sent at regular scheduled intervals. Attempted Call No Service Records an instance whereby a subscriber attempts to establish a voice call when no network is available. ACNS is sent as part of the DNN notification. Time To First Service Highlights subscribers who power-on their terminal and experience extended delays before receiving service. TTFS is sent as part of the BOOT notification.

Note that notifications are not KPIs. Each notification includes a probability weighting factor (see section 4.4 above). This factor is used to allow the client to reduce network traffic by only sending a sample of events. For example a weighting factor of 1 would mean that every event of that type is being recorded but a weighting factor of 32 means that only 1 in 32 events of that type are recorded. In order to allow for the different weightings you need multiply the count for that event by the weighting. The impact of this sampling on the reported values is discussed in a later section. 4.5.2 Key performance indicators

The following KPIs are examples of what can be calculated from the notifications: Event source DVC CSC

KPI CDR Call Drop Ratio

Formula dropped_call is where the DVC reports a call has completed which connected but the call was terminated for an abnormal reason. connected_call is where the DVC reports a call has been established beyond the network setup phase. CDR = SUM(dropped_call * weighting) / SUM(connected_call * weighting)

CSSR MO Call Setup Success Ratio

DVC CSC

mobile_originated_call is where the DVC reports a call that was started by the handset. mo_call_connected is where the DVC reports an MO call that has connected CSSR = SUM(mo_call_connected * weighting) / SUM(mobile_originated_call * weighting)

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 11 of 24

KPI HOSR In call hand off success ratio

Event source CHN DVC

Formula call_dropped_in_handoff is where the call drop occurred during a transition between cells handoff_in_call is where a cell transition occurs and the HOSR = 1 - (number of calls dropped because of handoff failure / number of handoffs in call)

Coverage Time spent in coverage

CPN

no_service_ratio is the proportion of time for a given CPN spent with no coverage % coverage = 100 * ( (SUM(duration) * no_service_ratio) / SUM(duration))

2G/3G/UMA Coverage Time spent in technology

CHN

In combination with cell site database information the report shows the relative times spent in each technology in_cell_duration = time spent in a cell 2g_in_cell_duration = time spent in a 2g cell % time in 2G_coverage = 100 * SUM(2g_in_cell_duration * weighting) / SUM(in_cell_duration * weighting) Substitute 3G and UMA for equivalent ratios for those technologies.

TTFS Time to first service

TTFS

Time to first service records the time to acquire service following a handset power on event. boot_time = handset powerup event network_acquire_time = first time at which service appears Average TTFS = SUM( (network_acquire_time - boot_time) * weighting) ) / SUM(weighting)

ACNS Attempted calls no service

ACNS

Attempted calls out of coverage records attempts by the user to make calls outside of network coverage. Typically caused by handsets not updating the display signal/coverage even though coverage has been lost. acns_count = number of calls attempted whilst out of service ACNS = SUM(acns_count * weighting)

Note: in the table above the notation for SUM is as per the SQL notation and reflects the sum of the contents of the formula for all selected events. For each KPI it is possible to select and filter the data used according to different dimensions. Most events can be filtered by any dimension; however, CPNs can only be dimensioned by MSISDN and time. If the TAP system has been configured to provide user privacy then the MSISDN dimension may be lost. The following dimensions can be used to control reporting from the TAP database. If a KPI is sourced from events that support that dimension then the KPI can be filtered, sorted or grouped according to that dimension.

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 12 of 24

Dimension Time Handset

Dimension Source All All

Usage All events contain information about the time when events took place. Handset make/model information from the TAP database can be combined with the IMEI data from the handset to provide make and model dimensions. Cell MCC,MNC,LAC and CID is recorded for these events allowing the location to be determined from a cell site database. Accuracy of the location is limited to the range and coverage area of the cell sites. All events contain information about the MSISDN used to send the event. This can be correlated with the IMSI records included in BOOT and TSN/IMEI records MSISDNs can be assigned to a fleet in the TAP database. This allows MSISDNs to be grouped. In addition to location information the cell information in the cell site database combined with events allows dimensions to be created to include: access technology (e.g. 2G/3G); regional information (e.g. postcode); custom information (e.g. vendor of network infrastructure).

Location

BOOT CHN DVC DNN CSC All

MSISDN

Fleet Cell derived: Technology, Region, Custom

All BOOT CHN DVC DNN CSC

4.6

Configuration Options

This section describes the configuration of the SIM applet and how that impacts on the data recorded. The applet is initially configured during the manufacturing or deployment phases and can also be updated using OTA control. Note that the OTA operations differ for Essential and Mosaic. There are three aspects to configuring the TAP Applet. The first part defines the communications pathway that the applet uses: typically an SMS short code. The second defines the MCC/MNC combinations that make up the home networks and allow the applet to recognise when it is roaming. The final aspect describes the features enabled and the sampling rates available. These features are described for TAP Essential and TAP Mosaic below: Configuration Item Enable client Roaming comms. Roaming boot record Roaming record Boot Drop net BOOT DNN Related Event

Type On/Off On/Off On/Off On/Off Probability Probability

Description Enable or disable all client operation Control SMS sending when roaming Record boots when roaming Record events when roaming Sampling of boot records Sampling of network loss events that do not include any ACNS events Sampling of network loss events that include ACNS events Cell changes when not in a call and where the LAC has not changed Cell changes when in a call Cell changes when the LAC changes Page 13 of 24

Drop net (with ACNS) Cell handoff (normal) Cell handoff (in call) Cell handoff (LAC change)

DNN CHN CHN CHN

Probability Probability Probability Probability

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Configuration Item End call (normal) Drop call (error) CPN interval Start call (normal) Start call (error) End call (normal) Drop call (error) MCN interval

Related Event DVC DVC CPN CSC CSC CSC CSC MCN

Type Probability Probability Interval Probability Probability Probability Probability Interval

Description Sampling of calls without errors Sampling of calls with errors Time period to wait before sending CPNs Sampling of call setup without errors Sampling of call setup with errors Sampling of calls without errors Sampling of calls with errors Time period to wait before sending MCNs

Settings with probability values can be set to record events at the following intervals: 1:1, 1:2, 1:4, 1:8, 1:16, 1:32, 1:64, 1:128, 1:256, 1:512, 1:1024 and never. Valid intervals for the CPN notification are: Never, 17 hours, 34 hours, 2.8 days, 5.6 days, 11.4 days, 22.8 days. Other intervals are possible but not typically deployed.

4.7

Sampling

This section describes the nature of the sampling used by TAP and how to interpret data when sampling us used. In the simplest configuration of TAP all the probabilities can be turned to 1:1 and all events recorded. This method generates detailed information for each subscriber and allows the review of an individual's experience of the network. However, to balance the amount of information sent from a set of handsets on the network it is often preferable to limit the number of messages sent by an individual subscriber. There are occasions when operators may wish to enable 1:1 messaging for a subscriber, for example for a high value customer experiencing problems, but for large scale deployments of SIMs with the applet you do not gain significant statistical benefit by recording every event. Statistical sampling of the customer based is improved by not biasing the selection of customers being monitored. For example deploying SIM applets to specific groups of people such as internal teams will create a 'biased sample'. Within the sample group the data will provide accurate data but may not provide a full basis to assume that the wider population receives the same customer experience. For this reason the TAP applet should be configured to use 1:1 (or near to that) for detailed observation work on a small sample of subscribers and lower sampling rates for medium to large subscriber groups. Increasing the sample rate for a large subscriber group will not increase the accuracy of the data in line with increase in samples but will increase the traffic and the demands on the reporting system. For sampling to work the number of events included in a report needs to be broad enough to counter the impact of sampling. To explain this further the following picture shows a projected sample of 10,000 calls being sampled at 1:32.

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 14 of 24

Figure 1 - Sample of 10,000 calls

The blue line reflects the actual number of calls and the red line a prediction based on a random sampling of 1 in 32 calls. As can be seen over time the red line tracks the blue. However, if we zoom into the first 100 hundred calls we can see a different picture:

Figure 2 - Sample of 100 calls

In this picture we see a different aspect of the data which shows that we do not have enough sample points to make precise conclusions. Note that this is exactly the same data set as shown in the previous figure. The significance of this illustration is that the sample size controls the precision of the reporting. Therefore when reporting using sampled data it is important to keep the number of samples high enough to ensure that the data is valid. For example it is not valid to look at the call records of an individual MSISDN on a single day. However, combining the call records of a single MSISDN over a long period would be valid as would be to combine the call records of many MSISDNs over a short period.

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 15 of 24

4.8

SMS Traffic

This section describes the configuration impact and models for the resulting levels of SMS traffic generated by the applet. Each network and the way in which users move through that network varies. This variation makes predicting an exact level of traffic an iterative process. By using an initial model traffic rates can be predicted and then once data starts to arrive the model can be refined and used to adjust the configuration of SIMs. The following table illustrates the starting reference model based on assessments across a variety of networks. It predicts 10+ calls a day, a failure rate of 1 in 10 calls and a fairly active movement around the network. Note that the Handoff information is amongst the most expensive to record as it changes the most.

BOOT Handoff incall Handoff lac Handoff normal IMEI LOST TVC (ok) TVC (fail)

Reference Model 0.2 7 45 180 0.2 11 10 1

Figure 3 - Reference Event Rates

Using this model you then assign probabilities for the levels of messaging that you wish to report:

Reference Model BOOT Handoff incall Handoff lac Handoff normal IMEI LOST TVC (ok) TVC (fail) 0.2 7 45 180 0.2 11 10 1

Light

Events/day 4 0.050 64 0.109 64 0.703 64 1 4 64 4 2.813 0.200 2.750 0.156 0.250

Detailed Events/day 1 0.200 1 7.000 1 45.000 8 1 1 1 1 22.500 0.200 11.000 10.000 1.000

The illustration above defines the weighting factors for a 'light' and a 'detailed' mode. These are only example configurations but if they were deployed then you would see SMS traffic rates predicted in the range of:

Light mode Per user: SMS/day 1.172

Detailed mode SMS/day 16.150

In this instance both modes would transmit at least one message a day. Data in the database would then be current for information from at least 24 hours before. However,
Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 16 of 24

samples of data are arriving all the time and still would flag potential network issues before this time. Using these figures it is possible to scale the numbers to create a predicted message count for larger subscriber numbers as follows:

100 500 10000 100000 500000 1000000

Light Detailed SMS/day SMS/day 117 1615 586 8075 11719 161500 117188 1615000 585938 8075000 1171875 16150000

These message rates demonstrate the importance of careful selection of the probability settings for the applet.

5 Server aspects
5.1 General

TAP Server aspects are implemented in Common-of-the-Shelf (COTS) components such as the following; Platforms from vendors such as IBM, Dell or Hewlett Packard Operating systems such as Linux, Microsoft Server, etc Virtual Machines The Java programming language with commonplace class file support SQL databases from vendors such as Microsoft or MySQL Web Servers such as Apache, Microsoft IIS, etc

TAP is a very scalable solution so systems supporting very few SIM cards through to those supporting many millions of cards can easily be implemented and supported by reasonably competent IT resources. A modest installation supporting a network of less than 1 million SIM cards can be hosted on a single machine such as a blade server. The characteristics of a large deployment to many millions of SIM cards may include; High capacity platforms running several Virtual Machines Connection to Storage Area network (SAN) for retention of data Dedicated backup of the SAN

Any installation will require a connection to an SMSC by implementing the SMPP v3.3 or v3.4 protocol and VPN connection to Wadaro for support purposes.

5.2

TAP Server

The TAP server provides the following capability; Retrieval of SMS from SMSCs Decode of the data transmitted by TAP Clients Insertion of information into SQL database tables Page 17 of 24

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Programmatic exposure of the database to reporting tools to include ones offered by Wadaro or those already available to the network operator Provide stimulus required by 3GPP TS 03.48 compliant OTA platforms to control Client configurations

5.3

TAD Server

Wadaro maintains a central Type Approval Database (TAD) for terminals. This database features in excess of 65,000 terminals by make and model along with benchmark data that qualifies the performance of each terminal as a participant in TAP monitoring. Not all devices function as anticipated or in line with published specifications. Wadaro has invested significant resources into benchmark testing with a view to moderating the information produced by each device. Example issues that are addressed include; Incorrect implementation of SIM Application Toolkit. Either an API is incorrectly implemented or, in extreme cases, access to data via SAT causes the host terminal to crash Variance in performance of a device as a Radio Terminal (signal levels reported by 2 terminals for the same serving network can differ)

Information that qualifies the performance of a device as a participant in TAP monitoring is available from the TAD Server. Each implementation of a TAP Server refers to the TAD Server when a new device is detected on the network. If the TAD Server maintains a record of that new device then information regarding the performance of the terminal is returned to the TAP Server. If no information is available in the TAD Server, Wadaro is alerted to this exception and a like device is sought for benchmarking. As soon as the TAD Server is updated with new device information, device characteristics are transmitted to each TAP Server monitoring that device.

6 Integration with the network to be monitored

6.1 SMSCs

The only mandatory interconnect between TAP and a network is to enable the TAP Server to collect SMS from an account on an SMSC. Generally, TAP is allocated a zerocost rated short code to which SMS are transmitted by the TAP Client. TAP is also allocated an account on the SMSC so that the TAP Server can connect to the SMSC to collect those SMS. For small networks, a single short code and access to a single SMSC should be sufficient to enable TAP. For large installations where TAP SMS traffic is too much for a single device, TAP Clients can be configured to spread traffic across short codes and/or a number of SMSCs. The distribution of SMS traffic across several short codes and/or SMSCs can be configured in the Client when it is installed or later by Over-the-Air control of the Client configuration.

6.2

3GPP TS 03.38 compliant OTA platforms

Control of Client configuration is applied by sending configuration data that is secured by an 03.48 OTA platform. Depending on what the network operator wants to achieve with TAP, the TAP Server can produce a list of MSISDNs to which control data is to be sent. Some examples of why an operator may wish to control TAP Clients are; Switch Clients on or off Change the depth of monitoring for an individual subscriber or groups of subscribers Page 18 of 24

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

o More monitoring of post-pay subscribers o Less monitoring of pre-pay subscribers o More or less monitoring by terminal type o More or less monitoring of subscribers in a specific location Direct TAP SMS to a different short-code Enable or disable roaming support Force an update of data from the Client to the Server Install or delete clients Modify file system data

6.3

Cell site database

TAP provides the ability to geo-locate Events and generally reports the position of those Events on maps. For example;

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 19 of 24

The following table lists example data that can be input to TAP to both locate Events and to enable reporting based on the Access Technology in use at the time an Event occurs. Please note that M in the table refers to Mandatory data and O is optional; Field Cell Global ID (CGI) Access Technology Geographical location Site name Cell site symbolic name RNC symbolic name Site address Antenna type Antenna height Free format comment Required M M M O O O O O O O Example data 234:15:60147:38612 2G, 3G, UMA, etc Longitude & Latitude , Easting, Northing or Map Ref Textual name of the site (e.g. Manchester Airport North) MANAIR01 (includes the sector identification) MAN01 Manchester Airport North, M90 2BN Jaybeam TS65XV10V10MR24J 6.5m

7 Reporting
At the heart of TAP is a SQL database that enables operators to apply their preferred reporting tool to TAP. If no appropriate tool is available then Wadaro can supply one (figures in subsequent sections addressing reported KPI are taken from the Wadaro tool). As mentioned in section 4, TAP enabled SIM cards process raw signal data into KPI within the SIM card. This data is then subject to further processing by the TAP Server with a view to accelerating commonplace queries that are made by reporting tools. The following figures depict some example reports taken as screen shots from the TAP reporting tool applied to real data. The tool itself is highly configurable through the development of template views into the TAP database so further reporting is simple to achieve;

Figure 2

High level view of call performance

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 20 of 24

The above chart provides a simple summary view of the performance of calls for a sample of subscribers over time.

Figure 3

Examples of how coverage is presented

In the figure above, the first chart shows the ratio of time on versus time off the network for the period of time when a terminal was powered-on. This is an example of how service accessibility can be measured. The second chart provides a breakdown on time on 2G versus 3G.

Figure 4

Example comparison of time on 2G versus 3G for 3 makes of terminal

The figure above shows a a comparison of time spent on 2G versus 3G for 3 given makes of temrinal. As shown here, all the temrinals appear to preferentially camp on 2G.

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 21 of 24

Figure 5

Example analysis of service accessibility over time

Figure 6

Presentation of commonplace KPI with breakdown by access technology

Figure 7

Example presentation of call performance time hour of day

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 22 of 24

Figure 8

Sample table of call terminal with cause

The above table shows a count over time of calls by termination cause. NetLoss terminal lost Radio Access NetFail one of the cause codes listed in 3GPP TS 25.008 Unknown represents call termination where there was no explicit reason given by the host terminal for termination. The TAP Applet also could not work out cause from data available

Figure 9

Example presentation of terminal performance Page 23 of 24

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

In this figure, a number of devices are listed with associated call performance. As can be seen, there appears to be more setup failures for Nokia 1200s and Huawei G2201s than most of the remaining terminals. Suggest focus would be on the Huawei device as it made few calls but suffered many setup failures.

8 Privacy
As described above,TAP has the capability to correleate service performance with individual subscribers. The capture of a subscribers geographical location is often the scrutinised aspect of mobile network performacne monitoring. To enable TAP to be deployed in manner that is acceptible to network operators and prevailing telcommunications regulators, Wadaro offers options with respct to how information can be anonymized whilst still providing useful reporting. Three basic forms of TAP implementation that helps address issues of subscriber privacy include;

8.1

Irreversible subscriber anonymity

All data received from a TAP Client is stripped of information that identifies the subscriber before being inserted into the TAP database. It is not possible to reverse engineer data back to a form that identifies the subscriber. The functionality of TAP based on this resulting anonymous data enables the following; Measure network performance Profile terminal performance

However, a 1:1 relationship between service performance and the subscriber is not available so application of TAP in business processes such as Customer Care would not be possible.

8.2

Anonymity but with support for fleets of subscribers

With this configuration of TAP, the identification of a subscriber is stripped from data received from TAP Clients but is labelled with a fleet identification. This enables the network operator to localise performance measurement to groups of anonymous subscribers. A typical application of this configuration of TAP would be to corporate subscriber customers.

8.3

Permission based tracking of subscriber experience

Assuming that TAP is initially configured for total subscriber anonymity or fleet based anonymity, network operators may choose to secure subscriber permission to maintain data about their service experience. In this case, the TAP database would accumulate information identifying the subscriber. This change in subscriber privacy handling can be enabled and disabled at will be the operator. Please note that although retention of data identifying the subscriber is enabled, previously received information from the subscriber will remain anonymous.

Wadaro Limited 2007/2012. Confidential External Disclosure Requires NDA. All intellectual property rights in this work belong to Wadaro Limited. The information contained in this work is confidential and must not be reproduced, disclosed to others without the prior written permission of Wadaro Limited or used except as expressly authorized in writing by Wadaro Limited.

Page 24 of 24