This document describes a plugin developed for the AWARE framework that estimates the indoor or outdoor location type of a mobile device using its on-board sensors. The plugin analyzes data from the accelerometer, magnetometer, light sensor, location sensor, and battery to infer the location type. It is moderately battery efficient, consuming between 3-10% of total device battery. The plugin stores location data and inferences in a database and displays updates every 3 minutes. It uses sensor data and established boundaries to assign weightings to indoor or outdoor predictions and sums the weights to determine the overall location type. The plugin was evaluated using real sensor data and boundaries were adjusted until it accurately inferred location in over 60% of tests.

1. AWARE plugin for location type estimation
Pablo Panero
Department of Computer Science Engineering
University of Oulu
ppanero27@gmail.com
ABSTRACT
The location type or environment where a device is at a precise
moment is an important characteristic to take into account when
carrying out research or developing applications in order to
improve usability and efficiency. In consequence, we address the
indoor-outdoor (from now on called IO) distinction problem. Our
goal is to develop a plugin for the AWARE framework that infers
the location type analyzing the data collected from the device
sensors (i.e. accelerometer, magnetometer, light meter, location,
and battery). This plugin is moderate in battery consumption. It
can vary from 3% to 10% in consumption (of the total device
consumption), due to it turning on and off the sensors to avoid a
higher power draining. Even though the plugin is highly accurate,
the chosen approach has an impact on its accuracy. In addition the
plugin cannot infer the location in real-time, doing so in intervals
of at most three minutes.
Categories and Subject Descriptors
I.1.4 [Information systems applications]: Applications.
General Terms
Measurement, Human Factors.
Keywords
AWARE, context detection, mobile sensing, location type,
indoor-outdoor.
1. INTRODUCTION
Nowadays knowing the location type is a very relevant
characteristic to take into account for device efficiency and
usability optimization. As an example a mobile device could adapt
its settings and increase its usability depending on where it is,
therefore, saving battery, triggering reminders, or performing
other specified action. The implementation will be carried out
using the AWARE framework, which eases the mobile sensing
data gathering. This plugin will only be available for mobile
devices with Android OS 2.3.3 or higher.
2. RELATED WORK
There are many factors and sensors to take into account when
trying to estimate mobile devices’ placement (indoor/outdoor).
At first sight it should be enough to get the location of the device
using GPS technology to know if it is inside or outside of a
building. However, GPS technology is not always accurate
enough. Therefore other technologies, such as Wi-Fi Access Point
or cell tower triangulation, can be helpful to get more accurate
results of the position. Nevertheless, the computational effort
needed might exceed mobile phones’ capabilities, and if not, it
could result in a power drainer method.
An example that uses the sensors mentioned before (i.e. cell, light
and magnetic field sensor as primary source of data) is IODetector
developed by Zhou et al. [1], a lightweight sensing Android
application. Some of the assumptions used for the IODetector
development are:
• During daytime, in outdoors, light intensity is typically much
higher than indoors. Therefore, during daytime it assumes to
be outdoors, with high confidence, if the light sensors values
are higher than 2000 Lux. In a similar way it assumes that
during nighttime it is outdoors if the light sensor values are
lower than 50 Lux, but in this case with low confidence.
The light sensor is not taking into account if the proximity sensor
detects that the device may be in a pocket, bag, etc. where the
light is low almost always.
• When a device changes from outdoors to indoors the cell
tower strength drops rapidly due to the attenuation produced
by walls and ceilings. IODetector looks for changes of 15
dBm in intervals of 10 seconds to detect transitions between
indoor and outdoor. As argued by Radu et al. [2] this
threshold is not accurate enough, because that change can
happen indoors when going from one room to another.
• When a device is moving in an indoor environment the
magnetic field fluctuates more than outdoors, due to the
appliances, electronic devices, metallic objects, etc. that may
be nearby. IODetector looks for changes of 18 uT in intervals
of 10 seconds to detect changes between indoor and outdoor.
However, this threshold has been proven to be very inaccurate
by Radu et al. [2].
A common problem shared by the cell tower strength and
magnetic field sensors is that they require the sensor to run
continuously, resulting in a higher energy use.
A new possible environment taken into account by IODetector is
the one called “semi-outdoor”. That is when the device is close
enough to a building so the values from the sensors do not easily
distinguish between indoor and outdoor.

2. The architecture of IODetector is the following:
Figure 1: IODetector architecture
IODetector does not take into account any previous knowledge of
the environment it only uses on-board sensing. As argued by Radu
et al. [2], accuracy is greatly diminished by not knowing the
environmental context
As stated by Radu et al. [2] some thresholds set in IODetector to
consider indoor or outdoor (i.e. light sensor) could work or not
depending on the environment. For example in a sunny day the
light sensor would get accurate results, however, in a cloudy day
it will not be as accurate (i.e. the light sensor values might not go
beyond 2000 Lux when it is outdoors).
To solve this problem Radu et al. [2] present a solution, also
lightweight in energy consumption, using semi-supervised
machine learning. The proposed model needs to adapt to new
environments and/or devices. Doing so by collecting labeled
training data that requires the user involvement, what can result
impractical.
As stated by Radu et al. [2] the IO problem is essentially a
classification type problem solved using machine learning. The
current state is classified according to a tuple of values measured
by the sensors.
As argued by Wahl et al. [3] if we take into account more data
(not sampled by the mobile sensors, so we would have to rely on a
trustworthy source), such as time of the day, weather, surrounding
luminance, and environment information (e.g. using GPS) we
could even distinguish some aspects about the place. For this
purpose additional hardware is used (light sensing device wore in
the wrist). The following thresholds are proposed:
Figure 2: thresholds for placement distinction
Another aspect to take into account when approaching the IO
problem is where the device is. Meaning that we have to choose
which sensors to use depending on the current placement of the
device (e.g. do not take into account light sensor if the phone is in
the pocket).
There have been many attempts to solve this problem [4, 5, 6]. As
said by Guiry et al. [5] we can infer the placement of the device
using the accelerometer, magnetometer, and gyroscope (for
motion classification), the pressure sensor (for body placement),
and finally the light sensor (to detect changes in between different
locations).
For the purpose of estimating the body placement of the phone the
accelerometer, magnetometer, and gyroscope were each
interpolated to 100Hz. In a similar way, the light sensor was
interpolated to 10Hz. A band-pass filter was used to discard
changes that do not interest for this purpose.
Another approach proposed by Yang et al. [6] it to use an
estimation of the gravity vector on a surface, and the signal
magnitude variance from the accelerometer, and as before the
light sensor to distinguish changes between places, to estimate the
placement of the phone.
Some problems may be encountered when using the light and
proximity sensors for placement detection. For example, the
owner of the phone might be in a dark environment holding the
phone in his/her hands or making a call, so the ear would be
detected as a nearby object.
Another useful source of information could be the activities that
might be being performed by the owner of the device. It could be
helpful to solve the IO problem, since some activities cannot be
performed in one or another environment. Parandi et al. [7] also
find accelerometer patterns for certain activities such as going up
or down using an elevator, which would, with high confidence,
mean that the device is indoor.
Figure 3: accelerometer patterns
3. IMPLEMENTATION
The plugin was developed for mobile devices running Android
operative system with version 2.3.3 or higher. The chosen
developing environment was IntelliJ IDEA1
, and a GitHub
repository2
for version control. The plugin is implemented for the
AWARE Framework3
.
The plugin uses five sensors to infer the location type: battery,
location, light, accelerometer, and magnetometer. The established
bounds and weights for each sensor are shown in Table 3.
Notice that all sort of transport methods are categorized as
outdoors.
1
IntelliJ IDEA is a IDE from JetBrains: www.jetbrains.com/idea
2
www.github.com/ppanero/com.aware.plugin.io
2
www.github.com/ppanero/com.aware.plugin.io
3
www.awareframework.com

3. 3.1 Provider
The plugin has a database provider where it stores permanently
the collected data and the location type inferred, along with the
elapsed time (time spent in the same location type) and the last
update of the database. The table of the provider is the following:
Name Type Description
_id Integer Primary key, auto
incremented
timestamp Real Timestamp of the data
device_id Text ID of the device that
collected the data
io_status Text Location type
(indoor/outdoor)
elapsed_time Integer Consecutive unix time, in
seconds, spent in the location
type.
last_update Integer Unix time, in seconds, of the
last update of the location
type
magnetometer Integer Averaged value of the
magnetic field
double_accelerometer Real Averaged value of the
acceleration
battery Integer Battery status, values
corresponding to table 2.
light Integer Averaged value of luxes.
gps Integer GPS accuracy
Table 1: Provider table fields
3.2 Context card
The context card is the part of the plugin where changes are
shown to the user. This card is refreshed each three minutes. This
interval allows the plugin to perform its computations and insert
new values into the database, thus changes are noticeable. The
context card can be seen in figure 9.
3.3 IO Alarm
In order to reduce the power consumption the plugin has alarm
that turns on the sensors every two minutes. The sensors will stay
active until they get the amount of samples needed, and then they
will turn off.
3.4 Battery
The plugin receives changes in the battery status, meaning if it is
charging or not. If the phone is charging it is more probably in an
indoor environment, with even higher probability if it is being
charge from AC rather than USB.
Status Value
Discharging 0
Charging from AC 1
Charging from USB 2
Table 2: Battery status description
3.5 Location
The plugin also receives changes in the location, taking into
account only the location inferred by GPS technology, not the one
from the network. Therefore, it is more probable that the user is
indoors when the accuracy of the GPS location is lower, and
outdoors when it is higher.
3.6 Light
The light sensor is the slowest from the five sensors. Therefore it
is the one that sets the next alarm when it finishes its
computations.
This sensor will process 10 samples and average them in order to
minimize the impact of outliers in the measured value. The
reliability of the light sensor depends on the hour of the day, due
to that, the weight is multiply by a value given by the following
function (that receives the hour of the day in 24-hour format as
input):
𝑓 𝑥 = −
𝑥 𝑚𝑜𝑑 12
22
+ 1
Equation 1: Light adapter function.
This function is a straight line that gives 12 and 00 hours the
highest value and decreases it along with the increment of the
hour. This function is applied because, independently of the
season and longitude where the device currently is, the sun will be
in its highest point (brightest, therefore more luxes) at 12 and the
lowest point (darkest, therefore less luxes). An example of the
trajectory of the sun in Oulu is shown in figure 4.
The boundaries that conform the intervals are also multiply by
those factors in order to adjust them to the sunlight.
Figure 4: Sun trajectory in Oulu
3.7 Accelerometer
Likewise the light sensor, the accelerometer is turn on by the IO
Alarm approximately each two minutes. However, this sensor will
process 20 samples (also to minimize the impact of outliers). This
sensor can process more measurements because it is faster in
measuring, and cannot be set up to do it at a slower rate.
The samples are taken as x, y and z-axis values. In consequence it
is needed to calculate the vector (with the following function
𝑥! + 𝑦! + 𝑧!). The samples are also averaged to minimize the
impact of outliers.
3.8 Magnetometer
This sensor is treated in the same manner than the accelerometer.
It also takes 20 samples, calculating its vector and averaged them
to minimize the effect of outliers.

4. 3.9 Inferring location type
The plugin has a decision matrix where the previous sensors store
the location the inferred and the associated weight. The plugin
will sum up the weights associated to indoors and outdoors, being
the one with higher value the inferred by the plugin.
3.10 Bounds and weights
Sensor Bound Location
type
Weight
Magnetometer
M <= 47 Indoor 0,7
47 < M <= 52 Indoor 0,5
52 < M < 60 Outdoor 0,7
M > 60 Indoor 0,5
Accelerometer A <= 2 Indoor 0,2
A > 2 Outdoor 0,2
Battery B = 1 (AC) Indoor 0,9
B = 2 (USB) Indoor 0,6
Light (the first
4 cases are
during daylight
and the last
three during
night time)
The weights
and daytime
boundaries are
multiply by the
factor f(x)
defined
previously,
night
boundaries are
divided by it.
L <= 200 Indoor 0,8
200 < L <= 400 Indoor 0,6
400 < L <= 800 Outdoor 0,6
800 < L Outdoor 0,8
L < 3 Outdoor 0,8
3 <= L < 20 Indoor 0,6
20 <= L Indoor 0,8
GPS
G <= 10 Outdoor 0,8
10 < G < 20 Outdoor 0,6
20 <= G < 35 Indoor 0,3
G >= 35 Indoor 0,8
Table 3: Sensors boundaries and weights
4. EVALUATION
At first a simple plugin was developed to store sensor
measurements. From the store data we observed that the sensors
that provide the most data are the accelerometer and the
magnetometer. Even though not in the same volume, a lot of data
from the light sensor was also collected. A major disadvantage
was the lack of barometer and thermometer built-in the device.
From the accelerometer by itself it is difficult to infer the location
type. The main finding was that most of the time that the device
was indoors it was still (or almost still, due to noises in the sensor)
as can be appreciated in figure 5. In consequence, from the device
being still an indoor value with a low weight is assigned to the
decision matrix.
Figure 5: Accelerometer data sample
The magnetometer sensor, on the other hand, provided more
reliable data to work with. Being needed to adapt the boundaries
three times. At first the boundaries were:
M < 50 Indoor
50 <= M < 60 Outdoor
M < =60 Indoor
Table 4: Magnetometer initial boundaries
However, the previous boundaries were not as effective as
expected. Being it accurate in less than 60% of the tests.
The boundaries were changed one more time before finding the
final ones shown in table 3.
The battery sensor also provide highly reliable data, although with
high confidence it can only be use to infer an indoor environment.
It is due to the fact that if the device is being charge from AC it is
highly probable, if not assured, that it is indoors. The same could
be said when the device is being charge from an USB plug.
However the existence of portable battery chargers, the
confidence on it being indoors is lower.
In the first version of the plugin the telephony sensor was used.
The location type was trying to be inferred from the GSM tower
signal strength. The main problem was the speed in which the data
was being measured, most of the times it was to late to be
updated, or it was not reliable enough. In consequence, this sensor
was substituted for the location sensor.
The location sensor is a reliable source of data in extreme points,
meaning that if the accuracy is really high the fact of being
indoors could be guaranteed with high confidence, and the same
could be said when the accuracy is really low for outdoor
environments.
Notice that when talking about location accuracy it refers to the
radius in which the device is being detected. Therefore a higher
radius means that the signal is poorer, which may be due to the
interference of walls.
The first values were measured with a third party Android
application4
in order to take in the wild values for empiric
observation. Those first values lead to the following boundaries:
G < 8 Outdoor
8 <= G < 15 Outdoor
G > 15 Indoor
Table 5: Initial location boundaries
In contrast to those measured values, the ones provided by the
aware framework were lower (meaning a larger radius). The
collected measurements from the aware plugin lead to the
boundaries shown in table 3.
4
GPS – Simple:
https://play.google.com/store/apps/details?id=com.andreabacceg
a.simplegps

5. The light sensor is may be the most complicated one of the five. It
was discovered to be more reliable during daylight than at night,
being the variances between indoor and outdoor more noticeable.
Figure 6: Light data sample
At first neither the boundaries nor the weights were adjusted by
multiplying by the factor given by equation 1. From the second
data collection it was shown that the closer the hour is either to
midday or midnight the less accurate the sensor was inferring the
environment. In consequence the equation was applied to
diminish the weight of the light sensor in the global location type
inferring.
After adjusting the weights it was observed that also the lux
intervals vary along with the hour of the day. Therefore the
boundaries are also adjusted by being multiplied by the function.
This last adjustment leads to the boundaries shown in table 3.
Concerning energy consumption he plugin is reasonable efficient.
It can vary from 10% to 3% depending on the step it is in.
Figure 7: High consumption Figure 8: Low consumption
5. DISCUSSION
The plugin infers the location type with an accuracy of
approximately 70% - 80%. Even though it is reasonably accurate,
it can be made more precise using some sort of decision tree or
other method that takes into account combinations of the
measured values and its sensors. An aspect to have into account
are devices’ case, some cases are attached to the device using a
magnet, which highly interfere with the magnetic field measured.
Figure 9: Indoor Figure 10: Outdoor
The least accurate or reliable part is the elapsed time. This fact is
produce by outliers, because they change the location type (even
for a short period) and therefore the elapsed time is reset.
However, this fact can be minimized, even fixed, when analyzing
the collected data. In figure 10 is shown an outdoor outlier that
affects the elapsed time between figure 9 and figure 11.
Figure 10: Outlier Figure 11: Elapsed time fail
Nevertheless it can be made more efficient by improving the
boundaries of the sensors and using some sort of filter for the
measured values, instead of averaging, to minimize the effect of
outliers, so in consequence less samples would be needed and
therefore the sensor would need to be turned on less time. In
addition the IO Alarm frequency could be adjusted to run more
frequently if the previous change is made.
The function that is being applied to the light sensor weight could
also be improved by taking into account the latitude, the day and
season of the year, and the weather. Probably resulting in a
Gaussian function.
The testing and evaluation has been carried out with only one
device (Motorola Moto G2), thus more testing would be needed
with different devices from different vendors.

6. 6. CONCLUSION
Even though the plugin work reliably and accurate enough, there
are a huge variety of technologies that can be used to improve
those aspects.
If possible the barometer and temperature sensors should have to
be taken into account, they can provide highly relevant data to
infer location. However, those two sensors were not available in
the testing device. Moreover, machine-learning techniques can
also be applied to gradually improve the accuracy.
7. ACKNOWLEDGEMENTS
We acknowledge the AWARE team that made possible the
development of this plugin thanks to it framework. We also
acknowledge Denzil Ferreira for the help granted during the
development process.
8. REFERENCES
[1] Zhou, P., Zheng, Y., Li, Z., Li, M., & Shen, G. (2012,
November). IODetector: A generic service for indoor
outdoor detection. In Proceedings of the 10th ACM
Conference on Embedded Network Sensor Systems (pp. 113-
126). ACM.
[2] Radu, V., Katsikouli, P., Sarkar, R., & Marina, M. K. (2014,
November). A semi-supervised learning approach for robust
indoor-outdoor detection with smartphones. In Proceedings
of the 12th ACM Conference on Embedded Network Sensor
Systems (pp. 280-294). ACM.
[3] Wahl, F., Kantermann, T., & Amft, O. (2014, September).
How much light do you get?: estimating daily light exposure
using smartphones. In Proceedings of the 2014 ACM
International Symposium on Wearable Computers (pp. 43-
46). ACM.
[4] Miluzzo, E., Papandrea, M., Lane, N. D., Lu, H., &
Campbell, A. T. (2010). Pocket, bag, hand, etc.-
automatically detecting phone context through
discovery. Proc. PhoneSense 2010, 21-25.
[5] Guiry, J. J., Karr, C. J., van de Ven, P., Nelson, J., & Begale,
M. (2014, August). A single vs. multi-sensor approach to
enhanced detection of smartphone placement. In Engineering
in Medicine and Biology Society (EMBC), 2014 36th Annual
International Conference of the IEEE (pp. 3691-3694).
IEEE.
[6] Yang, J., Munguia-Tapia, E., & Gibbs, S. (2013, September).
Efficient in-pocket detection with mobile phones.
In Proceedings of the 2013 ACM conference on Pervasive
and ubiquitous computing adjunct publication (pp. 31-34).
ACM.
[7] Parnandi, A., Le, K., Vaghela, P., Kolli, A., Dantu, K.,
Poduri, S., & Sukhatme, G. S. (2010). Coarse in-building
localization with smartphones. In Mobile Computing,
Applications, and Services (pp. 343-354). Springer Berlin
Heidelberg.
[8] Alén, R. (2014, November). Estudio de la trayectoria solar en
Oulu.