Location-Based Services on a Smart Campus:

A System and A Study

Alexandr Petcovici and Eleni Stroulia
Department of Computing Science
University of Alberta
Edmonton, Canada
{apetcovi,stroulia}@ualberta.ca

Abstract- Knowledge about people’s geographical location can be
used to infer their possible needs, and to offer relevant services to
satisfy these needs. Such targeted approach in service demand
identification and service delivery is one of the reasons why
Location-Based Services (LBS) are so popular in our days. In this
paper, we describe a framework that we developed for offering
location-based services, relying on infrastructure typically
available in smart campus environments. Our framework
includes three user-facing components: 1) an energy-aware
Android application for end users to recognize their locations and
access the services available to them; 2) a web application, which
enables end users to search for services available on the campus
as a whole; and 3) a web application for managers to specify what
services are available on campus and in which areas. Each of
these applications communicates with a server from the middle
layer. Finally, a PostgreSQL database constitutes the
framework’s back-end, where information about the available
services and their spatial scope is maintained. We evaluate the
performance of our framework in terms of localization accuracy,
since this is the most critical quality for the effective delivery of
location-based services.
Keywords— Location Based Services, localization, Smart
Campus, energy consumption efficiency.
I. INTRODUCTION
We have recently been witnessing an increasing popularity of
Location Based Services (LBS). One of the reasons behind this
phenomenon is the ability of LBS to recognize the demand for
example, video-surveillance systems, which require
installation of video cameras for each new area to be
monitored for the purpose of offering location-based services.
In addition, the application server that receives data from video
cameras must continuously run computationally expensive
image-processing algorithms to identify users (and potentially
their activities) in the monitored areas. As the number of
cameras increases the number of required application servers
and associated hardware also increases. Smartphones represent
an alternative, lower-cost solution. For the purpose of
localization, smartphones can use and combine data from
various sources: GSM and GPS triangulation, Wi-Fi
fingerprinting, gyroscopes, 3D-accelerometers, etc. As a result,
they can be used for localization in both indoor and outdoor
environments. The main advantage of using smartphones for
localization is that there is no need to build a special-purpose
localization infrastructure.
The term “Smart Campus” refers to a space where virtual and
physical worlds interact in order to improve quality of life or to
offer a better learning experience. An essential component for
such systems is the connector, which links the virtual and
physical worlds. One possible way to perform this connection
is through LBS. This paper presents experience report of our
framework designed to offer location-based services in smart
campus environments. The high level architecture of the
framework is shown in Figure 1.
PostgreSQL DB
with PostGIS extension

services and to provide said services, based on one’s location.

Social networking, targeted advertisement, driver-assistant
programs, and augmented-reality games are just a few
examples where LBS have been successfully applied. One of User’s Web
Application Server
Admin’s Web
Application Server Mobile Application Server
the main requirements for LBS is localization, which, in this
context, can be defined as the ability to identify potential
service consumers in areas where services are provided. In
small-scale smart environments, such as smart-homes and
smart-offices, the cost of building accurate localization
infrastructure is low, due to relatively small size of the
monitored area. Motion Sensors, RFID tags and RFID tag- Client Web Page Client Web Page Admin Tool

readers, Wi-Fi fingerprinting and video surveillance are often Client Client Client

used for this purpose. For large-scale environments, however, Figure 1: High-Level representation of LBS Framework
the cost of localization infrastructure is high. Consider, for

94
 The front-end is composed from three separate components:
1) an Android application used for localization and service
delivery; 2) a web application which allows users to perform
look-ups for available on-campus services shown as Open
Layers 3 (OL3) [14] polygons on Open Street Map (OSM)
[13]; 3) a web application for administrators to maintain
services and service areas by modifying or drawing new OL3
polygons on OSM. At the back-end, the framework is
composed from a separate server for each front-end application
and a PostgreSQL [11] database for data storage.
The framework supports three types of services.
(a) Subscription services: Users can subscribe/unsubscribe
and specify the services that they wish to access.
(b) Notification services: These services are offered to all
users so that they can be informed about important events in
their current location (i.e. “West entrance to library is locked
due to maintenance. Please use another entrance”).
(c) Information services: Users can query their current
location for information (i.e. “You are in front of Athabasca
Hall”).
In order to benefit from our framework, users must install our
Android application on their smartphones. This application
runs as a background service and switches between two
operational states: passive and active. In the active state, the
localization service updates the user’s current location every
three seconds, and sends its coordinates to the application
server. In the passive state, the service only listens when the
user becomes mobile, while connected to the campus wireless
network. These two application states represent a mechanism
to minimize the application’s energy consumption. This
mechanism is inspired by the simple intuition that, by default,
the app should offer low-accuracy localization on low-energy
consumption mode; upon occurrence of an event of interest,
the application should switch ON the more energy-demanding
sensors to offer better localization accuracy. Ideally, GPS
should be OFF in passive operational state and ON in active
operational state. Unfortunately, for security reasons, the
functionality to programmatically turn ON and OFF GPS was
deprecated in newer Android OS versions. Thus, in the passive
state the energy savings are due only to reduced network
communications.
The main use-case offered by the framework is the following.
When a user is on campus, and enters in an area where LBS is
offered, the framework receives the user’s coordinates, verifies
if the user is allowed to access the service in question, and, if
so, the user is served. A more detailed description of the
framework is given in Section 3 of this paper.
The rest of the paper is organized as follows. Section 2 is
dedicated to related work. In Section 3, each component of the
framework is described in detail. Section 4 describes our
experimental evaluation, reports our results, and outlines some
ideas for future directions to improve the current framework
shortcomings. Section 5 concludes with a summary of this
work.
95
II. LITERATURE REVIEW
Challenges related to smartphone-based localization negatively
impact the Quality of Service (QoS) of location-based services.
The first challenge is accurate localization in indoor and
outdoor environments. Currently, the outdoor localization
accuracy through GPS is 3.5 meters [7]. Indoor localization is
not as good and is still an open problem. A number of research
approaches have been proposed to address this problem. For
example, in [6] authors proposed a smartphone indoor-
localization system, Guoguo. The system sends localization
beacons via high-band acoustic signals, inaudible to humans.
Localization accuracy achieved by Guoguo is from 6 to 25 cm.
The drawback of the system is that it requires the installation
of a special-purpose anchor network.
Some other indoor localization techniques also show good
results. For example, in [8] accurate localization was achieved
by fusion of data from WLAN signal strength combined with
user motion information data collected from gyro and three-
axis accelerometer. In [9], accurate indoor localization was
obtained by fusion of data from smartphone motion sensors
and Wi-Fi fingerprinting, using a Bayes filter. In [10], accurate
localization is obtained by applying Kalman filter to fused data
from smartphone sensors, Wi-Fi signal strength and
landmarks. Landmarks are identified based on specific sensor
patterns.
Another important issue is the problem of localization
accuracy when users transition from indoor to outdoor
environments and vice-versa. Some technical difficulties
related to this problem are discussed in [1], and they are related
to the fact that the sensors that provide useful data for
localization in one environment may not be as useful when the
environment changes.
In our framework, we use the Fused Location Provider [12]
developed by Google Inc. This component is part our mobile
application. In order to determine accurate location of the
smartphone, the Fused Location Provider uses aggregate data
collected from GPS, Wi-Fi, GSM, 3D-accelerometer,
Gyroscope and other smartphone sensors. In order to obtain the
most accurate data, we set the provider to operate in
HIGH_ACCURACY mode, which uses GPS as the primary
source of data for localization outdoors, and Wi-Fi as the
primary source of data for indoor localization [18]. Google Inc.
does not disclose specific information about how exactly Wi-Fi
data is used for localization, nor on how the change between
environments is detected. There are several reasons why we
decided to use this component in our application. First, it offers
two key functionalities: sensor fusion for localization and
indoor-outdoor context recognition. From a pragmatic
perspective, this component is available for Android
developers for free, it is actively maintained and well
documented. Also, Fused Location Provider benefits from high
popularity among Android Application developers and, as a
result, there are many online resources dedicated to it such as
forums, blogs and tutorials.
The second challenge is minimization of energy consumption B. User’s Web Application
of our mobile application, mainly caused by GPS. An The end-user’s web application is shown in Figure 2. This is a
attractive solution is presented in [2]. Initially, this application visualization component for displaying the various coverage
uses GSM triangulation for localization; when it detects the areas, within which services are offered, along with specific
occurrence of an event of interest, it turns ON GPS in order to information about these services. This information is presented
get more accurate data. In this manner, the application on Open Street Map, as OL3 shapes.
conserves energy when “nothing interesting” is happening. In
our framework, we tried the same approach. The problem is
that ability of applications to start and stop GPS
programmatically represents a potential thread for privacy, and
the latest versions of Android OS have deprecated this
functionality.
There are several examples [3][4][5] of smart campus
environments that offer information to help user to find points
of interests on smart campus maps. However, none of these
examples actively offer services to their occupants, as they
enter a geofence particular to a service.

III. THE LBS FRAMEWORK

As we mentioned in the Introduction, our framework is Figure 2: User’s Web Application for service are lookup
designed to offer location-based services in Smart Campus
environments via an Android application. At the end of the C. Admin’s Web Application
introduction section we described at a high level the core To modify existent services and to create new ones, our
architecture and basic functionality of the framework. In this
framework offers the admin’s web application, shown in
section, we will present in details the design and functionality
of each component separately. Figure 3. It is delivered to administrator user as a JSP page that
communicates with the corresponding service through Java
Beans. This defines the mechanism of how data from(to) the
A. PostgreSQL with PostGIS extension
client browser is loaded to(from) the database.
The database engine used by our framework is PostgreSQL
[15]. It was favored over other engines due to its popular
extension named PostGIS [11]. This extension supports the
specification of spatial objects and enables the formulation, and
efficient answering, of spatial queries.
In our framework, we define service areas as polygons; the
vertices of each polygon are represented as point coordinates in
a Spherical Mercator projection. The mobile application, once
installed on the user’s smartphone, sends the user’s coordinates
to the application server. When a user enters an area where a
service is offered, the application server uses the most recently
received coordinates to query the database and to find out if
user’s current location matches any services for which he is
qualified.
Figure 3: Admin’s Web Application to modify areas for existent LBS and
The mobile application continuously updates the user’s location to add new. This example shows how a polygon is drawn to match a
to the mobile-app server. When a user enters an area where a building from campus
service is offered, the application server uses its coordinates to
query the database to find out if user’s current location matches D. Mobile Application Server
any services for which the user is qualified. The Android application installed on users’ smartphones
Each front-end client interacts with a corresponding middle- communicates with the Mobile Application Server via secure
tier server. The first two servers are (a) the end-user’s web- sockets, relying on a self-signed certificate embedded in the
application server and (b) the administrator’s application mobile application. The server handles four types of incoming
server. They both run on Apache Tomcat 7 and serve JSP messages.
pages and communicate with the corresponding clients via (1) Initialization Message. When a client connects to the
Java Beans. server, it sends an initialization message containing its user ID.
The server uses this ID to query the database for the list of

96
services for which the client is qualified. This list is composed
of the services to which the user subscribes, and the list of
notification services currently active on campus. Notification
services are offered to all users, since they contain important
information about events on campus. The purpose of this list is
to create a cache-like mechanism designed to make queries
more fine grained and to reduce the load to the database.
Further, this list is referred to as the list of cached services.
When a service is offered to client, it is dropped from the
cached list of services, to prevent the user from being served
twice. Sometimes the client application experiences
interruptions in connection with the server. This will trigger
the mobile application to reconnect to the server and resend
initialization message. As a result, the server will restore the
original list of cached services. To prevent this, the server
keeps track of the time when the last message of any type was
received from the client: if this was more than one hour before
the reconnection, the list of cached services is rebuilt, else the
list of cached services remains the same as it was before the
disconnection.
(2) Current-Coordinates Message. These messages contain the
coordinates of the client’s current location. If the Android
application is in the active state, these messages are received
every 3 seconds; if the application is in the passive state, there
are no such messages. The server takes these coordinates and
queries the database to see if the client’s current location is
within any of the cached service areas.
(3) Query-Location Message. One of the functionalities offered
by our framework is to query the current location for
information. For this, a user has to press “Query Current
Location” button in the Android application (Figure 4a). When
the server receives this message, it queries the database for
information services within the area of the user.
(4) Subscribe/Unsubscribe Message. This message contains
the service name and the client’s decision to subscribe or
unsubscribe to it. When the server receives this type of
messages, it performs the action it indicates.
The Mobile Application Server can respond only with one type
of messages, which contain the text to be displayed in the
notification. When the client receives a response from the
server, it pushes a notification to the smartphone display
(Figure 4 b).
E. Mobile Application
In order to take advantage of our framework, users must install
our Android mobile application on their smartphones. This
subsection focuses on two critical aspects of the application
from which Quality of Service (QoS) of our framework
depends: accurate localization and minimization of energy
consumption.
As it was mentioned earlier, accurate localization is critical to
our framework and is more important than minimizing the
energy consumption of the application. This is the reason why
we use the location provider from FusedLocationProviderApi
97
[12]. Details about its benefits are indicated Section II of this
paper.
Figure 4: a) Home screen of the application showing. The message at the
bottom is shown when AP is changed and indicates if the client is
connected to AP which belongs or does not to university. B) Example of
the received notification
The second critical aspect for QoS of our framework is energy
efficiency. If the application drains the smartphone’s battery,
users will be disinclined to use it. To minimize the energy
consumption of our application, we designed it to have two
operational states: passive and active. The idea is to keep low-
energy consumption sensors active all the time (passive state),
and on occurrence of an event of interest, to turn on high-
energy consumption sensors (active state) to collect more
accurate data. In this context, the sensor of interest is the GPS,
due to its high-energy consumption. Unfortunately, new
versions of Android OS, do not allow application developers to
turn on and off this sensor programmatically, so for our
purposes it must be always on. In passive state the energy is
saved only due to the fact that the localization function is not
called.
In Figure 5, the transition to passive state is marked as “Pause”
and the transition to active state is marked as “Resume.” The
application starts, by default, in the passive state. First it
checks if the smartphone has Wi-Fi turned on and if it is
connected to access point (AP); if not, the application listens
for a connection event. If there is an active connection, the
application checks if it is connected to an AP of the university.
Next, the application checks if the client is moving, by
verifying if the AP to which it was connected did not change
during the past 10 minutes. The framework does not use the
change in the client’s coordinates to detect movement. During
testing we noticed that even if the client stays in the same
location, its coordinates may change. Further, if all of the
above conditions are satisfied, the application switches to the
active state and starts sending its coordinates until any of the
checks fails, in which case it switches again to the passive
state.
 IV. EXPERIMENTS AND RESULTS
For our experiments we used a Samsung Galaxy S3
smartphone with Android 4.4.2 and play-services-gcm:8.4.0
and play-services-location:8.4.0. Before conducting our
experiments, the phone was restored to the default factory
settings.
First, we evaluated the application’s energy consumption in the
passive and active states. For this, we used the Power Tutor
Mobile Application [16]. The application used for testing is not
accurate enough to detect changes in energy consumption. This
is due to the fact that GPS consumes much more energy in
comparison with other sensors. As a result, variations in their
energy consumption are not distinguishable. According to data
offered in Google IO presentation, the fused location provider
drains the smartphone battery at a rate of ~7.5%. per hour, in
HIGH_ACCURACY mode [18]. Since almost entire energy
consumption of our mobile application can be attributed to the
fused location provider, we expect the battery to drain at
approximately the same rate.
Start
Send Pause
Is Wi-Fi ON N
N
Y
Resume
N Is Connected
to University AP
N Is Paused
Y
Y are no Wi-Fi connectivity interruptions when the smartphone
Is Paused Y Is Moving N
Figure 5: State Diagram which shows android application logic to save
energy consumption
Next we tested the localization capabilities of our mobile
application for indoor and outdoor environments. The
experiment consisted of walking (three times) on a predefined
path within the University of Alberta campus with the
application turned on. The path was approximately 950 meters
in length. Experimental results are shown in Figure 6. The
green line marks the actual path with the mobile application
connected to AP; the red line is the actual path with the mobile
application disconnected for the AP; the blue dots correspond
to the localization results. As shown in Figure 6, the outdoor
localization is quite accurate, but the indoor localization is not.
Also, for three tests the indoor localization results are very
different. This indicates that the indoor localization is till quite
noisy and requires significant improvement.
An important question that arises in this context is about the
bounds of the localization error. Due to the fact that the
primary source of localization data in indoor and outdoor
environments is different, the corresponding bounds for
localization error are also different. Our experimental results
presented in Figure 6 show that outdoor localization is more
98
accurate than indoor, being close to expected value of 3.5
meters (as indicated in [7]). However, this is not always true.
Sometimes the localization error is significantly bigger than
expected (i.e. blue dot in the third picture of Figure 6, located
in the left side of central area). Such deviations are practically
unpredictable, since they are caused by a combination factors
specific to a particular point in time. For example, errors in
GPS signal delays are caused by ionospheric and tropospheric
phenomena [17]. Further, for the case of indoor environment,
localization, accuracy is worse. According to Google IO
presentation [18], when the fused location provider operates in
HIGH_ACCURACY mode, it offers ~10 meters localization
accuracy. Our experiments show that indoors localization
accuracy is often lower. One such example is demonstrated in
the second picture of Figure 6, where a series of blue dots from
the green area were recorded when the tester was walking
inside of the building in on the green line in the top area of the
picture.
Another observation from experiments is that the smartphone
was disconnected from the university wireless network in
different locations during each test. This fact introduces a
certain degree of randomness (noise) in the QoS of our
framework. In addition, the time it takes to reconnect back to
the network, once disconnected from it, varies. During the
period of time the application is in a passive mode- it is not
sending its coordinates and not receiving services. In fact, even
small interruptions in Wi-Fi connectivity is undesirable, since
while the user is walking and is not connected, services
available in the user’s proximity will not be recognized. There
switches from one AP to another.
Figure 6: Experimental localization results. Blue dots show localization
results, green line shows actual path where the device was connected to
Wi-Fi and the red line, where it was disconnected.
To summarize our experimental results, we have observed that
our framework is functional albeit with several QoS issues,
which imply the need for technical improvements. From a
high-level feasibility perspective, the framework makes
minimal infrastructure assumptions and offers localization
accuracy good enough (services are likely to be offered in
coarse-grained spaces).
However, the indoor localization must be improved and this is
a critical requirement. In the related-work Section, we
indicated a set of potential solutions that can improve indoor-
localization accuracy. Second, one might identify the areas on
campus with poor Wi-Fi connectivity, and prevent the
framework from offering services there. Finally, a method to
turn on and off the GPS programmatically would considerably
improve mobile application’s energy efficiency and make it
more attractive for users.
V. CONCLUSION
In this paper, we presented our framework to offer and
maintain location-based services in smart campus
environments. Our framework offers a complete set of
functionalities, based on the off-the-shelf fused location
provide API, for specifying location-based services and
notifying users when the services are available in their
proximity, relying on an indoor-outdoor localization service.
We conducted a simple feasibility study to validate the
performance of the mobile application and presented the
analysis of our results. We believe that LBS can offer many
benefits due to its location based targeted approach in
detecting client needs and satisfying them. Deployment of such
system in a smart campus environment can unlock a huge
number of potential services especially if it is combined with
the IoT technologies.
REFERENCES
[1] Torres-Sospedra, J., Avariento, J., Rambla, D., Montoliu, R., Casteleyn,
S., Benedito-Bordonau, M., ... & Huerta, J. (2015). Enhancing integrated
indoor/outdoor mobility in a smart campus. International Journal of
Geographical Information Science, 29(11), 1955-1968.
[2] Mohan, P., Padmanabhan, V. N., & Ramjee, R. (2008, November).
Nericell: rich monitoring of road and traffic conditions using mobile
smartphones. In Proceedings of the 6th ACM conference on Embedded
network sensor systems (pp. 323-336). ACM.
[3] Jacob, R., Zheng, J., Ciepłuch, B., Mooney, P., & Winstanley, A. C.
(2009). Campus guidance system for international conferences based on
99
OpenStreetMap. In Web and Wireless Geographical Information Systems
(pp. 187-198). Springer Berlin Heidelberg.
[4] Workman, R., Gschwender, A., & Chan, J. L. (2005). Campus google
map applications. EB/OL.
[5] Si, Z., Zhang, L., & Wang, Y. (2016). Research and Implementation of
Campus Tour System Based on Mobile Terminal. In Advanced Graphic
Communications, Packaging Technology and Materials (pp. 379-385).
Springer Singapore.
[6] Liu, K., Liu, X., & Li, X. (2013, June). Guoguo: Enabling fine-grained
indoor localization via smartphone. In Proceeding of the 11th annual
international conference on Mobile systems, applications, and services
(pp. 235-248). ACM.
[7] “GPS Accuracy”, US National Coordination Office, 20 Mar. 2016. Web.
20 Mar. 2016. Web.
[8] Leppäkoski, H., Collin, J., & Takala, J. (2013). Pedestrian navigation
based on inertial sensors, indoor map, and WLAN signals. Journal of
Signal Processing Systems, 71(3), 287-296.
[9] Waqar, W., Chen, Y., & Vardy, A. (2014, September). Incorporating user
motion information for indoor smartphone positioning in sparse Wi-Fi
environments. In Proceedings of the 17th ACM international conference
on Modeling, analysis and simulation of wireless and mobile systems (pp.
267-274). ACM.
[10] Chen, Z., Zou, H., Jiang, H., Zhu, Q., Soh, Y. C., & Xie, L. (2015).
Fusion of WiFi, smartphone sensors and landmarks using the Kalman
filter for indoor localization. Sensors, 15(1), 715-732.
[11] "PostGIS." — Spatial and Geographic Objects for PostgreSQL. Web. 21
Mar. 2016.
[12] "FusedLocationProviderApi." Google Developers. Web. 21 Mar. 2016.
[13] "OpenStreetMap." OpenStreetMap. Web. 21 Mar. 2016.
[14] "Latest." OpenLayers 3. Web. 21 Mar. 2016.
[15] "PostgreSQL 9.5.1, 9.4.6, 9.3.11, 9.2.15 and 9.1.20 Released!"
PostgreSQL: The World's Most Advanced Open Source Database. Web.
24 Mar. 2016.
[16] "PowerTutor - Android Apps on Google Play." PowerTutor - Android
Apps on Google Play. Web. 25 Mar. 2016
[17] Huang, J. Y., & Tsai, C. H. (2008, July). Improve GPS positioning
accuracy with context awareness. In Ubi-Media Computing, 2008 First
IEEE International Conference on (pp. 94-99). IEEE.
[18] GoogleDevelopers. "Google I/O 2013 - Beyond the Blue Dot: New
Features in Android Location." YouTube. YouTube, 2013. Web. 31 Oct.
2016.