Master thesis

Monitoring of user experience and interactions for mobile video
streaming services
The first step to explore existing infrastructure more effectively

Jiahao Liu

Master’s thesis at Communication Systems
School of ICT
Stockholm, Sweden June 2011

Supervisor: Pietro Lungaro
Examiner: Zary Segall
i

Abstract
Mobile data traffic is expected to continue growing at an almost exponential rate in the next
five to ten years. Contributing to this trend are video streaming services, e.g. YouTube and
Netflix, which are currently consuming significant portions of the available bandwidth and are
likely to remain very popular services.

In order to meet future traffic demands, mobile operators can either continue with the current
approach consisting of proportionally increasing the infrastructure deployment, or adopting
some alternative and opportunistic paradigms for content delivery, capable of exploiting the
temporal and geographical traffic variations while optimizing the amount of resources invested
in content delivery.

While the former approach is likely to have only very limited economic feasibility, due to
substantial increases in OPEX and CAPEX, the latter is instead very promising but require
experimental validation and new software tools for performing more informed resource
allocation decisions. A series of initial experimental investigations have been performed within
the COSEM project to assess the feasibility of context-aware content pre-fetching in mobile
networks. The initial results showed that an unprecedented increase in user experience,
together with terminal energy cost reduction and increased network resource utilization can be
achieved with pre-fetching, provided that future content requests can be predicted with some
certain degrees of reliability.

In order to understand to what extent content can be predicted and how to utilize user context
information for increasing the reliability of the predictions, this project proposes an innovative
monitoring approach, in which a software application, running "on the background" of mobile
devices, is designed for collecting information on both the user context and her interactions
with the mobile device and the various running services."

The results show, with one of the methods chosen, for the YouTube application running in
Android System and without any direct interaction, 90.51% of the transition between states
and 95% of the internal states can be monitored. The 9.49% of the transition between states
that cannot be monitored corresponds to showing the keyboard on the screen, which has
minimal importance; the 5% of the non-monitored internal states corresponds to the change on
the settings of the application, which can be monitor with other methods.

Furthermore, in order to improve the universality of the information obtained, making it easily
shared between companies, all the data are saved in RDF format, which contains a uniform
resource identifier (URI) to make each resource unique in the world.

Keywords: Mobile data traffic, Mobile operator, video traffic on Internet, COSEM, YouTube,
Android, Monitor process, Resource Description Framework

iii

Acknowledgements
First of all, I want to thanks to my supervisor Pietro Lungaro, who has guided me during all the
process. Without him, this project won’t be possible. Secondly, I want to tanks to my examiner,
who has been reviewing this project in very important moments.

After them, I am very graceful with Cristobal Viedma, my friend and college of office for these 6
months. Thanks to his review, important issues of this project have been fixed.

I want to thanks to my friend Luis Martinez also, who has introduced me into the Communication
System and who has helped me to establish the first contact with my supervisor and my examiner.

For the part of RDF, I want to thanks especially to Wu Dan, who has reviewed the structure of RDF
database and who has given me her point of view.

My friends Paolo Pettinato, Urko Serrano and Thinh Lee, whom are also producing very good
project at the same time with me, were very helpful for very important moment.

Finally, I want to thanks to my family, my parents, my sister and specially my wife LiLiang Cheng
for their understanding and support.

Stockholm, June 2011

Jiahao Liu

v

Table of contents
Abstract ii
Acknowledgment v
Table of contents vi
List of figures ix
List of tables xi
Glossary xii

1. Introduction 1
1.1 Background ..................................................................................................................... 1
1.1.1 The future tendency of Internet ............................................................................. 1
1.1.2 Main sources of video traffic on Internet ............................................................... 1
1.1.3 Internet video dissection ........................................................................................ 3
1.2 Problem description .........................................................................................................4
1.2.1 The actual mobile operator’s situation and future prediction ..................................4
1.2.2 Possible solutions ..................................................................................................5
1.3 Aims and goals ................................................................................................................ 6
1.4 Methodology ................................................................................................................... 6
1.5 Limitations ...................................................................................................................... 6
1.6 Project outline ................................................................................................................. 7

2. Problems description 9

3. Market study 11
3.1 Smart phone market ....................................................................................................... 11
3.2 Video sharing services ................................................................................................... 11

4. Software environment 13
4.1 Android System ............................................................................................................. 13
4.1.1 General view ....................................................................................................... 13
4.1.2 Components ........................................................................................................ 14
4.1.2.1 Activity .................................................................................................. 14
4.1.2.2 Service ................................................................................................... 14
4.1.2.3 Intents .................................................................................................... 15
4.1.2.4 Broadcast receiver .................................................................................. 15
4.1.2.5 Content providers ................................................................................... 15
4.1.3 Shared preferences .............................................................................................. 16
4.1.4 Android Manifest file .......................................................................................... 16
4.1.5 LogCats .............................................................................................................. 16
4.1.6 Sending and receiving messages in Android ........................................................ 16
4.2 Analysis of the YouTube application ............................................................................. 17
4.2.1 YouTube application´ use cases ......................................................................... 17
s
4.2.2 YouTube application in detail ............................................................................. 19
4.2.2.1 Overview ............................................................................................... 19
4.2.2.2 Transition between states, general statuses, modes and invocation of
parallel actions........................................................................................ 20
4.2.2.2.1 General rules .............................................................................. 20
4.2.2.2.2 Transition between states............................................................ 20
4.2.2.2.3 Switch general statuses ............................................................... 24
4.2.2.2.4 Choose a mode ........................................................................... 24
vi

4.2.2.2.5 Invocation of parallel actions ...................................................... 24
4.3 Resource Description Framework .................................................................................. 25

5. Software Implementation 27
5.1 Tool utilized for the implementation .............................................................................. 27
5.2 Implementation.............................................................................................................. 27
5.2.1 Interface .............................................................................................................. 27
5.2.2 Application installed in the Android device ......................................................... 28
5.2.3 General overview ................................................................................................ 28
5.2.4 Running the program........................................................................................... 30
5.2.4.1 Starting the monitor process ................................................................... 30
5.2.4.2 On location changed ............................................................................... 30
5.2.4.3 Monitoring the user actions .................................................................... 31
5.2.4.4 Stopping the monitor process ................................................................. 31
5.2.5 The RDF database ............................................................................................... 32

6. Evaluation and analysis 33
6.1 Settings .......................................................................................................................... 33
6.2 Single state evaluation ................................................................................................... 33
6.2.1 Test implementation ............................................................................................ 33
6.2.2 Results and analysis ............................................................................................ 33
6.3 Complex states evaluation ............................................................................................. 34
6.3.1 Introduction ........................................................................................................ 34
6.3.2 Evaluation 1 – Play a video ................................................................................. 35
6.3.3 Evaluation 2 – Play a video extended .................................................................. 35
6.3.4 Evaluation 3 – Record and upload a video ........................................................... 36
6.3.5 Evaluation 4 – Search a video ............................................................................. 36
6.3.6 Evaluation 5 – Upload a video............................................................................. 37
6.3.7 Evaluation 6 – See the information about the user account .................................. 37
6.3.8 Evaluation 7 – See information about a video ...................................................... 38
6.3.9 Evaluation 8 – Rate a video ................................................................................. 38
6.3.10 Evaluation 9 – Read comments about a video .................................................... 39
6.3.11 Evaluation 10 – Set a video as favorite .............................................................. 39
6.3.12 Evaluation 11 – Set a video as “unfavorite” ....................................................... 40
6.3.13 Evaluation 12 – Share a video ........................................................................... 40
6.3.14 Evaluation 13 – Flag a video ............................................................................. 41
6.3.15 Evaluation 14 – Delete a video .......................................................................... 42
6.3.16 Evaluation 15 – Subscribe a channel ................................................................. 42
6.3.17 Evaluation 16 – Unsubscribe a channel ............................................................. 43
6.3.18 Evaluation 17 – Play more than one videos per time .......................................... 43
6.3.19 Evaluation 18 – Change the settings .................................................................. 44
6.3.20 General analysis of all complex evaluations ...................................................... 45
6.3 Conclusion .................................................................................................................... 45

7. Example of usage of the application 47
7.1 Introduction ................................................................................................................... 47
7.2 Scenario 1 - The relation between the data rate and the Quality of Experience ............... 47
7.3 Scenario 2 - Geographical usage and access to a concrete category ................................ 48
7.4 Scenario 3 – Better QoS for a concrete user ................................................................... 49
7.5 Scenario 4 – Probability of usage of YouTube through the day ...................................... 50
7.6 Scenario 5 – Prediction of the favorite videos of the user ............................................... 51
7.7 Conclusion .................................................................................................................... 53
vii

8. Conclusions and discussions 55
8.1 Goals and goals dissection ............................................................................................. 55
8.1.1 Video sharing program’s description and analysis ............................................... 55
8.1.2 User interaction monitoring ................................................................................. 55
8.1.3 Description of possible scenarios ........................................................................ 55
8.2 Contributions ................................................................................................................. 55
8.3 Discussions .................................................................................................................... 56
8.4 Conclusion .................................................................................................................... 56
8.5 Future works.................................................................................................................. 56
8.5.1 New version of YouTube .................................................................................... 56
8.5.2 Other video sharing programs ............................................................................. 56
8.5.3 RDF data analysis ............................................................................................... 57

Bibliography 59

Appendices 63

A Description of the YouTube Application´ information
s 63

B Device information obtained 69
B.1 Device information obtained when the application starts monitoring process................. 69
B.1.1 Software information .......................................................................................... 69
B.1.2 Hardware information......................................................................................... 70
B.1.3 Language and country ........................................................................................ 71
B.1.4 Cell connected information ................................................................................. 71
B.1.5 Data connection .................................................................................................. 71
B.1.6 Mobile network information ............................................................................... 71
B.1.7 SIM – Subscriber Identity Module ...................................................................... 72
B.1.8 Screen information ............................................................................................. 73
B.1.9 General Network information ............................................................................. 74
B.1.10 Wireless network information ........................................................................... 74
B.2 Device state change monitor ......................................................................................... 76
B.2.1 Cell information ................................................................................................. 76
B.3 Additional information related with the device information obtained ............................. 76
B.3.1 Android system API Level Table ........................................................................ 76

C Keywords used to monitor logs 79
C.1. Keywords used to detect the states, general status, modes and parallel actions.............. 79
C.1.1 States.................................................................................................................. 79
C.1.2 General Statuses ................................................................................................. 92
C.1.3 Modes ................................................................................................................ 92
C.1.4 Parallel actions ................................................................................................... 93
C.2 Keywords used to detect internal states ......................................................................... 94

D Specific information obtained through logs 115
E Specification of the device utilized for the evaluation 140

viii

List of figures
1.1.1 Global consumer Internet Traffic. 2010 – 2015 ............................................................... 1
1.1.2.1 Peak period aggregate traffic composition – North America: fixed access ....................... 2
1.1.2.2 North America, fixed access, peak period, top applications in Downstream by Bytes ......3
1.1.3 Consumer Internet video. 2010 – 2015 ............................................................................ 3
1.2.1.1 Pricing models in US, UK, Singapore and Australia ........................................................ 4
1.2.1.2 The root challenge for the traditional telecommunication companies ............................... 5

3.1 Smart phone analysis. Quarterly shipment data. Q4 2010 .............................................. 11

4.1.1 Android software stack.................................................................................................. 13
4.2.1 Use cases of YouTube 1.6.20 (E) on Android System ................................................... 18
4.2.2.2.2 General state diagram for YouTube 1.6.20(E) on Android System ...........................22-23
4.3 Semantic web layer cake ............................................................................................... 25

5.2.1 The interface of YouTube monitor ................................................................................ 27
5.2.2 YouTube monitor application installed in Android System ............................................ 28
5.2.3 YouTube monitor program’s general overview ............................................................. 29
5.2.4.1 Starting the monitor process sequence diagram ............................................................. 30
5.2.4.2 On location changed sequence diagram ......................................................................... 30
5.2.4.3 Monitoring the user actions sequence diagram .............................................................. 31
5.2.4.4 Stopping the monitor process sequence diagram ............................................................ 31

6.2.2 Single state evaluation ................................................................................................... 33
6.3.2 Evaluation 1 – Play a video ........................................................................................... 35
6.3.3 Evaluation 2 – Play a video extended ............................................................................ 35
6.3.4 Evaluation 3 – Record and upload a video ..................................................................... 36
6.3.5 Evaluation 4 – Search a video ....................................................................................... 36
6.3.6 Evaluation 5 – Upload a video ....................................................................................... 37
6.3.7 Evaluation 6 – See the information about a user account ............................................... 38
6.3.8 Evaluation 7 – See information about a video ................................................................ 38
6.3.9 Evaluation 8 – Rate a video ........................................................................................... 39
6.3.10 Evaluation 9 – Read comments about a video ................................................................ 39
6.3.11 Evaluation 10 – Set a video as favorite .......................................................................... 40
6.3.12 Evaluation 11 – Set a favorite video as “unfavorite” ...................................................... 40
6.3.13 Evaluation 12 – Share a video ....................................................................................... 41
6.3.14 Evaluation 13 – Flag a video ......................................................................................... 41
6.3.15 Evaluation 14 – Delete a video ...................................................................................... 42
6.3.16 Evaluation 15 – Subscribe a channel ............................................................................. 43
6.3.17 Evaluation 16 – Unsubscribe a channel ......................................................................... 43
6.3.18 Evaluation 17 – Play more than one video per time ....................................................... 44
6.3.19 Evaluation 18 – Change the settings .............................................................................. 45
6.3.20 General analysis of all complex evaluations .................................................................. 45

7.2 Relation between data rate and QoE .............................................................................. 47
7.3 Video played in Kista since 2011.06.23.12.49 to 2011.06.23.12.50 ............................... 48
7.4 Video traffic of a concrete user from 2011.06.23.10.30 to 2011.06.23.11.30 ................. 50
7.5.1 Number of sessions per hour for a concrete user in one month....................................... 51
7.5.2 Probability of starts a session per hour for a specific user .............................................. 51
7.6.1 States where the video played comes from .................................................................... 52
ix

7.6.2 States where the video played comes from – Percentages .............................................. 52

x

List of tables
1.1.3 Consumer Internet video. 2010 – 2015 ............................................................................ 4

7.3 Video played in Kista since 2011.06.23.12.49 to 2011.06.23.12.50 ............................... 48
7.4 Video traffic of a concrete user from 2011.06.23.10.30 to 2011.06.23.11.30 ................. 50

xi

Glossary
Base station In wireless communication system, a base station is a wireless station installed in a
fixed location to communicate with the mobile devices such as mobile phones.

OPEX It stands for Operational Expenditure and it is the ongoing cost of running a product. In the
context of this project, OPEX is the cost for the mobile operators to maintain the existence
infrastructure.

CAPEX It stands for Capital Expenditure and it is the counterpart of OPEX. It is the expenditures
to create future benefits. In the context of this project, CAPEX is the inversion needed to create
infrastructure necessary to maintain the QoS and the QoE.

QoS The Quality of Service measures the capacity of the vendors to offer a concrete service. In the
context of video streaming service, it could be the level of acceptable defects on a service.

QoE The Quality of Experience used in this project refers mainly to the perception of the users
about the experience received with the mobile devices. In contrast with QoS, it is subject to the user
and different user can experiment different QoE in the same situation.

Exabytes It is a unit to measure the computer storage and it is equal to 1.000.000.000.000.000.000
Bytes.

Petabytes It is a unit to measure the computer storage and it is equal to 1.000.000.000.000.000
Bytes

CARG It stands for Compound annual growth rate and it measures the smoothed annualized gain of
an investment over a given time period.

Internet PVR It is one of the categories that Cisco has grouped the Internet video. It is the recorded
live TV content for late view.

Ambient video It is used to group one of the types of videos in Cisco predictions. It contains all the
persistent video streams such as pet cams, home security cams and nanny cams.

Average Revenue per User (ARPU) It is a term used for companies who offers subscriptions to
the users and it measures the revenue generated by one customer over the time, typically each
month or each year.

OMS It is a variant of Android system created for the Chinese market. It stands for Open Mobile
System and it is supported by the Chinese company China Mobile Ltd.

Tapas It is an OS derived by Android system launched by the ex-president of Google in China. It is
modified to support Chinese social networks, Chinese e-books and other services that are not
related with Google.

Device ID (IMEI for GSM phones and MEID for CDMA phones) IMEI stands for International
Mobile Equipment Identify and MEID stands for Mobile Equipment Identifier. Both of them are
usually unique to identify the mobile devices, but not subscribers. For example, IMEI is used to
reduce the effect of mobile phone theft, by stopping the mobile device with a stolen IMEI to access
to network.
xii

Software fingerprint Generally, a device fingerprint contains compact information about the
hardware and the software. In the case of Android, it collects the software fingerprint which
uniquely identifies the software build.

Android ID It is a 64-bit number randomly generated when the Android devices is booted for the
first time. It should remain constant for the lifetime of the device.

URI Uniform Resource Identifier is a string of characters that enables the unique identification of a
resource on Internet. It could act as URL (Uniform Resource Locator), URN (Uniform Resource
Name) or as both. The URI is frequently used in markup languages such as HTML, XML or XLST
to point to other resources.

URL Uniform Resource Locator is a Uniform Resource Identifier that specifies the location of a
well-known resources and the mechanism to retrieve it. This is possible because the syntax specifies
a schema which could be used to identify the process method of the URL.

xiii

Chapter 1 Introduction
In this chapter, first of all, the future tendency of Internet and the main sources of video traffic on
Internet are presented, along with the actual situation of the mobile operators and the problems
that they are facing and possible solutions. Secondly, the aim and goals of this project will be
introduced. In order to achieve those aim and goals, a specific methodology is described. Finally,
the limitation of this project and its structure could be finding.

1.1 Background
1.1.1 The future tendency of Internet
Since Sir Tim Berners-lee invented the web on 1989, the traffic on internet has been growing.
Recently, the forecast published by Cisco shows the future tendency of traffic on Internet [22]. It
predicts that the global IP traffic will continue growing, reaching 966 Exabytes by the end of 2015.

Figure 1.1.1 Global consumer Internet traffic. 2010 – 2015. Source [22]

As the graph shown, the type of data which increase most is Internet video. The study of Cisco
point out that on 2010, the Global Internet video traffic has surpassed global file sharing. It wills
growth from 40 percent of consumer internet traffic in 2010 to reach approximately 62 percent of
global consumer traffic by 2015. That is, on 2015, the video traffic on internet will reach 33,620
PetaBytes per month, which means that the among of video that will across global IP networks
every second in 2015 would need 5 years to be watched.

Due to this huge growth, the following sections are going to focus on the video traffic on Internet.
First of all the main sources of video traffic on Internet is going to be analyzed.

1.1.2 Main sources of video traffic on Internet
Nowadays, with such big amount of data traffic on Internet, it could be hard to know the rank of
most accessed web pages on Internet with accuracy. Thanks to Alexa, a subsidiary company of
Amazon, this information is easily obtained and daily updated.

According to this global rank, YouTube is the thirst most popular web page globally, only behind
Google and Facebook. [19]

Created on February 2005 and acquired by Google Inc. on November 2006 [14], YouTube is a
worldwide service portal where the user can upload, share and watch videos.

1

Based on the official information on the web of YouTube, it is localized in 23 countries across 24
different languages, which make it receives 2 Billions of views a day and 24 hours of videos to be
uploaded to it every minute [32].

With such amount of traffic and such good position in Alexa rank, it seems YouTube is the most
important source of the video traffic on Internet. But Internet is a place where the things can change
very fast, looking at the best one at the present could not be enough, the potential to grow of its
competitors is also important.

In this sense, the “Global internet Phenomena Report: Spring 2011” provided by Sandvine advice
the reader to the rapid growth of Netflix. [26]

Netflix is an American provider of Video-on-demand Company in United States and Canada. It
provides both physical rental service (United States) and internet-based streaming service (United
States and Canada). By the year 2010, it has 19.7 millions of subscribed and a revenue of 2.16
billion. [24]

Figure 1.1.2.1 – Peak period aggregate traffic composition – North America: fixed access. Source
[26]

This graph of Peak period aggregate traffic composition in North America regarding the fixed
access shows the increase of the Real-time entertainment between 2009 (29.5%) and March 2011
(49.2%), which is almost 60%. Furthermore, Sandvine forecasts the Real-Time entertainment
category will represent 55-60% of peak aggregate traffic by the end of 2011.

2

Figure 1.1.2.2 – North America, fixed access, peak period, top applications in Downstream by
Bytes. Source [15]

The reason behind this heavy growth is the domination of Netflix in the video traffic market, which
represents 29.7% of peak downstream traffic in North America, as the figure 1.1.2.2 shows. This
peak downstream traffic makes possible Netflix becomes the largest source of Internet traffic
overall in North America. [26]

Once the two main sources of the actual video traffic on Internet are presented, the future tendency
of Internet video and its components will be analyzed.

1.1.3 Internet video dissection
In the same study provided by Cisco, the forecast of the Internet video between 2010 and 2015 is
also provided, which is extracted to build the graph and the table below [22]

Figure 1.1.3 – Consumer Internet video. 2010 – 2015. Source [22]

3

Consumer 2010 2011 2012 2013 2014 2015 CARG
Internet Video 2010-2015
Short form 697 931 1254 1665 2208 2978 34%
Long form 2936 4984 6932 9255 11980 15879 40%
Internet video 342 838 1626 2786 4165 5911 77%
on TV
Live internet TV 480 777 1185 1754 2477 3417 48%
Ambient video 93 258 521 860 1207 1523 75%
Internet PVR 40 78 134 237 387 581 71%
Mobile video 85 213 493 1028 1933 3333 108%
Total 4672 8079 12146 17583 24357 33620 48%
Table 1.1.3 – Consumer Internet video. 2010 – 2015. Source [22]

Based on such study, the Internet video traffic will have a compound annual growth rate (CAGR) of
48% since 2010 to 2015, which will growth from 4672 PetaBytes on 2010 to 33620 PetaBytes on
2015 (719%). Among them, the one which has the highest CAGR value is the mobile video, which
wills growth from 85 PetaBytes on 2010 to 3333 PetaBytes on 2015. By the end of 2015, the Cisco
study predicts that the mobile video traffic will surpass Internet PVR, Ambient video, short form
and it will be almost the same as live internet to TV.

With such among of traffic within 5 years, are the mobile operators prepared for it? The next
section will analyze the actual situation of the mobile operators and the problems that they are
facing.

1.2 Problem description
1.2.1 The actual mobile operator’s situation and future prediction

Figure 1.2.1.1 - Pricing models in US, UK, Singapore and Australia. Source [18]

The graph above shows the actual pricing models (March 2011) in US, UK, Singapore and
Australia. [18] It groups the price model of those four country in “Per MB”, which means the final
price depending on the traffic used; “< 5GB”(per month), a flat fee with a limitation less than 5GB
of data traffic per month, and “>5GB” (per month), a flat fee with limitation more than 5GB of data
traffic per month.

It is very clear that in all those countries, the flat fee with a limitation more than 5GB is the price
model which dominates the market. This is especially clear in US, where 84% of the user has a
relatively unrestricted price model.
4

The flat fee was introduced to make the mobile data prices more attractive for the users, who can
easily translate their behavior from the computer to mobile devices. It has advantages and
disadvantages. At the same time that the mobile operators are gaining more users, the flat rate could
become a problem because it decreases the Average Revenue per User (ARPU) and increase the
data traffic. This is, by one hand, the incoming of the mobile operators will be decreased and by
another hand, the mobile operators are forced to make more investment in CAPEX and OPEX if
they want to maintain the actual level of QoE and QoS.

Figure 1.2.1.2 – The root challenge for the traditional telecommunication companies. Source [17]

The graph above shows that, once the data traffic exceeds the voice traffic, the actual situation can
greatly influence the revenue of the mobile operators, making the traffic growth not anymore
correlated with revenue growth.

With such big problems, the mobile operators should find solutions to make the situation more
sustainable.

1.2.2 Possible solutions
The easiest solution could be the end of the flat rates.

In June of 2010, AT&T signaled the end of flat-rate data tariffs for iPhone users in United States.
Instead, a model where owners could be up to 2 gigabytes of data per month on standard contracts
will be used. [2]

Also in United States, Verizon Wireless is going to charge new users by how much data they
consume in July 2011, finalizing the end of all-you-can-eat mobile Internet plans. [3]

However, because the contract that the final users have signed has a concrete duration of services,
until it get expires, this solution won’t be effective. Meanwhile better solution should be proposed.

A good solution could act both preventing the rapid growth of traffic cost and increasing the value
or the revenue of the mobile operators [17].

For the first part of the solution, prevent the rapid growth of traffic cost, the mobile operators could
try to manage the resources more efficiently, share infrastructures and making more efficient
deployment. To reach the aim of increase the revenues, the mobile operators could try to exploit
existing infrastructure more effectively and improve the user experience, for example by extending
the battery life of mobile devices [17].
5

1.3 Aims and goals
Because the long time required and wide knowledge needed to finish all the smaller solutions, this
project is going to focus one of them: exploit existing infrastructure more effectively.

Mainly, this solution requires two types of information at the same time: The utilization level of the
existing infrastructures and how they are going to be explored (User behavior)

From the point of view of the mobile operators, the first type of information is not so hard to know
because the infrastructure is under their control. The hardest part to more efficiently exploit the
existing infrastructure is to know the user behavior, which represents a constant destination of data
that is always moving.

Because the preferences and the needs of each person are not equal, this movement could be viewed
as a constant challenge for the mobile operators to drive correctly the traffic to the right
infrastructure when it is needed.

Fortunately, the human behavior is predictable, by knowing the previous actions of a specific user,
her future behavior could be determined with a certain level of probability.

Driven by this idea, the aim of this project is to build a program to explore the possibility to monitor
the user behavior with a video sharing program through a mobile device already on the market. In
order to fulfill this aim, several goals are set:
 Describe and analyze the behavior of a video sharing program running in a mobile device
already on the market.
 Utilize the tools available to monitor the interaction of the user with the program.
 Describe different scenarios where the data obtained could be useful.

1.4 Methodology
In order to fulfill the aims and the goals described in the previous section, this project has been
developed following a specific methodology.

First of all, because the large number of types of platforms and video sharing programs, a market
study should be done. In this market study, a concrete mobile device platform and a concrete video
sharing program should be chosen.

Once it is done, in order to make the results of monitor available for most of the customers and
make it easy sharable, a lecture review has been carried to choose the best data representation
format. After it, the device platform and the video sharing program are analyzed in detail to explore
all the monitoring possibilities and capture as much action as possible.

All those knowledge are utilized in the next step, where a prototype which runs in the chosen
platform has been implemented. Finally, an extent evaluation has been done running the prototype
in order to test the accuracy.

1.5 Limitations
The time constraint (20 weeks) has determined most part of the limitations of this project.

First of all, as the section 3.1 has demonstrated, there are several platforms in the market.
Developing an application on all them could be possible but it requires time. Thus, only the best of
them will be used. Through the study done by Canalys [20], It seems Google based platforms

6

(Android, OMS, and Tapas) dominate the market. Among them, a specific version of Android (2.1)
has been chosen.

In the section 3.2 of the same chapter, YouTube application has been chosen to be monitored. In
this sense, because different version of YouTube application could behave differently, only the
version 1.6.20 (E) has been analyzed and monitored.

There is also a limitation of the monitor process utilized. There could be several ways to monitor an
application on Android. The one utilized is based on Logs generated by the application, which
cannot monitor all the user actions. Other methods could be utilized in combination with this
methods in order to achieve 100% of user actions monitored, but it will requires more time.

Finally, more extend evaluation could be done. At time of writing this project, hundred mobile
devices compatible with Android has been released. [23, 29] Testing the monitor application on all
them by utilizing tools as TestDroid could prove that the monitor application work for all the
Android devices, but it will take long time and a lot of resources.

1.6 Project outline
In the following sections, the author is going to explain the possible problems that this project could
help to answer in the section 2. After it, the first step of the methodology which is market study will
be presented in the section 3. The software environment, both YouTube application and Android
system will be introduced in section 4. Lately, in section 5, the author is going to explain the
functions of YouTube Monitor program implemented, its interface, the general overview, the design
of the database and the internal actions when the user runs the program.

In the section 6, the author has designed a single test and 18 sets of more complex test in order to
evaluate the monitor capacity of the program. The potential and the scenario where this program
can be used are shown as example in section 7. Finally, in section 8, the author is going to do a
review of the goals and objectives proposed, a discussion about the actual state of the program, as
well as the future works. The conclusion, which summarizes the entire project, is also shown in this
section.

7

Chapter 2 Problems description
This chapter is going to introduce several set of questions describing the problems that the
researchers could have and this project could help to solve.

In section 1.2.2 the author has point out that the efficiently use of the actual infrastructure could be
part of the solution for the mobile operators to gain more revenue. By knowing the resources
available and the user´ behavior, the data traffic could be driven to be present in the right moment
s
and right place, because the context is shifted on time and place. [4, 5, 6, 7, 8, 9, 10, 13]

However there are still questions that should be answered:

The first and the most general set of questions could be related with how to monitor user
interactions with video. Currently there are several platforms which allow users to watch videos via
streaming, and there are several applications that allow user access to videos on Internet which can
behave in very different ways. The problems are, with such number of different platforms and
applications, how to monitor them? Is there a way to do it which is completely transparent to the
users? In such case, are all the interactions of the user monitored?

The second set of questions is about how to map QoS and QoE. Because video streaming on
Internet represents a long duration and time sensitive traffic, at what data rate the user will watch
completely most of the videos? At what data rate the user will watch less than half of the videos?

The thirst set of questions are about the habits of the users. Regarding the place, the question could
be what percentages of user watch the videos while they are traveling and what percentage of they
watch the video while they stay in the same place for long time. And regarding the time, the
question could be what percentage of they watch the videos always at the same time and what
percentage of they watch the videos at different times.

Once we know the habits of the users, the next set are about the level of prediction of the users. Is it
possible to predict the user behavior in the future? Are the predictions reliable? For a given user, Is
there any place or/and any time this user is more likely to request the videos? What is the possibility
to predict the place and the time of request of next video?

If the set of the questions above are answered, the mobile operators could start pre-fetching the
videos in the base stations where the user usually connects, in the user mobile devices or in both of
them. Then, the next set of questions is for an individual user or for a group of users, what are the
gains? Is she/they experimenting better quality of service and quality of experience? Are the quality
of service and the quality of experience good enough for her/them?

9

Chapter 3 Market study
This chapter describes the first step of the methodology utilized, which is market study. It has two
parts: The first one is about the analysis of the smart phone market and the second one is about the
logic behind when a specific application is chosen.

3.1 Smart phone market
Since the introduction of the concept of smart phone with IBM Simon on 1992 [30], the market of
smart phones has been growing with platforms such as Symbian, Palm, Windows, Blackberry,
Apple’s iPhone or Android.

Based on the market study published by Canalys on January of 2011, Google dominates the market
of smart phone shipment on the fourth quarter of 2010 with 32.9% of market share, while the
market share of Nokia and Apple are 30.6% and 16.0% respectively. [21] This study highlights the
shipment of Google phones (Android, OMS and Tapas) in the fourth quarter of 2010 are 33.3
millions, which represents a growth of 615.1% regarding the same period on 2009.

Figure 3.1 – Smart phone analysis. Quarterly shipment data. Q4 2010. Source [21]

For this reason Google based platform has been chosen to implement the video sharing monitor
program and among them, Android system.

3.2 Video sharing services
By the video-sharing services side, the section 1.1.2 has shown that YouTube is the biggest video
traffic source worldwide and Netflix has very good potential to compete with it, both options could
be valid.

When the author started the project, on January 2011, there was not program that enable the
possibility to access the film database of Netflix through Android System. The actual program was
launched on 12th of May, 2011 [25]. This means there were no better options than YouTube. So,
YouTube application for Android system was chosen to be monitored.

11

Chapter 4 Software environment
In this chapter the software environment is presented. First, the description of platform chosen and
most part of the components utilized in the implementation are introduced. Lately, the YouTube
application which should be monitored is analyzed, both with use cases and with detailed state
charts. Finally, RDF, the data representation format which the result will be presented is analyzed.

4.1 Android system
4.1.1 General view
Android is a software stack for mobile service that includes an operation system, middleware and
key applications [28]. The development and the release are supported by the Open Handset Alliance,
which is composed by 81 technology and mobile companies, from semiconductor companies,
handset manufacturers to software companies, mobile operators and commercialization companies.

The follow picture shows the Android architecture:

Figure 4.1.1 – Android software stack. Source [20]

The applications which run in Android use Java as main language and XML (eXtensible Markup
Language) to build the user interface. With proper user permission and by using the application
framework, any application running in Android can take advantage of the device hardware, access
location information, run backgrounds services, set notification status bar, etc.

Other important features of Android is every Android application runs in its own process, which
guarantee the isolation from other applications. This is possible using the Android’s own virtual
machine called Dalvik Virtual Machine, which unlike the Java Virtual Machine, is register-based.

13

This feature makes the Android’s Virtual Machine more efficient [16], enable the possibility to run
several Virtual Machines at the same time in the mobile phone.

4.1.2 Components
The android applications are building basically by components; each one represents an entry point
through which the system can enter the application. Each one of them exists by its own and plays an
essential role.

There are four different types of application component: Activities, which is what the user see in the
screen; Services, which runs in the background; Broadcast receivers, which receive the intents and
Content provide, which provide data for the applications. The application built for this thesis is
based on the first three components.

4.1.2.1 Activity
The activity is one of the most important components in Android. It is prepared to be shown to the
user and normally it is related with a user interface file written in XML. The user can specify the
interface using the XML files and show it with the proper Java code.

In the program made for this project, there is only one activity which the user can decide to start the
monitor process, stop it or finish the actual activity.

4.1.2.2 Service
Unlike activities in Android, services run silently in background.

The priority set in Android regarding the services is the services have lower priority than an active
activity but higher than an inactive activity. Because this, it is perfect bind them to the application's
component and make the application continue runs and responses the user's action in the
background.

There are two types of the services: Bounded service and Started service. The main characteristics
of a bounded service are:
• This service will be created when some component bind it.
• Multiple components can bind the service at once.
• When no component is binding a service, this service will be destroyed automatically.
• It is possible to provide a client-server interface.

The main characteristics of a started service are:
• This service will be created when some component start it explicitly.
• The service will run almost indefinitely, even when the component which has started it has
been destroyed. So, it is useful when not result is required.
• To stop this service, a component could use the stop method or the service itself could stop
itself when it considers the goal for which the service has been created has been reached.

It is important to clarify all the started service could be also bound. This is, the combination of both
type is possible: A service can be started first and then bind it or it can be bind first and later be
started.

In the extremely low memory case, the service could be killed. But the system will try to restart it
again as soon as it has enough memory.

14

There are two services running in the code made for this thesis: DeviceStateServices which monitor
the general state of the device and GeneralService, which is responsible of monitor the YouTube
application user’s actions. Both services are started service.

4.1.2.3 Intents
Before explain the broadcast receiver, the intents should be described because basically broadcast
receiver is a class which receive the intents and process it.

The Intents is an abstraction description of operations which are used in Android to perform a
concrete one. [11] It contains two primary attributes: action and data. The action attributes contains
information about the general operation to be performed. There is several actions existence in
Android such as ACTION_VIEW to obtain information or ACTION_DIAL to display the phone
dialer. The coder can also set her own actions. The data attributes contains data which is used to
operate in the operation, which is expressed in URI format.

In addition to the primary field, several secondary attributes such as category or type can be used.

The most practical part of the Intents is they have a secondary field called “extras”. With the
method putExtra(), any basic data type such as Boolean or String could be added to intent and being
exchanged between processes.

In the monitor application, the author has created intents with a unique action in Android System,
which are utilized to send the RDF data to the broadcast receiver to be lately saved in the database.

4.1.2.4 Broadcast receiver
From the point of view of the order of intent processing, there are two types of the broadcast
receivers in Android: Normal broadcast receivers, which run in an undefined order, and ordered
broadcasts, which the order of processing could be controlled with the android:priority attribute of
the matching intent filter.

The broadcast receiver only contains a method called onReceive() and it is only alive when this
method is called. When this method finished, the system considers the receiver to be finished.

The broadcast received is used in the monitor program made for this thesis in order to receive
intents that contain the RDF data to be saved in the database. This makes the code more flexible
because as long as any java class has the variable “context”, which contains the context of the
program, it can send the intent with the RDF data to save it in the database.

4.1.2.5 Content providers
In Android, the persistent data is saved using three types of resources: Shared preferences, SQLite
database and Content Provider.

Shared preference is explained in the section 4.1.3.

SQLite database is the default relational database that comes with Android. By default, the database
is a sandbox. This means its content is only available for the application which has created it. [11]
This can be changed using the Content provider, which enable the content available to be shared.
Once the default SQLite database is turned to Content provider, any application which has proper
permission can add, modify and remove the contents.

Because there is no need to share the content of the monitor program’s data, the SQLite database
where the information is saved, hasn’t been turned into the Content provider.
15

4.1.3 Shared preferences
Shared preference is the way recommended to save the UI state, user preferences and application
settings in Android System.[11] It utilizes the key/value system to save/retrieve data. This is, every
single data will have a key which is unique in the shared preferences. By using this key, the value
saved previously, even the application has been killed and restarted again, will be restored. In case
the value required is not set yet, a default value will be returned.

In the YouTube monitor application, the shared preference is used mainly to save the unique id of
the mobile device and the previous state reached.

4.1.4 Android Manifest file
The Android Manifest file is an XML file presented in the root directory of any Android program
which contains all the essential information about the application. Those information could be the
java package name which serves as a unique identifier for the application, the description of the
components of the application (Activities, Services, Broadcast receivers, contents providers), the
permission required to run the application, the minimum level of API that the application requires,
(See appendix B.3.1) etc. It is unique in the application and it should be present since the beginning
because it indicates the activity of the application which should be run when the application starts.

4.1.5 LogCats
LogCats is the method used on Android based devices to show messages or logs which is similar to
the sentence System.out.print() of Java. To invoke it, the coders can write the print code in any
place of the existence code. It is important to mention that those messages or logs can be captured
and handled by any program running in Android, because it is the base of the program implemented
for this project.

There are 7 types of logs: Verbose, Debug, Information, Warning, Error, Fatal and Silent.

All they have different order of importance and they are sorted by it. The Verbose is the less
important one, and Silent is the most important one. In fact, Silent is so restrictive that nothing will
be displayed.

The general pattern to invoke the logs is using the function Log and then the first character of the
type of the log. It requires at least two arguments: Tag and Message. Tag is used to classified the
log and message is the information which the coder what to display.

In Android, there are three buffers where the logs are stored: Main, which is the default buffer and
where most of the logs are; Events, where all the events-related logs are stored and radio, where all
the radio/telephony related logs are stored.

4.1.6 Sending and receiving messages in Android
Beside the broadcast receiver, the other way to communicate in Android is using Messages and
Handlers. The main difference between the broadcast receiver method and the sending and
receiving message method is, in the second method, the receiver is known forehand, which is set
when the message is sent.

This receiver has to implement the method called handler. The handler is the process which
repeatedly checks the content of the message queue and filters the message which has itself as
receiver. Because of this loop, when the handler is not implemented in the activity, it should be
implemented in another thread.

16

In the program implemented for this thesis, the messages are used to evaluate the transition between
states. Although the main log buffer used for it is the Events, sometime it is not enough. In order to
monitor also the logs from the Main log buffer, expecting some specific log to appears, a special
class WatchDogPack is implemented. Basically, with this class, the application can add and remove
Watchdogs dynamically, when the application is running. If a Watchdog found a log which match
with the characteristics set, it will send a message to the handler then the application could act
depending on the message.

Once the main characteristics of Android System are presented, the author is going to explain how
the specific version of YouTube application in Android System works.

4.2 Analysis of the YouTube application
In this section, first the author is going to show all the case studies and then, explain all the states,
statuses, modes and parallel actions.

The version of YouTube application analyzed is 1.6.20 (E) which runs from the version 2.1 of
Android O.S. or later.

4.2.1. YouTube application use cases
The follow chart shows the use cases of the YouTube application:

17

Figure 4.2.1 – Use cases of YouTube 1.6.20(E) on Android System

The main functions of YouTube application on Android are manage videos, handler a video while it
is playing, manage a channel, manage the user account, get information and change settings.
18

To manage an application, the user can record and upload a video, or upload a video already exists
in the Android device, search for a video, play a video, share a video, set a video as favorite, set a
video as unfavorite, flag a video as inappropriate, rate a video from 1 start to 5 starts or delete a
video which has been uploaded by the user.

While a video is playing, the user can pause the video, play the video, backward/forward a video,
set the quality of the video (HD on/off), change the scroll of the video or see the captions of a video,
if any.

In the YouTube application, any user is at the same time a channel that other users can subscribe. A
user can also decide to stop subscribing a channel in any moment.

YouTube application works with two modes: logged in and logged out. When the user is logged in,
she can perform all the actions that are possible when the user is logged out, and she has also
opportunities to perform other specific actions.

Another function that the YouTube application has is to obtain information. They could be
information about a video, about the user account, about the channel or about a playlist. Other
information that are possible to obtain are the comment from other users about a specific video, the
list of the favorite videos of the user, the list of subscribed channels, the videos of a specific playlist,
the list of the videos uploaded by the user and the list of the categories set by YouTube.

Finally, the user is allowed to change several settings for the YouTube program.

4.2.2. YouTube application in detail
4.2.2.1 Overview
In total, YouTube application has 44 states, 2 general statuses, 2 modes and 2 parallel actions.

The states are composed by each one of the screens shown in the application and the moment when
the application is looking for a video in the server except the state 6, Start searching, which doesn’t
have any screen representation.

The general statuses are Launched and Finished, which indicates if the YouTube application has
been launched or it has been killed by Android System.

At the same time, YouTube application can works in both logged in mode or logged out mode. The
logged out mode are contained inside the logged in mode in sense that all the states of logged out
mode are also reachable from the logged in mode.

Finally, there are two parallels actions. They are actions that the YouTube application creates when
it has to upload a video to the YouTube server. They are necessary because they are running in
background, which enable the possibility for YouTube application to be running at the foreground,
being responsive for the actions of the users.

The first one corresponds to the action when the YouTube application is uploading a video recently
recorded and the second one corresponds to the action when the YouTube application is uploading a
video existence in the mobile device.

In appendix A there is a short description of each one of the states, general statuses, modes, as well
as the parallel actions.

19

4.2.2.2 Transition between states, general statuses, modes and the invocation of parallel
actions
4.2.2.2.1 General rules
In any Android device, the requirement states that the manufacturers must implement at least four
buttons: Home, menu, back and search [12]. The behavior of them should be the same for all the
applications. Basically the home button makes the device shows the home screen, the menu buttons
make appears the menu and it is context dependent, the back buttons make the application go to the
last state and the search buttons open a keyboard where the user can enter any keyword and look for
any information related to that keyword.

If the user presses the buttons and hold down them 1 or 2 seconds, a new action could be performed:
with the home button, the recently used applications (at most 6) will appear; with the menu button,
a keyboard will appears where the user can enter any keyword and make search within the phone.
Finally, with the search button, the voice search will be launched.

The existence of those buttons enables the possibility to the users to come back to the previous state
in any moment (Except the state 6. Start searching) by pressing the physical back button or go to the
home screen (exiting any application) in any moment by using the physical home button.

All the Android system supports the utilization of the touch screen. [28]. This enable the possibility
to implement the virtual buttons or buttons which will appears on the screen according the user
interface implemented. If the user press on the screen where the buttons are, her action will be
captured and the system will act as if the user has press on a physical button.

With the use of touch screen, the user also has the possibility to hold down the finger pressed on the
screen. This could enable the context menu, which displays a list of possible actions. As the
physical buttons, in YouTube application, the virtual buttons are also used both to make the
transition between the states and to trigger an internal state.

4.2.2.2.2 Transition between states

20

[White page left intentionally]

21

Figure 4.2.2.2.2 – General state diagram for YouTube 1.6.20(E) on Android System. Figure
available on http://www.jiahaoliuliu.com/2011/06/master-thesis-youtube-state-chart.html

In the State chart above, all the possible transition between the states are captured, as well as all the
internal states possible. In order to simplify the chart, some transition between the states is shown
inside the source state.

Also for simplification, the state 1, Main screen, is shown as also final state. This is, when the user
has finished the actions to perform, she can come back to the first state to perform other actions.

The other possibility while the user is performing an action is decided to not continue with such
action planned and come back to the final state. In this sense, the user can both come back to the
first state and press repeatedly on the physical back button, which the user can do in any state or
press on the virtual home button which will appear if the user presses on the physical menu button.

Because the existence of the physical home button, the user can exists the application in any
moment by press on it. In order to make the state chart more understandable, this transition is not
shown in the state diagram.

Another thing to take account is there are two groups of states which are context dependent. The
first group is because they invoke a call to other application, which depending on the applications
installed in the system and the system configuration, could trigger an external application. Because
the existence of the applications for Android is constantly changing, there is no way to know which
application will be triggered when a call is made. This makes impossible to monitor the behavior of
them.

They states of this first group are:
• 2. Start recording video
• 3. Video recording finished
• 17. Upload video
• 43. Share a video
• 44. Flag a video
No internal state can be described for them.

The second group is because they are depending on the system configuration. In this group there is
only one state: 5 Showing keyboard. This state depends on the locale configuration of each machine
(The language and the region set on the phone) and also the preference of the manufacturers,
because they have the right to modify it to adapt Android System to their preferences. Due this
flexibility, this state cannot be monitored easily and it is considered as context dependent.

4.2.2.2.3 Switch General statuses
For the generation between the general statuses, because there are only two statuses, launched and
finished, a cycle is used. The YouTube application only can go to the status Launched when it is in
the status Finished, and vice versa.

4.2.2.2.4 Choose a mode
The transition between the two modes, logged in and Logged out, are also cyclic. The user only can
go to the mode Logged in when she is logged out and vice versa.

4.2.2.2.5 Invocation of parallel actions
Finally, to invoke the parallel actions, specific state of YouTube application should be reached. To
invoke the parallel action “Start uploading video recorded”, the state “4. Fill information about a
24

video recorded” should be reached first. Then if the user fulfill all the compulsory data and press on
the “Upload” button, this action will be invoked, running in background, while the YouTube
application goes to the state 1, Main screen.

The invocation of the parallel action “Start uploading video” is almost the same as the action “Start
uploading video recorded”; the unique difference is it should be invoked in the state “18. Fill
information about a video uploaded”.

4.3 Resource Description Framework
Resource Description Framework (RDF) is a simple data model for writing down relations, which
forms part of the semantic web layer cake.

Figure 4.3 - Semantic web layer cake. Source [27]

Designed for knowledge representation, it is the standard model indicated by W3C consortium for
data interchange on the Web [31].

There are two main characteristics which make RDF a good standard model: its simplicity and its
universality.

The first characteristic is because all the knowledge is discomposed into triples: subject, predicate
and object. The subject is the one which do the action, the predicate is the action itself and the
object is the one which receive the action. For example, a simple knowledge could be “John has
mother Susan”. In this case, “John” is the subject, “hasMother” is the predicate and “Susan” is the
object.

This simplicity doesn’t mean RDF is incomplete. One of the advantages of RDF lies on the
invisible links that put the RDF together. Because the RDF data components could be any word, the
object in a RDF data could be also the subject of another RDF data. Thus, one by one, all the RDF
data could be interconnected if there is any relation between them, creating a more complex
structure.

The second characteristic, the universality, is possible by using URIs as global name, which
guarantees no name collision will be produced between RDF knowledge. Because URI is only a
string of characters, infinite URIs could be created based on any URI. This means, by having the
25

control of a URI such as URL, anyone can create an infinite number of URIs for her purpose
without worry about the existence of the same URI created by others.

For example, in this project, all the RDF data contains the URL of the project COSEM which this
project forms part. This is, by knowing that the URL
http://www.wireless.kth.se/research/projects/69-cosem is unique in the world and it is controlled by
COSEM project, concatenating information after this URL and use them as part of RDF data saved
in the database, the universality of the data will be guaranteed.

As directly consequence of the universality, if the same URI is found in the components of different
RDF data, they are considering the same. This consequence is very important because it allows
different parties create different RDF knowledge about the same object without interference
between them and making sure that their data will be easily merged only by according on the URI
utilized. This is the reason of why RDF is highly scalable.

Because of this, RDF is very useful for this project. When the database is created, the monitor
program will create a URI with the information of the mobile device where the program is running
as the root of the RDF structure. This URI is unique in the world and each time this URI is created
on the same mobile device, they will be the same.

Lately, this database could be extracted to be merged into a bigger database. By having this unique
URI, in this bigger database, the monitoring information obtained from different mobile devices can
be merged easily, creating historical monitor information of each mobile device separately by
grouping them by the root of the RDF structure.

26

Chapter 5 Software implementation
The thirst step of the methodology will be presented in this chapter. It starts describing the tools
utilized for the implementation, followed by the description in detail of the implementation. In this
description, the interface and description of the application installed on Android will be presented
first. Secondly a general overview of the flow of the data will be introduced. After it, the internal
data flow will be described supported by several sequence diagrams. Finally, the RDF database
utilized will be described.

5.1 Tool utilized for the implementation
For the implementation of the program, several tools are utilized.

First of all, eclipse was a utilized as the IDE (Integrated development environment) because it is the
unique IDE that works with the plug-in provided by Google to develop Android applications. The
version utilized is 3.6 (Helios). Secondly, the Android SDK was necessary to code for any program
for Android system.

The debug and evaluation process was possible utilizing a read device (HTC Hero, see specification
sin Appendix E) and LogCat viewer in eclipse that comes with Android SDK.

Finally, the use of ADB (Android Debug Bridge) makes possible direct communication with the
device through the terminal.

5.2 Implementation
5.2.1 Interface

Figure 5.2.1 – The interface of YouTube Monitor

The interface of the program has been designed as simple as possible. It contains three buttons:
“Start monitoring”, “Stop monitoring” and “Exit”.

As the names could suggest, the button “Start monitoring” is used to start the monitoring process,
the button “Stop monitoring” is used to stop the monitoring process and the button “Exit” is used to
exit the application.

There are several concepts for the interface that should be clarified:

The monitoring process is a simple process. It only has two states: Started or stopped. This means if
the user has already started the monitoring process, it cannot start it again. Not two monitoring

27

processes will be running in parallel. By other side, if the monitoring process has been stopped,
there is no way to stopped it again.

Because the monitoring process runs in background, even when the user has exited the application,
it will continue running until the user press the “Stop monitoring” button or the background process
has been killed by Android by other reasons.

5.2.2 Application installed in the Android device

Figure 5.2.2 – YouTube monitor application installed in Android 2.1

The Android device has a default application manager, which could be used to check the
application’s status, or uninstall them. The figures below show the YouTube Monitor application
information in the application manager:

As the figure shown, the application uses 292 KB of the space. Notices this is the space used when
no data has been generated. This means the application has recently installed and it hasn’t started
collecting information yet.

The figure also shows the permissions required by the application. It requires the user location
permission, the phone state and identity permission, the network communication permission and the
system log files permission.

The first three permissions are used by the Device state service to obtain the device information and
monitor the user location. The last permission is used by the General Service to monitor the
YouTube user actions.

5.2.3 General Overview
28

Here is the general schema about how the monitor application works:

Figure 5.2.3 – YouTube monitor program’s general overview

Basically the monitor application has one Activity and two services. The activity is used to start and
stop the services, which is shown as interface in the previous section, while the services are used to
obtain the information in background.

There are two different services: the device state service and the general service.
The device state service obtains most of the information about the device at the beginning of the
YouTube monitor program, when the user starts all the services. There is specific information, Cell
id and Cell latitude, which shows the base station that the mobile device is connected, which is
updated when any change of them occurs.

All the possible information that can be obtained is shown in the appendix B. Among them, the
most important information is:
• The phone number
• The software fingerprint
• The android ID
• The device ID
They are unique data for any device. In the database they are utilized to make an entrance of RDF
data unique in the world.

The second service is called General Service and it is used to monitor the user actions. It utilizes the
logs generated by the events buffer to identify the actual state of the YouTube Applications. That is,
each time a new event log is generated, the Event Log Handler thread created by General Service
will analyze the event log to see if it contains any keyword that matches with a new state, mode,
general status or parallel action. If the answer is affirmative, the Event Log Handler will notify it to
the YouTube Log handler and the Background log handler, then all they will analyze the logs
corresponding to a specific buffer in order to get and save useful data. All the keywords are shown
in the appendix C.

29

The process of saving database utilizes first a broadcast receiver which receive the intent that could
come from any part of the program and which contains the RDF data to be saved. Then the
broadcast receiver will interacts with the RDF Database adapter in order to save those data.

Because the Intents have a unique identification and it can be sending from any part of the code, it
makes the application very flexible. The code doesn’t have to worry about where to send or any
interactions with the database, it just has to create intent with proper identification and attach the
RDF data on it, then finally sends the intent.

5.2.4 Running the program
5.2.4.1 Starting the monitor process

Figure 5.2.4.1 – Starting the monitor process sequence diagram

As shown in the figure of interface, the monitoring starts when the user press on the button “Start
monitoring”. Then, the YouTube Monitor Activity, which is the interface screen, will create two
services: General Service and device state service.

Once the services are created, they will create several objects and interact with them. General
Service will create the RDF database adapter, the Event log handler filer, the RDF Broadcast
receiver, the YouTube log handler and the Background log handler. After the RDF Broadcast
receiver has been created, the device state service will try to obtain all the information regarding the
actual state of the mobile device and save them in the database by sending RDF intent to the RDF
Broadcast receiver. All the information obtained is shown in the appendix B.

Once the RDF Broadcast receiver receives the Intent, it will extract the information that it contains
and save them in the RDF database by interacting with the RDF Database adapter.

5.2.4.2 On location changed

Figure 5.2.4.2 – on location changed sequence diagram

The figure above shows the sequence diagram when the user location has changed. The device state
service will be always aware about the base station where the Android device is connected. When
30

the user’s device has changed the base station, the Device state service will notice it and then it will
try to obtain the information about the new Base station. Once they are done, this information will
be send to the RDF Broadcast receiver as intent, which will be updated in the RDF database
including the information about when it has been changed.

5.2.4.3 Monitoring the user actions

Figure 5.2.4.3 – Monitoring the user actions sequence diagram

The most important function of the program is monitoring the user actions. Once the Event log
handler is created by the General server, it will starts to capture all the logs from the event buffer
and match each one of them with the keywords.

If the Event Log handler detects that the state, the status or the mode of the YouTube application
has been changed, it will first save the new state, states or mode in the database. Then it will invoke
the methods stateChanged() present both in YouTube Log handler and Background Log handler to
notify them the change made. Once they have noticed the change, all them will start to monitor the
relevant data and the possible internal states.

5.2.4.4 Stopping the monitor process

Figure 5.2.4.4 – Stopping the monitor process sequence diagram

As shown in the figure above, if the user wishes to stop the monitor program, she can press on the
“Stop monitoring” button and stop the processes. This button will call first the General Service to
start stopping processes running in background and then call the Device state service to stop such
service.

Once the General Service received the command to stop the service, it will stop all the processes
that it has started: Event Log handler, YouTube log handler, Background log handler, RDF
Broadcast receiver and the RDF database adapter. Finally, it will stop itself.
31

5.2.5 The RDF Database
The design of the database is one of the most important tasks for the software engineer. Because it
means the interaction with a physical support, it is the part of the program which consume more
time. Due to the YouTube monitor program runs in background, it should be transparent to the user.
With this idea on mind, the author has designed a very simple database.

The monitor program uses the default SQLite database which comes with Android. It has just one
table with four columns, which correspond to Id, Subject, Predicate and Object of RDF data
representation. The data type of id is a number, and the rest are String.

It is important to clarify that all the RDF data saved in any database is unique in the world because
it concatenate several information. First of all, the URL of COSEM project which this project forms
part, secondly a unique ID generated by several information unique about the mobile devices,
which are the device ID, the phone number if any, the software fingerprint and the Android ID and
finally, the time stamp when the user action is performed to differentiate the same actions
performed on different time.

In order to have the data well organized, the concept of configuration and session has been
introduced.

When the YouTube Monitor application starts, the device state service creates an extra RDF data
which contains a unique timestamp. The mission of this RDF data is creating a new configuration
and links it with the mobile object. All the configuration of the device will be directly or indirectly
under this RDF data.

The concept of session is utilized by the service which monitors the user actions. The aim of it is to
classify better the data generated by grouping all the monitor data under a session.

A session is considered started when the YouTube application has reached the status Launched.
And it is considered closed when the YouTube application has reached the status Finished, in other
words, when the YouTube application has been killed by Android.

In order to make the RDF database more understandable, an example of it has been generated.
Because it is a huge image, it cannot be shown correctly in this project. Rather, it is hosted in
www.jiahaoliuliu.com (http://www.jiahaoliuliu.com/2011/07/master-thesis-example-of-rdf-
database_9279.html)

32

Chapter 6 Evaluation and analysis
This chapter presents the evaluation and its later analysis. It starts describing the general settings
utilized, followed by the single state evaluation. After it, 18 sets of evaluation will be described
along with their respective results and a general analysis. Finally, this chapter will end with a
conclusion about the results obtained.

6.1 Settings
The follow tests have done in a mobile phone (HTC Hero) which runs Android 2.1 and YouTube
1.6.20(E) for Android. The specification of the mobile phone is presented in appendix E.

All the evaluations generate a huge database which contains all the information. Because of this, the
results won´ be shown in details. Instead, the results will be grouped by: Transition between States,
t
transition between general statuses, transition between modes, invocation of parallel actions,
Internal states and Information obtained. Notice is an evaluation doesn’t generate any group of
results, it will be shown as 0%.

6.2 Single state evaluation
6.2.1 Test implementation
In this single state evaluation, the YouTube application will be consider as a simple program which
independently of the previous states, the log generated by the new state / general status/ modes /
parallel actions only depends on the new state reached.

By knowing all the states, general status, modes and parallel actions, internal states and possible
information that the logs generated could contain, and knowing all the states where this state /
general status / modes / parallel actions can come from, this evaluation try to split all the actions
that a user can perform into small and single transitions between two states, general status, modes
and parallel actions and test them.

In other words, this evaluation has been done examining every one of the states, general status,
modes and parallel actions. For each one of them, the author has made the mobile phone reaches it
from all the possible states, general status, modes and then examine if the monitoring of this
transition is possible for the YouTube monitor program.

6.2.2 Results and analysis

Figure 6.2.2 – Single state evaluation

As the result shows, almost all the user actions can be monitor examining the logs. There are two
groups of states that the monitor application cannot know. The first group is the external states,
which only has as member the state 5, Showing keyboard, which shows a keyboard on the screen.
33

There are two reasons why this state is not monitored. The first one is because the logs generated
are too generic, leading a big confusion. For example, in any moment the user can hold the menu
button to invoke the keyboard, which look for the information for the whole device, not only in
YouTube. In this case, there is no difference between the logs generated by both states, so, from the
point of view of the logs, they are the same.

The second reason is because this state is highly region configuration dependent. Different regions
can have implemented different keyboard to adapt to the type of character to enter. Because the
time constraint of this project, it is much better focus on the more important features than look for
the keyboard of all the regions of the world.

The second groups of states that cannot be monitor belong to all the internal states that the YouTube
application reaches in the Setting screen, which represents 5 percent of the Internal states. This is
because the YouTube application saves the user preferences directly to the internal memory of the
device and not generates any log. Then, it is impossible to detect those internal states watching only
the logs.

6.3 Complex states evaluation
6.3.1 Introduction
Once the single states evaluation is done, more complex evaluations should be done. Due to the
nature of the applications, it is impossible to evaluate all the possibilities because for each cycle in
the state chart, new actions of the user could be performed. In order to have finite number of
evaluations, the author has design a set of 18 tests by consulting the use case chart, which evaluates
most of the actions performed by the user.

The use cases which are not evaluated belong to the type “Get information” which is:
 See all the categories
 See the videos belong to a category
 See the subscriptions updates
 See all the videos recommended
 See all the most viewed videos
 See all the most discussed videos
 See all the top rated videos
Because all they have been tested in the single state evaluation, there is no need to do it again.

There are also several things to take into account:

 The author assumes that the YouTube application is not working in “Logged in” mode. That
is, when the user starts the tests, the user hasn´ logged in previously or, if she has logged in
t
previously, she has logged out before finish the application.

 At the end of all the evaluations, the user will go back to the main screen because it is
considered as the final state. After it the user will finish the YouTube application by click on the
physical home button

The set of evaluation are done by following each one of the actions in the description, one after
another. For each one of the actions, the author examines if the action and its corresponding data
generated are captured or not by the YouTube monitor program.

Once all the actions are done, the author groups the results obtained (detected or not detected) by
Transition between states, General statuses, modes, parallel actions, internal states and information
34

obtained. All in the transition between states, general statuses, modes, the invocation of parallel
actions and the internal states are shown in the graph 4.2.2.2. All the possible information that could
be obtained is shown in the Appendix D.

6.3.2 Evaluation 1 - Play a video
This is the first of several tests done. In this test, the user is going to do the follow actions:
1. Launch the YouTube application
2. Select one of the video shown in the main screen to play it
3. Once the video has finished, she will come back to the main screen
4. Finish the YouTube application

Figure 6.3.2 – Evaluation 1 – Play a video

In this evaluation, there are 5 transitions between states, 2 switches between general statuses and 18
types of information are obtained. All they detected correctly.

6.3.3 Evaluation 2 - Play a video extended
This is an extension of the evaluation1. In this evaluation, when the user is playing the video, she
will perform several actions while the video is playing. The actions are:
2. Select one of the video shown in the main screen to play it
3. When the video has been played 10 seconds, the user forwards the video.
4. After 10 seconds, the user pause the video
5. The user plays the video again.
6. After 10 seconds, the user backwards the video
7. After 10 seconds, the user changes the quality of the video (HD off)
8. After 10 seconds, the user change restores the original quality of the video (HD on)
9. After 10 seconds, the user scrolls the video to the second 10.
10. After 10 seconds, the user enables the captions for the video
11. Once the video has finished, she will come back to the main screen

35

Figure 6.3.3 – Evaluation 2 – Play a video extended

In this evaluation, there are 5 transitions between states, 2 switches between general statuses, 8
internal states and 18 types of information. All they detected correctly.

6.3.4 Evaluation 3 – Record and upload a video
In this evaluation the user is going to record a video with camera and upload the video recorded.
Note the process of record video (step 3) is device dependent. It depends on the application of video
recording that each device has. Because of this, this process is not described. The actions are:
2. Click on the “Camera” button in the top-right corner
3. Record a video and click on “Done”
4. Fulfill all the information
5. Click on the button “Upload”. The YouTube application will go to the main screen automatically

Figure 6.3.4 – Evaluation 3 – Record and upload a video

In this evaluation, there are 4 transitions between states, 2 switch between general statuses, 1
parallel action and 3 types of information. All they detected correctly.

6.3.5 Evaluation 4 – Search a video
In this evaluation the user is going to search the videos by keyword. The result could be empty or
not depending on the keyword chosen and the videos in the YouTube server
2. Click on the “Search” button in the top-right corner
3. Enter a keyword or select one used for previous search. The YouTube application will show the
result screen
4. Come back to the main screen by clicking on the “Back” button

36

Master thesis

Recommandé

Recommandé

Contenu connexe

Similaire à Master thesis

Similaire à Master thesis (20)

Dernier

Dernier (20)

Master thesis