Automated Logging of Mobile Phones Failures Data
Paolo Ascione Marcello Cinque, Domenico Cotroneo
Laboratorio ITEM
Consorzio Interuniversitario
Nazionale per L’Informatica
Via Diocleziano 328, 80124 Naples, Italy
pascione@napoli.consorzio-cini.it
Abstract
The increasing complexity of mobile phones di-
rectly affects their reliability, while the user toler-
ance for failures becomes to decrease, especially
when the phone is used for business- or mission-
critical applications. Despite these concerns, there
is still little understanding on how and why these
devices fail and no techniques have been defined to
gather useful information about failures manifesta-
tion from the phone. This paper presents the design
of a logger application to collect failure-related in-
formation from mobile phones. Preliminary failure
data collected from real-world mobile phones con-
firm the proposed logger is a useful instrument to
gain knowledge about mobile phone failure’s dy-
namics and causes.
1 Introduction
Today’s market demand for enhanced mobile
and embedded devices, such as smart phones
and PDAs, is causing these devices to become
increasingly complex. While innovative features
are attractive and meet customer demands, the race
toward innovation increases the risk of delivering
less reliable devices, since new mobile phones are
often put on the market without comprehensive
testing. As a result, more and more users’ com-
plaints on mobile phone failures can be read on
several web forums dedicated to mobile phones.
These failures range from simple value failures to
freeze and self-reboot.
Although users complaints do not represent a
major issue, dependability of mobile phones
becomes an important concern as novel critical-
data-driven applications are being introduced
on the mobile phone market, e.g, phone-based
Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing
0-7695-2561-X/06 $20.00 © 2006 IEEE
Dipartimento di Informatica
e Sistemistica - Università
degli Studi di Napoli Federico II
Via Claudio 21, 80125 Naples, Italy
{macinque, cotroneo}@unina.it
banking, ticket booking, and e-trading. Depend-
ability will become even more critical as the
use of mobile phones is hypothesized in critical
application scenarios, e.g., robot control [12, 9],
traffic control [1] and telemedicine [3]. Finally,
the possibility of exchanging data increases the
smart phone’s sensitivity to malicious attacks. One
example is the recently reported virus for mobile
phones, called Cabir and affecting smart phones
with the Symbian OS.
Despite these concerns, there is still little under-
standing of how and why mobile phones fail or
of the methods/techniques needed to gain such
understanding. A well established methodology to
evaluate the dependability of operational systems
and to identify its dependability bottlenecks is
represented by field failure data analysis [8] (see
section 2.2). However, today’s smart phones do
not offer any mean to detect failure manifestations
and collect failure-related information.
This paper offers a solution to this problem by
proposing an automated failure data logger for
smart phones. In order to understand which fail-
ures are to be detected, we first define, in section 3,
a high level failure model for mobile phones based
on everyday user’s experiences. Then, in section
4, we detail the design of a heartbeat technique
to detect the most important failure occurrences.
Upon failure detection, the logger gathers many
useful information, such as the phone’s activity,
the list of running applications, and error condi-
tions signaled by system/application modules. The
technique has been implemented over Symbian OS
smart phones. We chosen the Symbian OS because
of i) its open programmability features with C++
and Java programming languages, and ii) its wide
spread use at the time of writing. The needed
Symbian OS background is given in section 2.1.
The logger has been deployed on 16 phones from
 Symbian Application (or server)
Non-preemtive scheduling,
Event driven synchronization
mechanisms
Active
Scheduler
Kernel
space
Thread Scheduler
Time-sharing
Preemptive
Thread Active Object
Priority based scheduler
Figure 1. Symbian multitasking model
September 2005. Since phone’s failures are not
frequent events, the data collected so far does not
have the statistical significance needed to draw
conclusions. Nevertheless, looking into portions
of the log files produced by the logger, in section
5 we show the logger capabilities to detect failure
occurrences and to relate them with the state of the
device. The logged data also allows to pinpoint
dependability bottlenecks and failures root causes,
to re-build failure dynamics, and to measure their
temporal characteristics.
2 Background and Related Research
2.1 Symbian OS fundamentals
Symbian [7] is a light-weight operating system
designed for mobile phones and carried out by
several leader mobile phone’s manufacturers. It
is based on a hard real-time, multithreaded ker-
nel that is designed according to the microker-
nel approach. Specifically, the microkernel pro-
vides simple, supervisor-mode threads, along with
their scheduling and synchronization operations.
Moreover, the kernel offers basic abstractions, i.e.,
address spaces and message passing interprocess
communication. All system services are provided
by server applications. Clients access servers using
message passing kernel’s mechanisms. Examples
of servers are the File Server, for files’ manage-
ment, the Window Server, for user interface draw-
ing, and the Message Server for the Short Message
Service (SMS) management.
The Symbian OS defines two levels of multitask-
ing: threads and Active Objects (AOs). Threads
are scheduled by the OS thread scheduler, which is
a time-sharing, preemptive, priority-based sched-
uler. Moving up a level, multiple AOs run within
a thread (see figure 1). They are scheduled by a
non-preemptive, event-driven scheduler, called ac-
Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing
0-7695-2561-X/06 $20.00 © 2006 IEEE
tive scheduler. In other terms, AOs cooperatively
multitask using an event-driven model: when an
AO requests a service, it leaves the execution to an-
other AO. When the requested service completes,
it generates an event that is detected by the ac-
tive scheduler, which in turn inserts the requesting
AO in the queue of the AOs to be activated. Non-
preemption was chosen to meet light-weight con-
straints, avoiding synchronization primitives such
as mutexes or semaphores. Moreover, AOs belong-
ing to the same thread all run in the same address
space, so that a switch between AOs incurs a lower
overhead than a thread context switch. AOs non-
preemption characteristics make them not suitable
for real-time tasks. On Symbian OS, real-time
tasks should be rather implemented using threads
directly. The whole design constitute a good com-
promise between real-time and light-weight design
requirements.
A crucial aspect of interest for our activity is rep-
resented by panics. In the Symbian OS world, a
panic represents a non-recoverable error condition
notified to the Kernel by either user or system ap-
plications. The panic information associated with
the event is a record composed of its category and
type. Once this event has been notified, the appli-
cation is killed by the kernel. As for panics no-
tified by system servers, the kernel might decide
to reboot the phone to recover them, based on the
panic’s severity.
2.2 Related Research
The field failure data analysis of operating sys-
tems is a well established research area. Exam-
ples are analysis of Windows NT [8, 16], Windows
2000 [14], and Linux [6, 13]. Other studies char-
acterized failures of networked systems, network
of workstations [15] and more recently, large-scale
heterogeneous server environments [11]. Less
work has been profused in the field of mobile
distributed systems. An architecture for gather-
ing and analyze failure data for the Bluetooth dis-
tributed systems has been proposed in [5], whereas
in [10], data collection and processing for a cellular
telecommunication system have been addressed.
All these works exploit failure information stored
into system event logs, automated reportings, or
failure reports provided by specialized mainte-
nance staff. In the case of smart phones devices,
logging facilities are limited and not fully exploited
yet. In particular, the Symbian OS offers a par-
ticular server (the flogger) allowing an application
to log its information. Yet, to access the logged
data of a generic X system/application module it
is necessary to create a particular directory, with
 a well defined name (e.g. Xdir). The problem is
that the names of such directories are not made
publicly available to developers, and are used by
manufacturers during the development. Recently, a
tool called D EXC1 has been proposed to register
all panic events generated on a phone. However,
the tool does not relate panic events with failure
manifestations, running applications, and phone’s
activity at the time of the failure.
3 Smart Phones’ Failure Model
We propose a high level classification of failures
based on the only freely available data source on
mobile phone failures: the users. Thus, we found
several web forums2 where mobile phone users
post information on their experiences using differ-
ent devices. The posted information has been care-
fully studied in order to consider only those posts
that signal a failure of the device. In the following,
we categorize such failures into five classes.
• Freeze: the device delivers a constant output,
and it does not respond to the user’s input.
The only way to restore proper operation is to
pull out the battery from the phone. This kind
of failure is also know as halting failure [2].
• Self-reboot: the phone reboots itself, and no
output is delivered at all during the reboot. It
is also called silent failure [2]. As already
mentioned in section 2.1, on Symbian OS
smart phones this might be caused by unre-
coverable and high severe system panics.
• Unstable behavior, or erratic failure [2]: the
device exhibits erratic behavior without any
input inserted by the user. Examples are con-
tinuous self-reboots, and self-activation of ap-
plications or modes of operation.
• Output failure: The device delivers an out-
put in response to a certain input that devi-
ates from the expected one. This is also called
value failure [4]. Examples reported by users
include inaccuracy in charge indicator, ring or
music volume different from the set one, and
event reminders going off at wrong times.
• Input failure, or omission value failure [4]:
User inputs have no effect on device behav-
ior, e.g. soft keys do not work.
1D
EXC is a Symbian project, available at
http://www.symbian.com/developer/downloads/tools.html
2 We considered www.howardforums.com cellphonefo-
rums.net, www.phonescoop.com, and www.mobiledia.com.
Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing
0-7695-2561-X/06 $20.00 © 2006 IEEE
Although this classification is defined according to
a high level of abstraction, it represents an impor-
tant initial step towards the definition of the logger.
It is indeed necessary to know the nature of the fail-
ures in order to detect them and to relate their oc-
currences with other information available on the
phone. More insights about failure dynamics and
causes can be gained once a significant amount of
failure data will be available. As shown later, in
section 5, the logger represents a valid instrument
to collect such failure data.
4 Automated Failure Data Logging
4.1 Assumptions and Goals
We concentrate on freeze and self-reboot fail-
ures, since they are easy to detect yet severe failure
manifestations. Some unstable behavior failures,
such as repeated self-reboots, can be captured as
well. As for input and output failures, we do not
pay attention to them for their less important sever-
ity and for the fact that the automatic detection of
value failures would require the implementation of
a perfect observer which has a complete knowledge
of the system specification [4].
The main objective of the logger is to detect and
record the occurrences of freezes and self-reboots.
Other than this, it is important to catch the status
of the phone during the failure. For example, let
us assume that a phone freezes when a text mes-
sage is received. Probably, detecting the freeze is
not enough, but it is desirable to answer questions
like: 1) are we able to know that a text message
was being received? 2) Do we know whether some
user/system module failed? And 3) are we con-
scious of the other running applications running
during the failure (which may cause interferences)?
4.2 Logger High Level Architecture
Based on the previous considerations, we de-
signed a logger application as a set of AOs, each
one responsible of a particular task. The logger ar-
chitecture is shown in figure 2. Each AO interacts
with a particular OS server to perform its task, and
all AOs use File Server facilities to store their data.
The logger is conceived as a daemon application
that starts at the phone start-up and that executes
in background. The AOs building the logger are
detailed in the following.
• Heartbeat: it implements the technique to
detect both freezes and self-reboots. More
details about the heartbeat technique can be
found in the next subsection.

Log
beats activity File runapp
Kernel Db Log File
Appl.
Arch.
System
Servers
Panic Log HeartBeat Running
Detector Engine App
Detector
Logger
Application
ACTIVE SCHEDULER
Figure 2. Overall architecture
• Running Applications Detector: this AO pe-
riodically stores on the runapp file the list
of IDs of all the applications running on the
phone. The list is obtained by requesting it to
the Application Architecture Server.
• Log Engine: it is responsible to collect the
smart phone activity (e.g. calls, messages, and
browsing). The information is gathered from
the Database Log Server, and it is stored into
the activity file.
• Power Manager: it provides information
about the battery status, in order to distinguish
self-reboots due to failures from those due to
low battery. The battery status is gathered
from the System Agent Server, and it is stored
into the power file.
• Panic Detector: collecting panics as soon as
they are launched is one of the main objectives
of the logger. In order to gather panics and the
related information (e.g. panic category and
type), the Panic Detector exploits the services
provided by the RDebug object, offered by the
Symbian OS Kernel Server.
Other than collecting panics, the Panic Detector is
also responsible of putting all the information pro-
duced by the other components together into one
Log File. This operation is performed either when
a panic is detected or when the logger applica-
tion starts (i.e., when the phone starts). A draw-
back of the logger is that it cannot store data about
File Server’s failures. Nevertheless, this cannot be
avoided in that there is no way to permanently store
any information when the File Server fails.
It is worth noting that the proposed architecture
Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing
0-7695-2561-X/06 $20.00 © 2006 IEEE
Files answers the questions posed in previous section.
power
Question 1 is answered by asking the phone’s ac-
tivity to the Log Engine. The panic notifications
captured by the Panic Detection allow to identify
System user/system modules responsible for a self-reboot
Agent
or freeze, thus answering question 2. Finally, ques-
tion 3 is answered by means of the Running Appli-
cation Detector.
4.3 Detecting Freezes and Self-
Power reboots
Manager
Freezes and self-reboot detection is accom-
plished by means of the heartbeat technique. This
is a well known approach for crash detection. The
Heartbeat AO periodically writes a heartbeat item
on the beats file. The item is composed of a time-
stamp and a status info, i.e. ALIVE, REBOOT,
MAOFF, and LOWBT. During normal execution,
the Heartbeat writes an ALIVE item. When a shut-
down is performed either by the user or automati-
cally undertaken by the kernel, the Heartbeat writes
a REBOOT item, since it is capable to capture the
phone shutdown event. It is worth to mention that
when the phone is rebooted the OS leaves a certain
time to applications to complete their tasks. This
time is sufficient for the Heartbeat to write the RE-
BOOT item. When the user deliberately turns off
the logger application, a MAOFF (Manual OFF)
item is written. This helps to distinguish manual
shut downs of the logger from freezes. Finally, if
a shutdown is due to low battery (the battery sta-
tus is requested to the Power Manager), a LOWBT
(LOW BaTtery) item is written.
When the phone is turned on and the logger starts,
the Panic Detector checks the last written item by
the Heartbeat. When an ALIVE is found, the phone
has been shut down by pulling out the battery. In
all other cases (i.e., a shutdown due to low battery,
user, or kernel) the Heartbeat would have written
REBOOT or LOWBT. This means that the phone
was frozen, coherently with the fact that pulling out
the battery is the only reasonable user-initiated re-
covery action for a freeze. Therefore, a freeze is
registered by the Panic Detector, along with the in-
formation gathered by the Log Engine and the Run-
ning Applications Detector.
On the other hand, a REBOOT can be found for
three reasons. First, the phone rebooted itself. Sec-
ond, it was rebooted by the user to recover a fail-
ure (e.g., output failure). Third, it was regularly
shut down. Hence, the problem of distinguishing
this three cases arises. Unfortunately, we are not
able to systematically distinguish phone induced
reboots from manual ones, because the generated
event i.e., the one captured by the Heartbeat AO,
 is the same in both the cases. However, they can Uncertainty Zones

be distinguished by looking at the off time of the

High
Medium

Low
phone, or reboot duration. It is reasonable to state:

TSR ≤ TM R < TSH

where TSR is the duration of a self reboot, TM R

is the duration of a manual reboot, and TSH is the
duration of a regular shutdown. In other terms, the
duration of a shutdown (e.g., when the phone is
shut down over the night) is greater than the du-
ration of a user initiated reboot, which is in turn
greater than or equal to the duration of a self-
reboot. A manual reboot requires the user to press
the on button, which generally requires more time
than a self-reboot. The Panic Detector registers a
self-reboot event and its duration. This way, the Figure 3. Δw as a function of fh , with
reboot duration can be analyzed a posteriori. It re- different application workloads (up-
mains hard to distinguish manual reboots and self- per plot), and I as a function of fh
reboots, but, in case of self-reboot, the Panic De- (lower plot)
tector also registers the panic which caused the re-
boot. This is a further way to distinguish between
the two cases.
respect to different application workloads running
on the phone: SMS, phone call, video call, listen-
4.4 Heartbeat Frequency
ing of an audio clip, and Bluetooth file transfer. We
also performed measurements with an “idle work-
The hertbeat frequency fh is a logger’s crucial
load”, i.e., when the phone is in stand-by mode.
parameter since it determines the time granularity,
The measurements were performed on two differ-
or uncertainty, at which the above mentioned dura-
ent Symbian smart phones: Nokia 6630 and Mo-
tions, i.e., TSR , TM R , and TSH , can be measured.
torola A1000.
It would be desirable to choose an arbitrary big fh
As far as Δw measurements are concerned, we run
to decrease the uncertainty of the measurements.
the logger concurrently with one of the mentioned
However, this is not possible for two practical rea-
workloads, for each fixed fh . As an effect of the
sons: i) the battery consumption induced by the
writing delay, the timestamps on the beats file are
logger increases as fh increases, and ii) the heart-
written with a period Th + Δw . Hence, from the
beat precision decreases as fh increases, as will be
timestamps we can evaluate the average Δw .
shown later by our experiment. The heartbeat pre-
As for I measurements, we connected the phones’
cision can be defined as:
power supply pins with a stabilized voltage genera-
precision = Th
, Th = 1 tor (set to 3.7 V , i.e., the nominal voltage provided
Th +Δw fh
by phone’s batteries). We also connected an am-
where Δw is the write delay induced by the File perometer in series with the supply circuit in order
Server. In other terms, once fixed a heartbeat fre- to measure the average I with different fh . For
quency fh , and thus a heartbeat period Th , the each fh , I has been measured for ten minutes. Be-
heartbeat items will not be written exactly each Th , ing the current absorbed by the logger low as com-
but they will be written each Th plus the time Δw pared with the application workloads, we adopted
needed to invoke the File Server, transfer to it the the idle workload to perform the current measure-
information to write, access the file, and actually ments.
write it. The greater is fh , the smaller is the pre- Figure 3 shows the results of the experiment. As
cision, because as Th decreases, it becomes com- we expect, both the average Δw and the average
parable with Δw . Moreover, as Th decreases, Δw I are increasing functions of fh , independently
increases because the File Server starts to be over- from the workload. With the idle workload, we
loaded with requests. As for the battery consump- experienced that fh = 2 Hz (Th = 0.5 s.) is
tion, the greater is fh , the greater is the absorbed a physical upper bound after which Δw starts to
current I. This is confirmed by our experiment. increase almost exponentially. For this reason,
We evaluated the average Δw and the average I as the experiments shown in figure 3 have been run
a function of fh . The average Δw is evaluated with with fh ranging from 0.1 Hz to 2 Hz (for the cur-

Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing
0-7695-2561-X/06 $20.00 © 2006 IEEE
 Smartphone under
observation
Gateway
Workstation
Database
Server
(GW)
logger, midlet database
GW software
Figure 4. Distributed Data Collection
Architecture
rent, fh starts from 0.05 Hz). The figure shows
that the most critical application is the video call.
This could be expected as the video call use a
wide range of phone’s resources. From figure 3
one could conclude that the best choice to meet
precision and battery consumption requirements
would be fh = 0.1 Hz or even lower. On the
other hand, low frequencies increase the uncer-
tainty. For example, fh = 0.1 Hz introduces an
uncertainty of 10 seconds on the measured TSR ,
TM R , and TSH , which makes it hard to distinguish
one from the other. For this reason, on figure 3
we draw three qualitative uncertainty zones: high
uncertainty (fh ≤ 0.1 Hz), medium uncertainty
(0.1 Hz < fh ≤ 0.33 Hz), and low uncertainty
(fh > 0.33 Hz). For the logger we deployed so far
on actual phones, we chose fh = 0.33 Hz, in the
medium uncertainty zone, since it represents an ac-
ceptable trade-off between uncertainty (3 s.), pre-
cision (in the worst case, the average Δw is 28 ms.,
hence the precision is 0.99), and battery consump-
tion (the average I is 6.6 mA, hence, being for
example the battery capacity of the Nokia 6630
equals to 900 mAh, the stand-by time with the log-
ger running on the phone would be 136 hours, that
is almost 6 days. This is acceptable if we consider
that the manufacturer declare a stand-by time from
6 to 11 days for the Nokia 6630).
4.5 Distributed Data Collection
Architecture
The logger has been deployed on actual phones
used by students, faculty and staff of our Univer-
sity. In order to allow them to easily transfer to
us their Log Files, without requiring them to spend
money (e.g., by avoiding the use of SMS services
or data connections), we developed a data collec-
tion architecture. The architecture is structured ac-
cording to a 3-tier model (see figure 4).
The first tier is the phone. In particular, we devel-
oped a Java midlet for the phone using the Java 2
Micro Edition technology. The logger requests the
user to send the Log File when it reaches a certain
Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing
0-7695-2561-X/06 $20.00 © 2006 IEEE
size (20 KB in the current implementation). When
the user is ready, the midlet can be used to send
the Log File to the tier 2, the Gateway Worksta-
tion (GW), via a Bluetooth connection. However,
if the user’s phone or GW does not provide Blue-
tooth connection facilities, he or she can avoid to
use the midlet and can transfer the file via the serial
cable usually used to synchronize the phone with a
computer.
The GW (tier 2) is a user’s computer connected
to the Internet. It runs our software to receive
the Log File via Bluetooth, and to send it to our
Database node (tier 3) using the Internet. To this
aim, the user must authenticate himself/herself to
the Database node. Again, if Bluetooth connec-
tions are not available, the GW allows the user to
select the Log File to send from his/her computer’s
file system.
Finally, the tier 3 stores the received files on a cen-
tralized database, after checking the Log File for-
mat. The data collected on the database can then
be used to perform the field failure data analysis.
5 Preliminary Results: Logger Capa-
bilities
The logger has been implemented for
several Symbian OS phones with differ-
ent user interfaces and APIs. It can be
downloaded from the project’s web site:
http://www.mobilab.unina.it/symdep.htm, along
with the java midlet and the GW software for data
collection. The logger has a low memory footprint
(16.1 KB) and, as for the files it produces, they
occupy at most 30 KB on the phone internal
memory.
At the time of writing, the logger was running
on 16 phones from September 2005. However,
the data collected so far (i.e., about 100 failure
points) are not enough to achieve the needed
statistical significance to perform dependability
measurements. More time, and more phones are
needed to achieve this goal. Therefore, in this
section we prefer to focus on some significant
portions of the collected Log Files in order to show
the logger’s capabilities.
The first Log File portion shown in figure 5 comes
from a Nokia 6680 device. Entries in the log
are not timely ordered. This is due to the fact
that the Panic Detector starts to log from either a
panic indication or a FREEZE or PWOFF event,
and then it gathers and writes on the Log File all
the related information from the other files (i.e.,
activity and runapps), which could be registered
before the panic (or FREEZE or PWOFF) event.
 Portion 1
19/10/2005 12:12:17
Category: KERN-EXEC
Panic Type: 3
19/10/2005 12:12:09 SysAp ScreenSaver Telefono Menu Messaggi Autolock SymDep
19/10/2005 12:12:15 Short message
19/10/2005 12:15:52 FREEZE Days 0 Hours 0 Mins 3 Secs 15
19/10/2005 12:12:09 SysAp ScreenSaver Telefono Menu Messaggi Autolock SymDep
19/10/2005 12:12:22 SysAp ScreenSaver SymDep

Portion 2
01/10/2002 15:36:51
Category: irSec
Panic Type: 666
01/10/2002 15:36:49 Total irRemote SysAp ScreenSaver Telefono Menu Autolock
SymDep
01/10/2005 15:41:03
Category: irSec
Panic Type: 666
Category: KERN-EXEC
Panic Type: 3
01/10/2002 15:40:52 SysAp ScreenSaver Telefono Menu Orologio Autolock SymDep
01/10/2005 15:42:24 PWOFF Days 0 Hours 0 Mins 1 Secs 16
01/10/2002 15:40:52 SysAp ScreenSaver Telefono Menu Orologio Autolock SymDep
01/10/2005 15:41:04 SysAp ScreenSaver SymDep

Figure 5. Two sample portions of a Log File

The portion reported in the figure is an example
of a freeze. The log allows us to pinpoint the
Messages service (Messaggi in Italian) to be
responsible of the panic, and thus, of the failure.
At the 12:12:17 of October 19, 2005, the logger
captured a type 3, Kern-Exec panic. Browsing the
list of panic types and categories on the Symbian
OS web site, we can obtain more details about the
panic: “This panic is raised when an unhandled
exception occurs. Exceptions have many causes,
but the most common are access violations caused,
for example, by dereferencing NULL. Among
other possible causes are: general protection
faults, executing an invalid instruction, alignment
checks, etc.”. A few seconds before the panic, the
Running Application Detector registered seven
active applications (SymDep is our logger). One
of those applications signaled the panic which in
turn caused the phone to freeze. A FREEZE entry
is logged by the Panic Detector when the phone
finished the reboot, at the 12:15:52; the reboot
took several minutes, specifically 3 minutes and
15 seconds (TSR = 210s.), probably due to the
fact that the user had to pull out the battery. By
subtracting TSR from 12:15:52, we infer that the
last ALIVE item was written at 12:12:37, i.e., 20
seconds after the panic. This could be the time
needed by the user to realize the phone were frozen
and to decide to pull out the battery. Moreover,
the Log Engine registered that 2 seconds before
the panic, a short message was sent or received.
Another interesting information is given by the last
line, which shows that 5 seconds after the panic
only 3 applications were active. We can thus argue
that one of the absent applications provoked the
panic. Aided by the information provided by the
Log Engine, we can conclude that the responsible
application was the Messages service.
We can rebuild the failure dynamic as follows:
at 12:12:15 a short message is sent or received.
This causes the Messages service to fail and to
signal a type 3, Kern-Exec panic. The OS recovery
mechanism killed the failing service and caused a
chain of events that brought the phone to freeze.
The second portion in figure 5 is a further example
of the type of information that can be captured. It
shows a self-reboot caused by a third-party appli-
cation, called irRemote, used to turn the phone into
a universal, infra-red remote control. Data comes
from a Nokia 6600 phone. At 15:36:51, a type
666, irSec panic is detected. This panic is specific
of the irRemote application, that is thus killed
by the kernel. After a few minutes, at 15:41:03,
another irSec panic is signaled. This indicates
that, after the first failure, the irRemote application
has been launched again by the user. The second
time, however, the failure is more severe, and also
causes a type 3, Kern-Exec panic, perhaps signaled
by a service used by irRemote. 6 seconds after
the panic, at 15:41:08, the phone reboots itself
(the reboot took 1 minutes and 16 seconds), as
can be observed looking at the PWOFF entry. In
other terms, this time the OS recovery mechanisms
killed irRemote and successfully performed a self-
reboot in response to the unrecoverable Kern-Exec
panic.

Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing
0-7695-2561-X/06 $20.00 © 2006 IEEE
 6 Conclusions and Future Work
This paper presented the design of a logger ap-
plication to automatically gather failure-related in-
formation from Symbian-OS-based smart phones.
Even if tailored for the Symbian OS, the described
technique can also be adopted on other platforms.
Although the volume of data collected so far are
not enough to achieve statistical significance, the
examples discussed in section 5 allow us to draw
the following conclusions about the logger capa-
bilities:
• The logger enables the definition of a detailed
failure model for mobile phones, in that it al-
lows to pinpoint causes, i.e., panics, that lead
to failure manifestations, and to rebuild fail-
ures dynamics.
• Since all failure manifestations come with a
timestamp, the logger makes it possible to
quantify the dependability of current smart
phones, in terms of Mean Time Between Fail-
ures (MTBF) and Mean Time To Recover
(MTTR). More in detail, parameters such as
the mean time between freezes or reboot, and
the propagation time between causes (panics)
and failures could also be measured.
• The logger allows to pinpoint application or
servers responsible for failures. In other
terms, it allows to identify dependability bot-
tlenecks.
Future work will be devoted to the deployment of
the logger over more terminals and to the analysis
of the collected failure data, in order to fully
exploit the logger capabilities and define a detailed
failure model for smart phones.
Acknowledgments
This work has been partially supported by the fund for mo-
bility of researchers, sponsored by the University of Naples
Federico II - Ufficio Programmi Internazionali, and by the Ital-
ian Ministry for Education, University, and Research (MIUR)
in the framework of the FIRB Project “Middleware for ad-
vanced services over large-scale, wired-wireless distributed sys-
tems (WEB-MINDS)”.
References
[1] V. Astarita and M. Florian. The use of Mobile
Phones in Traffic Management and Control. Proc.
of the 2001 IEEE Intelligent Transportation Sys-
tems Conference, August 2001.
[2] A. Avizienis, J. Laprie, B. Randell, and
C. Landwehr. Basic Concepts and Taxonomy
of Dependable and Secure Computing. IEEE
Transactions on Dependable and Secure Comput-
ing, 1(1):11–33, 2004.
Proceedings of the Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing
0-7695-2561-X/06 $20.00 © 2006 IEEE
[3] A. A. Aziz and R. Besar. Application of Mobile
Phone in Medical Image Transmission. Proc. of
the 4th National Conference on Telecommunication
Technology, January 2003.
[4] A. Bondavalli and L. Simoncini. Failures Classifi-
cation with Respect to Detection. Proc. of the 2nd
IEEE Workshop on Future Trends in Distributed
Computing Systems, 1990.
[5] M. Cinque, F. Cornevilli, D. Cotroneo, and
S. Russo. An Automated Distributed Infrastructure
for Collecting Bluetooth Field Failure Data. to ap-
pear in Proc. of the 8th IEEE International Sym-
posium on Object-oriented Real-time distributed
Computing (ISORC’05), May 2005.
[6] W. Gu, Z. Kalbarczyk, R. K. Iyer, and Z. Yang.
Characterization of Linux Kernel Behavior under
Errors. Proc. of the 2003 International Conference
on Dependable Systems and Networks (DSN’03),
June 2003.
[7] R. Harrison. Symbian OS C++ for Mobile Phones
Volume 2. Symbian Press, 2004.
[8] R. K. Iyer, Z. Kalbarczyk, and M. Kalyanakrish-
nam. Measurement-Based Analysis of Networked
System Availability. Performance Evaluation Ori-
gins and Directions, Ed. G. Haring, Ch. Linde-
mann, M. Reiser, Lecture Notes in Computer Sci-
ence 1769, Springer Verlag, 2000.
[9] T. Kubik and M. Sugisaka. Use of a Cellular Phone
in mobile robot voice control. Proc. of the 40th
SICE Annual Conference, July 2001.
[10] S. M. Matz, L. G. Votta, and M. Malkawi. Analysis
of Failure Recovery Rates in a Wireless Telecom-
munication System. Proc. of the 2002 International
Conference on Dependable Systems and Networks
(DSN’02), June 2002.
[11] R. K. Sahoo, A. Sivasubramaniam, M. S. Squil-
lante, and Y. Zhang. Failure Data Analysis of
a Large-Scale Heterogeneous Server Environment.
Proc. of the 2004 International Conference on De-
pendable Systems and Networks (DSN’04), June
2004.
[12] A. Sekman, A. B. Koku, and S. Z. Sabatto. Hu-
man Robot Interaction via Cellular Phones. Proc.
of the 2003 IEEE Int. Conf. on Systems, Man and
Cybernetics, October 2003.
[13] C. Simache and M. Kaâniche. Measurement-Based
Availability Analysis of Unix Systems in a Dis-
tributed Environment. Proc. of the 12th Inter-
national Symposium on Software Reliability Engi-
neering (ISSRE’01), November 2001.
[14] C. Simache, M. Kaâniche, and A. Saidane. Event
Log based Dependability Analysis of Windows NT
and 2K Systems. Proc. of the 2002 Pacific Rim In-
ternational Symposium on Dependable Computing
(PRDC’02), December 2002.
[15] A. Thakur and R. K. Iyer. Analyze-NOW - An En-
vironment for Collection and Analysis of Failures
in a Network of Workstations. IEEE Transactions
on Reliability, 45(4):560–570, 1996.
[16] J. Xu, Z. Kalbarczyc, and R. K. Iyer. Networked
Windows NT System Field Data Analysis. Proc.
of the 1999 Pacific Rim International Symposium
on Dependable Computing (PRDC’99), December
1999.