See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/309149090

A smart low-consumption IoT framework for location tracking and its real
application

Conference Paper · June 2016

DOI: 10.1109/ICEIEC.2016.7589744

CITATIONS READS

16 258

3 authors, including:

Kai Lei
Peking University
186 PUBLICATIONS   1,990 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Complex Network Analysis for Communication Network Systems View project

old project View project

All content following this page was uploaded by Kai Lei on 30 December 2018.

The user has requested enhancement of the downloaded file.

 A Smart Low-consumption IoT Framework for
Location Tracking and Its Real Application

Hao Tang, Jian Shi and Kai Lei

Shenzhen Key Lab for Cloud Computing Technology & Applications (SPCCTA)
Peking University Shenzhen Graduate School
Shenzhen, Guangdong, 518055, China
[email protected]

Abstract—Location-based services are increasingly popular. screen due to power and portability consideration. Device
Smart devices embedded with GPS receiver are widely used in control relays on the server and app. A server side system is
vehicle tracking, law enforcement and person monitoring. To implemented to collect data and validate control command. We
provide real-time data collecting and analyzing, a backend server also build a mobile app to access data, display location on a
is necessary. A mobile app can work as a user client for accessing map and control device remotely. Specifically, we integrate a
location data and remote control. In this paper, we describe the walking stick with our tracking device. This walking stick is a
design and implementation of a system providing real-time real-world product for elderly people. Their family members
positioning and tracking service. Our system consists of three can locate and monitor their locations with our app.
parts: tracking device, backend server and mobile app. Our
tracking device integrates GPS module, GSM/GPRS module and This paper focus on the design and working process of the
TCP/IP stack, capable of generating location data, establishing whole framework. In Section II, we present some related works
TCP connection and receiving SMS. Location data are on location tracking system. In Section III, we give a detail
transmitted over TCP connection from device to our backend description of the whole system, including tracking device,
server. The server is responsible for collecting and storing data. backend server, and mobile app. Section IV presents some
The server also provides an HTTP-based RESTful API for optimization that can be applied to our system.
mobile app and web service. A mobile app is built for displaying
data and controlling device remotely. Data accessing is via calling
REST API and remote control is sent to device by SMS. Our II. RELATED WORK
device is compact in volume, accurate in positioning, and long in Currently all tracking systems can be classified into two
battery life. Our device has been integrated in a walking stick as categories, beacon-based system and GPS based system.
a real-world product. Beacon-based tracking system requires a large amount of
beacons attached to different areas to provide a unique
Keywords-IoT framework; location tracking; remote control;
identification for this local area. Indoor positioning is the most
LBS
suitable scenario of this technology. However, this technology
will not be widely accepted in near future because of the
I. INTRODUCTION challenge in deployment. Another category is GPS based
With the development of wireless technology and Internet tracking system. Global positioning system (GPS) is the most
of Things, smart devices are more popular in our daily life than mature and widely used technology in positioning and location
ever before. We use these devices recording our daily life, tracking. GPS receivers are widely embedded in cellphones,
monitoring personal status, and tracking objects. Cloud watches, and a various kinds of embedded devices. These
services are commonly integrated with these devices for data devices receive wireless signals from at least four GPS
collection, storage and analysis. Mobile apps are also provided satellites, and calculate positioning data using a triangulation
as the most popular interaction interface to the device. technique. Smart phone is the most popular device, and almost
every smart phone equips the GPS module. Previous works
Location tracking devices are the most commonly used [1][2][3] have been done on using general devices to
devices. These devices are embedded GPS receiver, capable of coordinate with GPS, Wi-Fi and Cell-Id to provide hybrid
generating location data. These devices are favored in vehicle positioning. However, general devices are expensive,
tracking, law enforcement and differently abled people cumbersome and power consuming. A specialized positioning
monitoring. device should be small, cheap, and low-consumption. In
In this paper, we propose a location tracking framework, addition, a tracking system should also contains a backend
composed of a tracking device, a backend server, and a mobile server for real-time data collection. A mobile app is also
app. The tracking device embedded with GPS receiver can required for data display and interaction. Considering these
generate location data in real time. This device integrated with requirements, we design a low-consumption IoT framework for
TCP/IP stack is capable of accessing Internet and uploading location tracking and implement a system for walking sticks as
location data. The device is not equipped with keyboard or a real-world application on the basis of the framework.

978-1-5090-1997-7/16/$31.00 ©2016 IEEE

306
 III. SYSTEM DESIGN AND IMPLEMENTATION Our device will generate and upload location data
Our tracking system is composed of a tracking device, a periodically. Location message transmitted over TCP is a
backend server and a mobile app. The whole system is client- sequence of ASCII characters, ending with CRLF for framing.
server model, as illustrated in Fig. 1. The device embeds with a Each message is composed of several fields. Below is an
GPS/GSM/GPRS module, capable of receiving GPS signals, example of the location message.
sending and receiving SMS, establishing TCP connection over “1,862609000062567,160323031858,11356.3367E,2232.9
GPRS. The device generates location data at a set interval. 371N,060,0460,0000,2623,0e09,98\r\n”.
These location data and other information i.e. device battery
information and timestamps will be uploaded to the server over Structure of this location message is illustrated in Table I.
TCP connection. Server will collect and store these data. Server Each location message is uniquely identified by the
also provides a RESTful API for mobile app. Command sent combination of IMEI and timestamps. IMEI is the unique
from mobile app to device will also be validated by the server. identifier of a tracking device. Location area code (LAC) and
Mobile app acquires data from server over HTTP requests, GSM cell id (CID) are used for an auxiliary positioning method.
sending SMS to control device remotely and calling API When GPS signals are not available, these two fields together
provided by server. Control command includes changing with mobile country code (MCC), mobile network code (MNC)
device’s frequency of uploading location data, and requesting and received signal strength indicator (RSSI) are used for
location data via SMS, etc. estimating position at a lower accuracy.

TABLE I. STRUCTURE OF A LOCATION MESSAGE

Backend Server Field Description

GPS Satellite
Data Storage Privilege Management
1 Message type code
Data Collector RESTful API
872501000030793 IMEI

HTTP 1463468426 Unix timestamp

TCP
113.563367E Longitude

SMS
22.329371N Latitude

060 Battery status

GPS Device Mobile App
0460 MCC

0000 MNC

Figure 1. Architecture of location tracking system 2623 LAC

0e09 CID
A. Tracking Device
98 RSSI
Our tracking device integrates SIM808 cellular module [4].
GSM/GPRS and GPS are integrated in a SMT package.
TCP/IP stack is also integrated in this SIM808 module. Commands from mobile app are sent directly to device via
WT51F516 [5] works as a microcontroller. Fig. 2 is a walking SMS. To prevent faking SMS from malicious users, our
stick equipped with our device. Screen and keyboard are not devices will query server for the validity of the SMS’ incoming
equipped for minimizing size and power consumption. number. The structure of query message is illustrated in table II.
Here is an example of query message.
“2, 872501000030793,13800000000,1,1,30\r\n”.

TABLE II. STRUCTURE OF A QUERY MESSAGE

Field Description

2 Message type code

872501000030793 IMEI

13800000000 Incoming number of SMS

1 Command code

1 Number of parameters

30 Parameter

Figure 2. A smart walking stick equipped with our device

307
 In the example message, message type code “2” refers to a Servers also provide a RESTful API for mobile app and
query message. Command code “1” refers to the command of web service. RESTful is an architecture style for building
altering the frequency of uploading data. This message applications. RESTful API is the most popular interface using
indicates that a command from 13800000000 requiring device HTTP requests to GET, POST, PUT and DELETE data from
872501000030793 to change its uploading interval to 30 server. Accessing location data is by sending a GET request to
minutes. the following URL: /device/{IMEI}/location. Optional
parameters are shown in Table III. Below is a full URL to
B. Server Side System request data.
Our backend server will collect location data, store these “/device/872501000030793/location?before=1463469426&
data for accessing and further analyzing. Fig. 3 displays the after=1463468426&type=b”
history position of a walking stick.
TABLE III. OPTIONAL PARAMETERS

Query parameter Description

Before=1463469426 Location data before 1463469426

After=1463468426 Location data after 1463468426

Type=g Source of location data

A GET request to the above URL means retrieving the

location data between 1463468426 and 1463469426 from
device whose IMEI is 872501000030793, and location data
source should be GPS instead of estimating from cell tower.
Server is in also charge of command validating and
permission management, only commands from authorized
numbers will be validated by the server and executed by a
device. We will describe this process in the app part.
When server system is implemented, MySQL [7] is used
for data persistence. To speed up data access, location data sent
in the last 24 hours will be cached in Redis [8]. Twisted [9] is
used on the server side to support network communications
including TCP and HTTP.

C. Mobile App
A mobile app is built for accessing location data, displaying
track on a map and controlling devices remotely via SMS and
server side API. Map related service is provided by [6]. In the
following part, we will omit the implementation detail of
mobile app and describe the process of remote control
specifically.
Remote control is accomplished on mobile app by sending
SMS and calling server side API. Control process is illustrated
Figure 3. History location tracking in Fig. 4. First, before sending command to device, the app
should first inform the server of the operation. If the source of
Upon receiving a location message, server will first check
command has been authorized, the server will replay with an
whether location data in this message is valid. If the longitude
acknowledgement and record the operation for the validation in
field or latitude field in location message from device is null,
Step 5. After accepting acknowledgement from server, app will
server will estimate device location via beacon-based station
send command in SMS to device. Meanwhile, app will inquire
positioning. By tracking the location of the nearest cell tower
the server for the operation result. On device side, upon
from location area code, GSM cell id, and calculating the
receiving an SMS, device will connect to server and validate
distance to the cell tower from RSSI, server can estimated the
the incoming number of the SMS. If this command passes
device location. In our system, server directly use the tracker
validation, the device will execute the command and then
API provided by Amap [6] instead of calculating from scratch.
inform the server of the operation result, which will be returned
These location data will be marked to indicate their lower
to app in Step 9. If command fails in validation, it will be
accuracy before storing.
dropped by device. If a timeout occurs in Step 4, either because

308
the device cannot access Internet, or due to the latency of SMS, encrypting and decrypting the formal encryption key. The first
app will be acknowledged about the error. time device connecting to server, an encryption key is
generated on server side. This key is encrypted by the one-off
app device server default key and then transmitted in cipher text to device.
Device will retrieve this encryption key by decrypting cipher
text with its one-off default key, and replace the default key
1. inform server with this new one. After this, every location message sent from
2. acknowledge device is encrypted by this new key. Expiration date can be set
3. command(SMS) for this new encryption key.
4. inquire result
REFERENCES
5. query validity
6. authorized [1] U. Bareth and A. Kupper, "Energy-Efficient Position Tracking in
Proactive Location-Based Services for Smartphone Environments,"
2011 IEEE 35th Annual Computer Software and Applications
7. execute command
Conference, Munich, 2011, pp. 516-521..
[2] Y. Ozen, O. Ozdemir and N. Bandirmali, "Android based energy aware
8. inform result
real-time location tracking system," 2015 Seventh International
9. return result Conference on Ubiquitous and Future Networks, Sapporo, 2015, pp.
842-844.
[3] P. A. Shinde and Y. B. Mane, "Advanced vehicle monitoring and
tracking system based on Raspberry Pi," Intelligent Systems and Control
(ISCO), 2015 IEEE 9th International Conference on, Coimbatore, 2015,
Figure 4. Scequence diagram of remote control
pp. 1-6.
[4] Simcom. [Online]. Available: http://simcom.ee/modules/gsm-gprs-
gnss/sim808/. [Accessed: 19- May- 2016]
IV. DISCUSSION AND FUTURE WORK
[5] Weltrend, “WT51F518”, [Online]. http://www.weltrend.com/en-
Several optimization can be applied to our system. First, we global/product/detail/66/89/307. [Accessed: 19- May- 2016]
assume that GPRS are always available and all location data [6] Gaode Maps, “Gaode open platform for developer”. [Online].
are transmitted over GPRS. However, this is not always true. http://lbs.amap.com/. [Accessed: 19- May- 2016]
When devices are not able to access Internet, location data can [7] MySQL. [Online]. http://www.mysql.com/. [Accessed: 19- May- 2016]
be transmitted through SMS. App first requests location via [8] Redis. [Online]. http://redis.io/. [Accessed: 19- May- 2016]
SMS, then device replies with its current position. To prevent [9] Twisted Matrix Labs. [Online]. http://twistedmatrix.com/trac/.
from replying data to an unauthorized user, device should only [Accessed: 19- May- 2016]
answer incoming SMS from an authorized number. Since
GPRS network is not available, authorized number should be
stored in device’s memory in advance. The process of setting
authorized number to device can be the same process as
described in Fig. 4 when GPRS is available.
Another concern is the fee of SMS. Sending SMS for every
control command can be uneconomical. Using TCP connection
to send command message can significantly lower the cost. In
our original design, device will close TCP connection after
sending location data to server. Therefore, the server cannot
send any message to device once the connection is closed. The
key to this problem is using heartbeat technique to keep the
connection alive after a TCP connection has been established
from device to the server. Device should send signals regularly
to keep connection alive, preventing underlying network
infrastructure from reclaiming idle resources. These signals can
be either location data, which provides real-time tracking, or
just whitespaces, keeping GPS module sleep and minimizing
battery consumption. The option varies case by case.
At last, we will discuss security issues. Location messages
from device to server are transmitted in clear text. We allow
this because we consider that GPRS sniffing is difficult to
implement and rare in practice. If security is a serious concern,
symmetrical encryption can be adopted to achieve a balance
between security and simplicity. Symmetric key is distributed
in the following way. Every device can pre-store a one-off
symmetrical key as its default key, which is shared between
device and server in advance. This one-off key is used for

309

View publication stats