wadaro system overview v1.13

© 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.

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. of 24

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


Contents

1 Document scope .............................................................................................. 4 2 Abbreviations .................................................................................................. 4 3 Introduction to TAP .......................................................................................... 5 4 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

5 Server aspects .............................................................................................. 17 5.1 General .................................................................................................. 17 5.2 TAP Server ............................................................................................. 17 5.3 TAD Server ............................................................................................. 18

6 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

7 Reporting ..................................................................................................... 20 8 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

© 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


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 Customer Experience Monitoring

EN Event Notification

GERAN GSM EDGE Radio Access Network

ICCID Integrated Circuit Card ID (SIM Serial Number)

IMEI International Mobile Equipment Identity

IMSI International Mobile Subscriber Identity

LAC Location Area Code

MCC Mobile Country Code

MNC Mobile Network Code

MO Mobile Originated

MT Mobile Terminated

NMS Network Management System

NMR Network Measurement Results

QoS Quality of Service

RAT Radio Access Technology

SAT SIM Application Toolkit

SIM Subscriber Identity Module

TAC Type Allocation Code

TAD Type Approval Database

TOD Time of Day (absolute year, month, day, time zone, hour and

minutes)

TPI Terminal Profile Information

UTRAN UMTS Terrestrial Radio Access Network



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.

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

Figure 1 High level view of TAP Essential

TAP Client inside subscriber terminals processes raw performance data into KPI

KPI are uploaded to the TAP Server



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.



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;

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

4.1.3 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 Description

Boot logger Used to track the presence of devices on the network and qualify them

by make and model

Coverage Reports where there is and where there is no coverage

Call start MO Reports on the performance of call set-up

Call drop Reports only on call terminations to include cause codes



TAP Mosaic

variant Description

Call counter 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.



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.

handsetTimestamp The date and time (TOD) maintained by the terminal when the

message was originated.

messageSequence A message sequencing number.

configurationHash 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.

iccidHash A disambiguating identity

eventList A list of all the Notifications packed into the message

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.

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 (22-1) so the Notification has a 1 in 4 chance

of being packed into the message buffer.

0 .. 3

0 .. 1

0

Probability factor = 2

0 22 - 1

0

0

21 - 1

20 - 1





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

Database

types Client Summary

BOOT BOOT Essential

& Mosaic

Identifies the terminal, when it was switched on,

when it first gained access to a serving network

and where

TSN IMEI Essential

& Mosaic

Terminal Serial Number – correctly identify the

make and model of terminal

DNN LOST Essential

& Mosaic

Dropped Network Notification – Records two

endpoints between which the terminal received

no service. This information provides a view of

‘holes’ in network coverage

CHN HANDOFF Essential 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

DVC TVC Essential 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.

CSC CSC Mosaic 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



Notification

Database

types Client Summary

MCN MCN Mosaic 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

CPN CPN Essential Call Performance Notifications report call

performance and coverage counters.

Measurements are made on all calls and the

event is sent at regular scheduled intervals.

ACNS LOST Essential 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.

TTFS BOOT Essential 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:

KPI

Event

source Formula

CDR

Call Drop Ratio

DVC

CSC

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)



KPI

Event

source Formula

HOSR

In call hand off

success ratio

CHN

DVC

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.



Dimension

Dimension

Source Usage

Time All All events contain information about the time when

events took place.

Handset All Handset make/model information from the TAP

database can be combined with the IMEI data from the

handset to provide make and model dimensions.

Location BOOT

CHN

DVC

DNN

CSC

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.

MSISDN All 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

Fleet All MSISDNs can be assigned to a fleet in the TAP

database. This allows MSISDNs to be grouped.

Cell derived:

Technology,

Region,

Custom

BOOT

CHN

DVC

DNN

CSC

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).

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

Related

Event Type Description

Enable client On/Off Enable or disable all client operation

Roaming comms. On/Off Control SMS sending when roaming

Roaming boot record On/Off Record boots when roaming

Roaming record On/Off Record events when roaming

Boot BOOT Probability Sampling of boot records

Drop net DNN Probability Sampling of network loss events

that do not include any ACNS

events

Drop net (with ACNS) DNN Probability Sampling of network loss events

that include ACNS events

Cell handoff (normal) CHN Probability Cell changes when not in a call and

where the LAC has not changed

Cell handoff (in call) CHN Probability Cell changes when in a call

Cell handoff (LAC change) CHN Probability Cell changes when the LAC changes



Configuration

Item

Related

Event Type Description

End call (normal) DVC Probability Sampling of calls without errors

Drop call (error) DVC Probability Sampling of calls with errors

CPN interval CPN Interval Time period to wait before sending

CPNs

Start call (normal) CSC Probability Sampling of call setup without

errors

Start call (error) CSC Probability Sampling of call setup with errors

End call (normal) CSC Probability Sampling of calls without errors

Drop call (error) CSC Probability Sampling of calls with errors

MCN interval MCN Interval 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.



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.



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.

Reference Model

BOOT 0.2

Handoff incall 7

Handoff lac 45

Handoff normal 180

IMEI 0.2

LOST 11

TVC (ok) 10

TVC (fail) 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

Light Events/day

Detailed Events/day

BOOT 0.2

4 0.050

1 0.200

Handoff incall 7

64 0.109

1 7.000

Handoff lac 45

64 0.703

1 45.000

Handoff normal 180

64 2.813

8 22.500

IMEI 0.2

1 0.200

1 0.200

LOST 11

4 2.750

1 11.000

TVC (ok) 10

64 0.156

1 10.000

TVC (fail) 1

4 0.250

1 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

Detailed mode

Per user: SMS/day 1.172 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,



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:

Light Detailed

SMS/day SMS/day

100 117 1615

500 586 8075

10000 11719 161500

100000 117188 1615000

500000 585938 8075000

1000000 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



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 zero-

cost 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



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;



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 Required Example data

Cell Global ID (CGI) M 234:15:60147:38612

Access Technology M 2G, 3G, UMA, etc

Geographical location M Longitude & Latitude , Easting, Northing or Map Ref

Site name O Textual name of the site (e.g. Manchester Airport

North)

Cell site symbolic

name

O MANAIR01 (includes the sector identification)

RNC symbolic name O MAN01

Site address O Manchester Airport North, M90 2BN

Antenna type O Jaybeam TS65XV10V10MR24J

Antenna height O 6.5m

Free format comment O

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



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.



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



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



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 system overview v1.13

Documents

system overview wadaro

tap mosaic

accuracy of information

trademark information

intellectual property

document scope

implementation of tap

license license