2015 5th International Conference on the Internet of Things (IoT)
Optimizations for RFID-based IoT applications on
the Cloud
Hoang Minh Nguyen, Seong Hoon Kim, Dinh Tuan Le, Sehyeon Heo, Janggwan Im, Daeyoung Kim
Department of Computer Science
Korea Advanced Institute of Science and Technology
Daejeon 305-701, South Korea
Emails: {minhhoang,shkim08,ldtuan,crux042,limg00n,kimd}@kaist.ac.kr
Abstract—Internet of Things (IoT) has received a lot of
attentions recently as a network of virtual representations of
physical objects using technologies like radio-frequency identi-
fication (RFID) to identify and tracking objects’ tags. While
some research work has attempted to deliver IoT applications
into the real-world, a scalable deployment has not yet been seen.
Therefore, by utilizing Cloud technology as a well-proven way
of real-world deployment for thousands of vendors, we propose
our Cloud solution with optimizations for scalable RFID-based
IoT applications deployment. In this paper, we first outline
the challenges of deployment of RFID-based IoT applications,
then our Cloud solution with load prediction and migration
management optimizations is proposed. For our experiments,
various results including prediction accuracy, migration delay
and load balancing performance are presented.
Keywords—IoT, RFID, Cloud optimizations, load balancing
I. I NTRODUCTION
Radio Frequency Identification (RFID) and Electronic
Product Code (EPC) have been among key technologies in
enabling Kevin Ashton’s vision of ’Internet of Things’ (IoT)
[1]. EPC is stored on a RFID tag as a universal identifier to
provide a unique identity for any physical object anywhere at
anytime. RFID tags are made of a silicon chip and an antenna,
which uses radio waves for faster and more efficient read of
product information compared to the traditional bar codes.
Their many applications range across various industry sectors,
including traceability and food safety in retail, enhanced pa-
tient safety and supply chain efficiencies in health care, and
improved efficiency and increased visibility of the flow of
shipments, more efficient handling and inventory management,
and increased security of distribution and speed of operations
in transport and logistics [2].
To support the development and implementation of both
EPC and RFID technologies, EPCglobal presents a suite of
industry-driven standards, namely EPCglobal Network (EPC
Network). The deployment of such standards for RFID appli-
cations, although well-designed and already employed for large
enterprises, usually exceeds the capability of small to mid-
size businesses due to their complexity and cost-intensiveness.
To address this challenge, Guinard et al. has identified three
major pain points, namely ’Complex and Expensive Back-
end Deployment and Maintenance’, ’Complicated Applications
Developments’, and ’Tedious Business Case Modeling and
Cross-IoT Systems Integration’ [3].
Various research works have deployed building-scale RFID
applications, at the same time proving Cloud platforms to be
978-1-4673-8058-4/15/$31.00 ©2015 IEEE
Authorized licensed use limited to: Corporacion Universitaria de la Costa. Downloaded on March 19,2021 at 04:43:26 UTC from IEEE Xplore. Restrictions apply.
a suitable approach for read-world deployments. This includes
combination of Cloud Computing, REST and Mashups in [3],
an RFID Ecosystem deployed within a building [4], a building-
wide EPC Gen 2 UHF RFID deployment in [5]. However,
scalability of such approaches still remain an issue, as the
number of RFID readers is increasing rapidly in the IoT
field. Thus, in this paper, we provide optimizations for RFID
applications deployments, especially back-end deployment and
maintenance, using Cloud computing.
For any RFID applications deployments on the Cloud,
an important component would be the ’flows’ of RFID tags
between RFID readers and their applications. To optimize
the performance of such application deployments, these flows
present several challenges, in particular:
• Flows are defined as a stream of tags coming from
RFID readers; these flows are created when tags are
detected in the vicinity of a reader’s antenna and sent
to clients (e.g., Application Level Event (ALE))[6].
However, the exact capacity and timing of each flow
in a Read Cycle of readers are unknown, thus caus-
ing fluctuations in loads at ALE VMs. This reason,
coupled with inherent load fluctuations, generate high
irregularities inside Cloud’s VMs.
• Overloading VM situations require migrations of flows
from one VM to another; thus, we develop a way
to perform such migrations. In addition, a strategy is
needed for migration management, including, when,
where, and what to migrate.
Thus, our target of this paper is load balancing through
flows migration for ALE VMs; our architecture is designed
with two main components taking care of two major steps:
• Load Predictor predicts future loads from historical
VMs’ load values. In addition with migration delay
effect prediction, this is designed for the Cloud system
to know VMs’ future loads as well as their stabiliza-
tion time after migration.
• Migration Manager decides whether to make flow
migrations for any overloading VMs based upon Load
Predictor’s prediction results. These migrations are
performed using our own flow-redirection technique.
To prove the feasibility of our approach, we have built
a system consisted of components taken from EPC Network
80
 2015 5th International Conference on the Internet of Things (IoT)
software stack, including RFID readers implemented in em-
ulators and LLRP interface. The system utilizes CloudStack
management software as it is one of the most matured open-
source Cloud solution with flexible environment for our setup.
The CloudStack VMs are used to run ALE, which function
as RFID readers’ clients to generate required flows for our
experiments. Our evaluation is performed for three key as-
pects, including load prediction accuracy, migration delay, and
overall load balancing performance.
The remainder of the paper is organized as follows. Section
II outlines the related works to this paper. Section III provides
the necessary background information for understanding of the
paper. Then the challenges of RFID application deployments
on Cloud and our proposed solution are explained in Section
IV. Our load and migration delay effect prediction approach is
explained in Section V, and our migration strategy is shown in
Section VI. Experimental results and discussion are provided
in Section VII. Finally, concluding remarks are presented in
Section VIII which emphasizes the scientific contributions of
this research.
II. R ELATED W ORKS
In [7], Rimal et al. provides a taxonomy and survey of
Cloud Computing systems based on the concept of massive
data processing distributed systems. They focus on comparing
different world-wide Cloud Computing services’ features and
identifying their key research challenges. Limitations of Cloud
Computing are further elaborated by Hofman et al.[8]. They
point out the tradeoffs enterprises need to make in order to
adopt the utility computing provided by the Cloud, which
emerge or are magnified in Cloud due to the infrastructure con-
trol change from enterprises to service providers. Furthermore,
moving into the Cloud can bring about serious challenges such
as integration cost and performance issue for applications not
originally designed for Cloud adoption [9].
There have been researches in RFID applications deploy-
ments on the Cloud [3], [10], [11]. Guinard et al. [3] discusses
how Cloud Computing, RESTful interfaces, Real-time Web
and Web 2.0 Mashups can simplify application development,
deployments and maintenance in a common RFID application.
Although this research works with RFID/EPC Network and
contributes to reductions in complexity and costs of deploy-
ments, they focus mainly on Cloud functionalities without
considerations on improving the functionality between RFID
readers and their clients. In [10], a cube model for data
processing is presented to remove data redundancies and data
noises; wherein Cloud computing is employed for necessary
computing power. In [11], a hybrid building fire evacuation
system (HBFES) is designed on a mobile phone using RFID
techniques and Cloud Computing. While these two researches
contribute to deployment of RFID applications on the Cloud,
they only utilize Cloud systems without trying to improve the
performance of such applications.
A lot of researches have worked on load prediction in
computing systems, more recently Cloud computing systems
[12], [13], [14], [15]. Gong et al. [12] presents a scheme which
consists of signature-driven and state-driven resource demand
prediction to deal with application resources scaling conflicts.
Their solution, PRESS, first uses signal processing techniques
81
Authorized licensed use limited to: Corporacion Universitaria de la Costa. Downloaded on March 19,2021 at 04:43:26 UTC from IEEE Xplore. Restrictions apply.
and Fast Fourier Transform (FFT) to select the ’pattern’
from the workload historical data. For applications without
repeating patterns, they employ a discrete-time Markov chain
to predict short-term future values. Dinda et al. [13] perform a
comprehensive set of experiments to compare between various
linear models and point out the performance advantage of Auto
Regression model at order 16 (AR(16)). In [14] and [15], load
prediction is achieved through a two-step strategy consisting
of load tracker, which ’smooths out’ the work-load historical
data to avoid noises and show the workload’s actual trend,
and load prediction, which predicts future values based on the
load tracker values. The strategy is shown to work well in real
time, as simple linear models can be used for both load tracker
and prediction. Although the above researches have significant
contributions in improving the accuracy in predicting load
prediction values, they have a big limitation of requiring
sufficient past load values data (i.e. a training phase). Since our
approach of flow-based migration scheme consists of gradually
migrating flows out of VMs in consecutive short intervals
which provides limited amount of data between intervals, the
above approaches are thus not suitable for our system.
Cloud computing researches have also seen a lot of works
about migration algorithms and techniques. This ranges from
evaluation of live VM migration effect on application per-
formance [16], survey of many Cloud Computing state-of-
the-art technologies and challenges including VM migration
[17] to different techniques of VM migrations including VM
cloning [18], black-box and gray-box strategies [19], and
dynamic resource scaling [20]. These researches have largely
concentrated on live VM migrations between hosts in order to
solve overloading situations in physical machines; however,
load balancing within VMs have not yet been considered.
While live VM migration can be effectively utilized to reduce
the load inside a host; this technique cannot be used to
reduce the load inside a VM. Furthermore, in our work, we
aim to provide a migration strategy that also considers RFID
applications’ properties, in order to perform load balancing for
ALE VMs.
Analyzing the contemplated related works, we intend to
bridge the gap presented in previous works: developing an
optimized strategy to bring RFID applications, in this case
EPC Network, into the Cloud. In this regard, we present
a comprehensive solution to a set of challenges presented
in RFID applications and demonstrate its effectiveness in a
Cloud-based system dealing with RFID readers and LLRP
interface, two major components directly involved with the
stated challenges.
III. BACKGROUND
This section provides the background information on EPC
Network and CloudStack architectures, which are necessary in
understanding our architecture design and experiments.
A. EPC Network
Electronic Product Code (EPC) Network architecture’s
components are included in Figure 1, which consists of
Reader Device, Filtering and Collection, EPCIS, and ONS.
Enterprise applications communicate with EPC Network’s
components through proper interface (ONS, Query, Capture,
 2015 5th International Conference on the Internet of Things (IoT)
ALE, RM/LLRP) to get desired information into their systems
(Capturing Application, Internal Database).
ONS
ONS Interface
(Object Naming Services)
Static pointer to EPCIS
Query Interface
manufacturer’s Discovery Services
EPCIS
Dynamic
Registration
Pointer
Query Callback
EPC Event Data
EPC Information Services (EPCIS) Repository
Query Control
Capture Interface
Filtering and Collection Logical Reader
LLRP
Reader Device Physical Reader
Air Interface
Transponder
Fig. 1. EPC Network Architecture Overview
The Object Naming Service (ONS), EPCIS Discovery
Service, and EPC Information Services (EPCIS) are the upper
components of EPC Network that deal with EPC data location
and storage. While the ONS and the EPCIS Discovery Service
are used to identify the distributed data for product tracing, EP-
CIS’ role is to provide a repository for EPC event and master
data [21]. The Filtering and Collection Component and Reader
Device are EPC Network components that work directly with
raw tag data; they are the more focused components of this
paper’s experiments and are explained below.
Reader device communicates with tag data through an
air interface protocol, and the control of this air protocol is
provided by the Low-Level Reader Protocol (LLRP), which
is an interface between Reader Device and its client, in this
case Logical Reader inside Application Level Events (ALE).
ALE events can be accessed through an ALE interface, and
reader control for accessing applications is provided by LLRP
and Reader Management (RM) protocol. Also, the standards
for ALE is general enough to support various types of carriers
including RFID tags, bar codes, and keyboard inputs.
B. CloudStack Cloud Infrastructure
Apache CloudStack [22] was chosen as our Cloud manage-
ment software because of its maturity with good open-source
community support. Designed as a highly available, highly
scalable Infrastructure as a Service (IaaS) Cloud computing
platform, it has already been used by many researchers, end-
users and enterprises. In our experiments, CloudStack version
4.4.1 was used; its architecture is depicted in Figure 2.
CloudStack is a scalable, multi-tenant, open-source,
purpose-built, Cloud orchestration platform for delivering
turnkey Infrastructure-as-a-Service (IaaS) Clouds. CloudStack
architecture can be divided into management units of Host,
Cluster, Pod, Zone, Region. Host is a basic unit of scale, which
runs on a hypervisor or is bare metal. A cluster consists of one
Authorized licensed use limited to: Corporacion Universitaria de la Costa. Downloaded on March 19,2021 at 04:43:26 UTC from IEEE Xplore. Restrictions apply.
Region
Interface
Management Secondary Zone
Console Proxy
Server Storage
g
System VM
Enterprise
applications Po
Pod
Secondary Storage
System VM Cluster
ter
Hostt
IInstantiated
nstantiated Primary
mary
VMs Storage
g
Virtual Router
System VM
EPCIS
Capturing Fig. 2. Overview of CloudStack Architecture
Application
ALE
or more hosts of same hypervisor type; all hosts in a cluster
have access to shared (primary) storage. A pod consists of one
RM/LLRP or more clusters; usually with a L2 switch. A zone consists of
one or more pods; a zone has access to secondary storage. A
region consists of one or more zones. While primary storage
stores the disk volumes for all the VMs running on hosts in a
cluster; secondary storage stores templates, ISO images, and
disk volume snapshots.
Among the VMs resided in hosts, there are three system
VM: Console Proxy, Secondary Storage, and Virtual Router;
all three of them are associated with a Zone. The console
proxy VM presents a console view to guest VMs via the web
UI, the secondary storage VM takes care of secondary storage
activities including templates downloading, templates copying,
and snapshot backups, and the virtual router VM takes care
of network activities for a guest network inside a zone. In
our experiments, we take advantage of this virtual router to
perform our load migration strategy.
IV. C HALLENGES & P ROPOSED S OLUTION
A. Challenges of RFID application deployments
1) Load fluctuations from unknown number of incoming
tags: Readers are equipped with antennas and tags are detected
when they pass in the vicinity of an antenna. This creates
a stream of tags coming from readers, namely ’flow’ in this
paper. These flows are then reported to clients (i.e., Application
Level Event (ALE)[6]) located in the Cloud’s VMs through
the Low Level Reader Protocol (LLRP)[6] interface after each
period of time, called Read Cycle, has passed. The exact
number of tags from each flow in the upcoming Read Cycle
is unknown, thus high load fluctuations in VMs at the Cloud
system is usually observed.
This reason, together with the already presented fluctua-
tions in VMs’ loads, contribute to a lot of ups and downs in
load values in the Cloud system. One example of this is shown
in Fig. 3, whereas the load values inside VMs fluctuates a lot
even with the number of readers kept constant at 300.
2) Load migration for flows from RFID readers: When
VMs experience overloads, some flows should be migrated
to send tags to other VMs; however, two challenges are
presented to support this migration procedure. Firstly, since
flows have TCP connections, employing direct TCP-based
migrations would introduce overhead as well as changes to
82
 2015 5th International Conference on the Internet of Things (IoT)

100
Controller Prediction Migration
90
Results Decision
80 Load Migration
70 Migration List
Predictor Manager
CPU load value

60
50 Load Migration
40 Statistics Information
30
CloudStack Management Software
20
10 Control
0
CloudStack Hosts
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
113
120
127
134
141
148
155
162
169
176
183
190
197
Number of intervals Host 1 Host 2 Host n

Fig. 3. Load Fluctuations, 300 readers, 1 interval = 5 seconds

ALE VM

ALE VM

ALE VM

ALE VM

ALE VM

ALE VM
TCP state machines. When the number of flows needed to
be migrated gets larger, ranging from hundreds to thousands
of flows, the overhead will become undesirable. Secondly, an XenServer XenServer XenServer
efficient strategy is needed for effective migration performance Hypervisor Hypervisor Hypervisor
inside the Cloud systems, including when, where, and what to
migrate.
Flow

B. Proposed Solution RFID Readers

In order to solve the above challenges, we have designed

a system that focuses on load balancing optimizations for
RFID application deployments on Cloud. To achieve desired
load balancing effect, we perform load prediction and flows
migration among VMs, with 3 main groups of components,
including the Controller, CloudStack Management Software &
Hosts, and RFID Readers. Multiple RFID readers, which are
emulators in our experiments, send tags to CloudStack hosts
running on top of XenServer hypervisor. In these hosts are
ALE VMs running on Linux OS, which acts as clients that
receive flows from RFID readers. Our system architecture can
be seen in Fig. 4.
In order to perform load balancing through prediction
and migration management, the system needs to be able to
obtain computing resources from VMs. In our experiments, the
system is designed to focus on CPU load statistics; although
it is designed to work with any types of computing resources.
Also, even though CloudStack supports users with API to
collect load statistics; it has significant delays for high rate of
requests (e.g. when trying to collect load statistics every few
seconds). Thus, our system is instead designed to collect load
statistics from the /proc/stat file in each VM; these statistics
are then forwarded to the Controller for migration decision
making.
The Controller of our system serves two main purposes:
load prediction and migration management. These are taken
care of by two main components inside the system, load
predictor and migration manager, respectively. The load pre-
dictor takes inputs, which are historical load statistics, from
VMs inside CloudStack hosts, in order to provide outputs of
future resource demands prediction. These prediction results
are utilized by the migration manager to decide whether a
VM is being overloaded or not, to perform flow migrations
if necessary. A migration list is made in case migrations
need to be performed; this list is executed by the CloudStack
management software by taking advantage of CloudStack
Virtual Router.
Fig. 4. Our System Architecture
V. L OAD P REDICTOR
A. Load Prediction
In order to make correct migration and load balancing
decisions, it is necessary to be able to predict the future
resource needs of VMs inside the system. Since our approach
aims to provide optimizations without modifications to both
VMs and readers, we have developed our load prediction
scheme using past resources utilization statistics inside VMs.
For a prediction algorithm based on past statistics to per-
form well, strong correlation between past and future statistics
is necessary. In our system, this correlation depends on flows
received from RFID readers, including the number of flows
and the number of tags from each flow during each observed
interval. As a result, whenever a group of flows is migrated
out of a VM, this correlation relation is weakened; thus, in
our system, those statistics are considered outdated and no
longer used for prediction. As our migration strategy consists
of gradually migrating flows out of VMs, this means only
limited amount of statistics is available between consecutive
migrations; therefore, prediction algorithms that require a
training phase (i.e. Linear Autoregression) would not be a good
choice.
Taken the above factors into account, we decide to take ad-
vantage of the exponential moving average (EMA) algorithm:
EM A(t) = α ∗ EM A(t − 1) + (1 − α) ∗ O(t)
= O(t) + α ∗ (EM A(t − 1) − O(t)

83

Authorized licensed use limited to: Corporacion Universitaria de la Costa. Downloaded on March 19,2021 at 04:43:26 UTC from IEEE Xplore. Restrictions apply.
 2015 5th International Conference on the Internet of Things (IoT)

where: (Fig. 6). Each flow’s event cycle is tracked in order to predict
this delay inside each VM.
EM A(t) : the exponential moving average value at time t
O(t) : the observed load value at time t
Migration Effect
α : the smoothing factor
100 Migration Point
90
EMA is chosen for its ability to smooth the load; however, 80
70

CPU Usage (%)

using the same α for all observed load values would provide 60
Delay
the same smoothing effects for both increasing and decreasing 50
load values. This would not be desirable for our flow-based 40
30
solution because of the differences between increasing and
20
decreasing load situations. (i) When load values increase 10
because of new incoming flows or increasing number of tags 0
0 10 20 30 40 50 60 70 80 90 100
to be processed, the system can experience fast load increases
Number of Intervals
in consecutive observed durations. While in case of decreasing
load values because of migrated group of flows, it would be
better to give the system enough time to adjust before the Fig. 5. Example of Delay Effect
next migration. (ii) Overloading situations are usually more
expensive than underloading ones because of violations of
Service Level Objectives (SLOs). Tags Stream

With the above reasoning, together with careful considera- Event Cycle Event Cycle
tions of a previous research work [23] that allows for negative
Tags Tags Tags
value of α, we come up with a modified smoothing value,
namely ”adaptive Exponential Moving Average”. This is de- Migration Point
signed to be able to ”adapt” to different cases of increasing and Tags Reported Tags Reported Tags Reported
decreasing load values. In other words, the smoothing factors
”accelerates” for increasing load values, and ”decelerates” for Fig. 6. Delay Effect after Migration
decreasing load values, thus the name of ”adaptive EMA”.

α = ( O(t)−E(t−1)
100 − 1) ∗ i for increasing load values
and
E(t−1)−O(t)
α = (1 − 100 ) ∗ d for decreasing load values
where:
i : increasing smoothing factor
d : decreasing smoothing factor
B. Prediction of Delays after Migrations
In our flow-based system, whenever a migration is per-
formed, an amount of time is needed for the VM’s load to
stabilize; an example of this behavior is shown in Fig. 5. As
can be seen from the figure, load remains at high level even
after a migration has already been finished; only until after
some time that the load finally settles down and exhibit its
normal behavior.
The reason for this delay effect can be explained in
Fig. 6. Tags are continuously read into RFID readers from
outside world objects. However, these tags are not immediately
reported from RFID readers to their clients (ALE VM) once
they are read. Instead, tags are reported after regular time line
configuration called ”event cycle” inside RFID readers. This,
in turn, causes the load inside the VM to remain at high level
for a longer amount of time even after migration has been
performed (in other words, a ”delay” is experienced).
Thus, in our system, the delay time is calculate to be from
the moment a migration happens until the next event cycle
VI. M IGRATION M ANAGER
A. Migration Technique
In our system, to reduce load level when necessary, flows
should be migrated from one VM to another; this procedure
is different from live VM migration. Also, migrating flows is
not straightforward, as connections from RFID readers to their
clients are TCP-based; direct migrations would, as a result,
cause high overhead as well as TCP state machines changes
[24]. So, instead of direct migrations, we apply a redirection-
based migration technique to migrate connection out of a VM
whenever necessary (Fig. 7).The connection between a RFID
reader and an ALE VM can be redirected using iptables chain
manipulation of sockets (each consisting of an IP address and
a port number). Although this approach introduces delay for
migrated flows establishment; the delay is shown to be small
in our experimental evaluation.
In our system, we take advantage of CloudStack Virtual
Router to perform our redirection-based flow migration ap-
proach. Rules in iptables-like chains inside the Virtual Router
are sequentially traversed to process and send the packets to
the correct destination VM. A flow of tags is considered to be
the smallest migration unit in our system.
B. Migration Decision
To properly perform flow migrations for VMs, our system
needs to be able to solve three essential issues, including which
flows to migrate, when to migrate, and where to migrate them.
• Flows to migrate: it is necessary to calculate the
amount of CPU the migrated flows would take inside

84

Authorized licensed use limited to: Corporacion Universitaria de la Costa. Downloaded on March 19,2021 at 04:43:26 UTC from IEEE Xplore. Restrictions apply.

Source Socket
Flow
CloudStack Virtual Router
Redirection
ALE VM
ALE VM
ALE VM
ALE VM
Host
Destination Socket
Fig. 7. Migration Technique
the destination VM. While this information would
allow the system to correctly decide the group of flows
to migrate, it is not straightforward to calculate this
CPU consumption. Instead, we estimate by using the
ratio of migrated tags to total tags with the source
VM’s load value:
migratedT ags
CP U (f ) = ∗ CP U (V M ) (1)
totalT ags
• Migration Time: the system will perform flow mi-
grations once an overloading situation is detected. A
VM is defined to be in overloading situation if the
resources utilization (e.g. CPU, memory) exceeds a
predefined threshold for a predefined amount of time.
Also, flow migrations are carried out only if the source
VM currently has no migration delay effect.
• Migration Destination: in our system, the destination
VM is chosen to be the VM with the highest load value
that can receive the migrated flows of tags without
turning into an overloading VM itself.
migratedT ags
CP U (f ) = ∗ CP U (V M )
totalT ags
An important property to note is that we employ a gradual
flow-based approach in our system; which means flows are
migrated gradually (using the above load consumption estima-
tion) in groups until the VM gets out of overloading situation.
Together with our consideration of migration delay effect, this
would avoid the errors cause by load consumption estimation
(as this is only an estimation and cannot be totally correct all
the time). As a migration is performed only after the source
VM’s resource utilization has stabilized, there are no ’errors
stacking’ of consecutive load consumption estimation for flow
migrations.
VII. P ERFORMANCE E VALUATION
A. Experimental Setup
Our experimental setup specifications can be seen in Table
I. As stated earlier in this paper, we employ RFID readers
and ALE, two key components of EPC Network, for our
experiments. RFID readers are run using emulators written in
C++, inside Ubuntu 12.04 OS. ALE is setup inside CloudStack
Authorized licensed use limited to: Corporacion Universitaria de la Costa. Downloaded on March 19,2021 at 04:43:26 UTC from IEEE Xplore. Restrictions apply.
2015 5th International Conference on the Internet of Things (IoT)
TABLE I. E NVIRONMENT S PECIFICATIONS
Management Host Hypervisor Host Virtual Machine
CPU Type Intel Core i5-3330 AMD Opteron 6172 AMD Opteron
Number of 4 48 1
CPU cores
Total Memory 8GB 200GB 1GB
ALE VM
ALE VM
ALE VM
ALE VM
VMs, and is implemented in Java, executed on Apache Tomcat
7.0 and Ubuntu 12.04 OS. WE configure the emulators of
Host RFID readers to send 200 tags at regular 20 seconds event
cycle.
B. Load Prediction Accuracy
As most applications take SLOs as a certain percentiles
of requests meeting a specific performance level, we have
compared our aEMA algorithm with the standard EMA one
in 90 percentile of the last 8 load values. Fig. 8 shows this
comparison result between aEMA with i = 0.2 and d = 0.8
and standard EMA with α = 0.7 in 90 percentile case. As can
be seen in the figure, our aEMA algorithm provides higher
prediction values much more frequently than the standard
EMA one.
TABLE II. L OAD P REDICTION A LGORITHMS C OMPARISON
EMA aEMA
90 percentile 90 percentile
median error 5.5% 2.5%
average error 9.4% 7.2%
Table II shows the median and average error results. As
our aEMA algorithm consistently provides higher and closer-
to-real-values prediction results in case of high load situations,
this increases our system’s hotspots prediction ability.
C. Migration Delay
(2)
As we employ a redirection-based approach to load migra-
tion, the time taken would be heavily dominated by the con-
nection establishment time of readers once migrations happen.
This is shown in Figure 9, in which the time taken increase
linearly with increasing number of readers. This migration time
can take more than 6 seconds for 100 readers, and thus support
our scheme of step-by-step migration based on load prediction
for RFID readers.
D. Load Balancing Performance
We have also conducted experiments to compare our ap-
proach with the standard one, which does not use any of our
optimizations, although redirection flow-based load migration
technique is still used because of necessity. The comparison
between the two approaches is shown in Table III.
The improvement results provided by our approach com-
pared to the standard one can be seen from Fig. 10 and Table
IV. Using 5000 flows for our experiments, our approach is
able to reduce the number of utilized VMs by 26.19%, while
increase the average number of flows per VM by 35.48%. This
85
 2015 5th International Conference on the Internet of Things (IoT)

CPU Load EMA aEMA

100 100 100

80 80 80

CPU Usage (%)

CPU Usage (%)

CPU Usage (%)

60 60 60

40 40 40

20 20 20

0 0 0
0 100 200 300 400 500 0 100 200 300 400 500 0 100 200 300 400 500
Time (seconds) Time (seconds) Time (seconds)

Real Real Predicted Real Predicted

(a) (b) (c)

CPU Load, 90 percentile EMA, 90 percentile aEMA, 90 percentile
100 100 100

80 80 80
CPU Usage (%)

CPU Usage (%)

CPU Usage (%)

60 60 60

40 40 40

20 20 20

0 0 0
0 100 200 300 400 500 0 100 200 300 400 500 0 100 200 300 400 500
Time (seconds) Time (seconds) Time (seconds)

Real Real Predicted Real Predicted

(d) (e) (f)

Fig. 8. CPU load prediction results

7000
Load Balancing Performance Comparison
6000 180 161.2903
Establishment time (ms)

160
5000
140
119.0476
4000 120
100
3000 80
60 42
2000
40 31
1000 20
0
0 Number of utilized VMs Average number of flows/VM
10 20 30 40 50 60 70 80 90 100
Standard Approach Our Approach
Number of readers

Fig. 10. Load Balancing Comparison

Fig. 9. Connection Establishment Time of Readers

TABLE III. P ERFORMANCE C OMPARISON S ETUP

grate flows out of a VM to minimize this type of error.
Standard EPCloudFlow In contrast, the standard approach does not consider
this problem; therefore, it is not able to make proper
Load Prediction None, use raw load values aEMA
migration judgment.
Migration Mechanism Redirection flow-based Redirection flow-based
Migration Strategy None, without migration EPCloudFlow migration
• Too many flows are migrated out of a VM in the
delay effect consideration strategy standard approach. This is because of the use of raw
load values instead of predicted ones; as well as no
considerations of migration delay effect, so the load
after flow migrations is not correctly observed.
significant contribution to the load balancing improvement is
because of two reasons:
VIII. C ONCLUSION
• Estimation of the number of flows to migrate always
carries some errors; thus, our approach gradually mi- We have proposed and demonstrated our approach for
RFID application deployments optimizations on Cloud. This
includes identification of unresolved challenges and our solu-
TABLE IV. L OAD BALANCING C OMPARISON tions proposal, together with system architecture design and
experimental evaluations of our proposal. Our approach has
Number of Average number of been shown to improve the overloading situations detection
utilized VMs flows per VM
accuracy through the use of aEMA, and be able to perform flow
Standard Approach 42 119.0476 migrations using a redirection-based technique with proper
Our Approach 31 161.2903 migration decisions. In our experiments, higher prediction
Improvement 26.19% 35.48% accuracy for high load levels, small connection establishment
time, and load balancing improvement have been shown.

86

Authorized licensed use limited to: Corporacion Universitaria de la Costa. Downloaded on March 19,2021 at 04:43:26 UTC from IEEE Xplore. Restrictions apply.
 2015 5th International Conference on the Internet of Things (IoT)

We reach the conclusion that gradual flow-based migration [15] M. Andreolini and S. Casolari, “Load prediction models in web-
based on aEMA load prediction scheme provides significant based systems,” in Proceedings of the 1st international conference on
contributions for hot spots detection and load balancing in Performance evaluation methodolgies and tools. ACM, 2006, p. 27.
Cloud-based RFID application deployment. As only linear [16] W. Voorsluys, J. Broberg, S. Venugopal, and R. Buyya, “Cost of virtual
machine live migration in clouds: A performance evaluation,” in Cloud
models are used, this scheme is also very inexpensive to Computing. Springer, 2009, pp. 254–265.
implement and use in real time. We expect our design to [17] Q. Zhang, L. Cheng, and R. Boutaba, “Cloud computing: state-of-the-art
contribute to the realization of IoT applications deployments. and research challenges,” Journal of internet services and applications,
vol. 1, no. 1, pp. 7–18, 2010.
ACKNOWLEDGMENT [18] H. A. Lagar-Cavilla, J. A. Whitney, A. M. Scannell, P. Patchin, S. M.
Rumble, E. De Lara, M. Brudno, and M. Satyanarayanan, “Snowflock:
This research was supported by the MSIP(Ministry of rapid virtual machine cloning for cloud computing,” in Proceedings of
Science, ICT and Future Planning), Korea, under the C- the 4th ACM European conference on Computer systems. ACM, 2009,
ITRC(Convergence Information Technology Research Center) pp. 1–12.
(IITP-2015-H8601-15-1007) supervised by the IITP(Institute [19] T. Wood, P. J. Shenoy, A. Venkataramani, and M. S. Yousif, “Black-box
for Information & communications Technology Promotion), and gray-box strategies for virtual machine migration.” in NSDI, vol. 7,
2007, pp. 17–17.
Institute for Information & communications Technology Pro-
[20] Z. Shen, S. Subbiah, X. Gu, and J. Wilkes, “Cloudscale: elastic resource
motion(IITP) grant funded by the Korea government(MSIP) scaling for multi-tenant cloud systems,” in Proceedings of the 2nd ACM
(No. R0126-15-1002, Development of agro-livestock cloud Symposium on Cloud Computing. ACM, 2011, p. 5.
and application service for balanced production, transparent [21] M. Kang and D.-H. Kim, “A real-time distributed architecture for rfid
distribution and safe consumption based on GS1), and the push service in large-scale epcglobal networks,” in Grid and Distributed
KUSTAR-KAIST Institute, Korea, under the R&D program Computing, ser. Communications in Computer and Information Science,
supervised by the KAIST. 2011, vol. 261, pp. 489–495.
[22] (2014) Apache cloudstack. [Online]. Available: http://cloudstack.
R EFERENCES apache.org/
[23] Z. Xiao, W. Song, and Q. Chen, “Dynamic resource allocation using
[1] K. Ashton, “That internet of things thing,” RFiD Journal, vol. 22, pp. virtual machines for cloud computing environment,” Parallel and Dis-
97–114, 2009. tributed Systems, IEEE Transactions on, vol. 24, no. 6, pp. 1107–1117,
[2] (2015) Gs1, the global language of business. [Online]. Available: 2013.
http://www.gs1.org/epcglobal [24] F. Sultan, K. Srinivasan, D. Iyer, and L. Iftode, “Migratory tcp: Highly
[3] D. Guinard, C. Floerkemeier, and S. Sarma, “Cloud computing, rest and available internet services using connection migration,” in Proceedings
mashups to simplify rfid application development and deployment,” in of ICDCS, 2002, pp. 17–26.
Proceedings of the Second International Workshop on Web of Things.
ACM, 2011, p. 9.
[4] E. Welbourne, L. Battle, G. Cole, K. Gould, K. Rector, S. Raymer,
M. Balazinska, and G. Borriello, “Building the internet of things using
rfid: the rfid ecosystem experience,” Internet Computing, IEEE, vol. 13,
no. 3, pp. 48–55, 2009.
[5] E. Welbourne, K. Koscher, E. Soroush, M. Balazinska, and G. Borriello,
“Longitudinal study of a building-scale rfid ecosystem,” in Proceedings
of the 7th international conference on Mobile systems, applications, and
services. ACM, 2009, pp. 69–82.
[6] (2015) Oliot, open language for internet of things. [Online]. Available:
http://gs1oliot.github.io/oliot/
[7] B. P. Rimal, E. Choi, and I. Lumb, “A taxonomy and survey of cloud
computing systems,” in INC, IMS and IDC, 2009. NCM’09. Fifth
International Joint Conference on. Ieee, 2009, pp. 44–51.
[8] P. Hofmann and D. Woods, “Cloud computing: the limits of public
clouds for business applications,” Internet Computing, IEEE, vol. 14,
no. 6, pp. 90–93, 2010.
[9] T. Dillon, C. Wu, and E. Chang, “Cloud computing: issues and chal-
lenges,” in Advanced Information Networking and Applications (AINA),
2010 24th IEEE International Conference on. Ieee, 2010, pp. 27–33.
[10] Z.-W. Yuan and Q. Li, “Research on data processing of rfid middleware
based on cloud computing,” in Rough Set and Knowledge Technology.
Springer, 2010, pp. 663–671.
[11] L. Chu and S.-J. Wu, “An integrated building fire evacuation system
with rfid and cloud computing,” in Intelligent Information Hiding and
Multimedia Signal Processing (IIH-MSP), 2011 Seventh International
Conference on. IEEE, 2011, pp. 17–20.
[12] Z. Gong, X. Gu, and J. Wilkes, “Press: Predictive elastic resource scal-
ing for cloud systems,” in Network and Service Management (CNSM),
2010 International Conference on. IEEE, 2010, pp. 9–16.
[13] P. A. Dinda and D. R. O’Hallaron, “Host load prediction using linear
models,” Cluster Computing, vol. 3, no. 4, pp. 265–280, 2000.
[14] P. Saripalli, G. Kiran, R. R. Shankar, H. Narware, and N. Bindal,
“Load prediction and hot spot detection models for autonomic cloud
computing,” in Utility and Cloud Computing (UCC), 2011 Fourth IEEE
International Conference on. IEEE, 2011, pp. 397–402.

87

Authorized licensed use limited to: Corporacion Universitaria de la Costa. Downloaded on March 19,2021 at 04:43:26 UTC from IEEE Xplore. Restrictions apply.