Фреймворк промышленного интернета

IJCSI International Journal of Computer Science Issues, Vol. 10, Issue 6, No 1, November 2013
ISSN (Print): 1694-0814 | ISSN (Online): 1694-0784
www.IJCSI.org 16
Conceptual Framework for Internet of
Things’ Virtualization via OpenFlow in
Context-aware Networks
Theo Kanter, Rahim Rahmani, and Arif Mahmud
Department of Computer and Systems Sciences, Stockholm University, Sweden
Abstract
A novel conceptual framework is presented in this
paper with an aim to standardize and virtualize Inter-net
of Things’ (IoT) infrastructure through deploying
OpenFlow technology. The framework can receive e-services
based on context information leaving the
current infrastructure unchanged. This framework
allows the active collaboration of heterogeneous de-vices
and protocols. Moreover it is capable to model
placement of physical objects, manage the system
and to collect information for services deployed on
an IoT infrastructure. Our proposed IoT virtualization
is applicable to a random topology scenario which
makes it possible to 1) share flow-sensors’ resources,
2) establish mult i-operational sensor networks, and 3)
extend reachability within the framework without
establishing any further physical networks. Flow-sensors
achieve better results comparable to the typi-cal-
sensors with respect to packet generation, reacha-bility,
simulation time, throughput, energy consump-tion
point of view. Even better results are possible
through utilizing multicast groups in large scale net-works.
Keywords: Context aware networks, Flow-sensor,
Infrastructure as a Service, Internet of Things, Open-
Flow, Virtualization
1. Introduction
The Internet of Things (IoT) can be outlined in a
universal network frame supported by regular and
interoperable network protocols in which sensible
and virtual “things” are incorporated into the co m-municat
ion network. ‘Th ings’, by definition, resem-bles
to any physical object that is capable to inter-connect
with each other and participate to develop
the concept of e-services out of context information
received from Internet of Things [1]; The concept of
IoT enormously strengthens the service space attain-able
from the Internet. Establishment of a complete
IoT framework can lead to ambient computing and
pervasive intelligence through networking and shar-ing
of resources among lots of physical entities in
configurable and dynamic networks [2]. A combined
cooperation of Internet of Things and OpenFlow is
able to hold the dream to attain Infrastructure as a
Service and the utmost exploitation of cloud compu-ting.
Availability of context information in modern in-formation
systems turns our day to day life simpler
and easier. All the devices surrounded us, from any
home appliances to any luxuries devices can become
responsive of our existence, and mood and can act
accordingly [3]. Deployment of flow-sensors in IoT
infrastructure can receive context data out of raw data
from environment and can lead to play role in devel-opment
in pervasive computing in such ways
 Information of dynamic environment can be
reachable through the placement of static devices.
 Create a better monitoring infrastructure for the
systems and services required
 Possibility of dynamic configuration and analy-sis
of the context information and sources.
 Maximum utilization of Internet of Things in
terms of reusability, resource sharing and sav-ings.
Present Infrastructure As a Service (IaaS) contain
a preset architecture with location aware network
mapping along with associated physical devices like
different servers and storage devices, routers and
switches and running routing logics and algorithms.
These topologies cannot support the dynamic one
where presence of sensors, intelligent devices are
virtual and cannot create a runnable common plat-form
for different kind of traffics. OpenFlow pro-grammability
and virtualization feature allows two
completely new abstract layers namely common plat-form
layer and virtualization layer to be added at the
top and bottom of a preset architecture. It also allows
Copyright (c) 2013 International Journal of Computer Science Issues. All Rights Reserved.

www.IJCSI.org 17
the present infrastructure running without any obsta-cles
even after adding new layer function-abilities.
So, only OpenFlow can provide a better solution
through network programmability and device virtual-izations
and thus enable the IaaS to provide the ser-vice
like security applications, system and network
applications, system software etc.
As a continuation of our previous works [4, 5, 6]
we have proposed the following ideas to implement
in IoT based context aware networks for the sake of
achieving a common platform and virtualizat ion with
IaaS layer through deploying OpenFlow protocol:
 A completely new idea to merge OpenFlow
technology with IaaS layer to make sensor data
clouds more efficient from informat ion gaining,
sensor management, monitor and virtualization
point of view.
 Placement of sensor node is very important for
proper data transmission and reception, but in a
random scenario, it is almost impossible. Many
researchers have proposed highly optimized
placement and transmission algorithms but these
are too complicated to be implemented practica l-ly.
So, why should not we try OpenFlow sup-ported
flow-sensor?
 Typical Sensor networks are formed in an ad-hoc
mode to perform any specific task. So, a com-mon
platform is required and OpenFlow is able
to provide that even for experimental traffics.
 Data is required to be shared and passed among
different wireless objects like sensors, actuators,
PDAs etc. OpenFlow is able to provide a com-mon
platform and virtualizat ion layer for all
networks and thus allow them to share the re-sources.
 We have suggested a 4 layer conceptual frame-work
to achieve context supported dynamic e-services
out of the static Internet of Things. This
framework will cover heterogeneous phys ical
entities, placement, integration and synchroniza-tion
with management system. This context ser-vice
network will leave the current internet infra-structure
unchanged and can be sketched along
with diverse systems and services.
 Presently transport layer is only responsible to
provide reliability which designates the internet
layer to be unreliable and let alone the below
layers. But OpenFlow supported sensor are
found to be the best candidate since it is delim-ited
to low overhead and multicast assistance as
comforted by CoAP application. Besides it can
turn the MAC layer more reliable in compar ison
to typical sensors and so does the network layer.
 At present sensor applications are typically data
centric but not the node centric which means we
are little concerned about the result of any spe-cific
node but the result from the group of sen-sors.
 Now a day calculat ion of the number of nodes
within the transmission range and packets re-ceived
are convenient from the stationary nodes
viewpoint. But we also need to address the pack-ets
from different domain of stationary sensors
received by access points.
Possible application includes e-health, home au-tomation,
transportation, battle field inspection, safe-ty,
failure management and in some other areas
where usual and normal attempts were proven to be
very expensive and uncertain [7]. Unstructured ran-domly
sited sensors integrated into IoT also have the
capabilit ies to offer a large amount of environmental
services such as sound, pressure, temperature, motion
etc.
The paper is organized in the following way: Sec-tion
2 describes the Motivation and background; Sec-tion
3 presents Design and implementation of the
proposed model; Section 4 describes the model
checking of the new concept; Section 5 presents the
performance evaluation and the conclusions are pro-vided
in section 6.
2. Background
Next generation internet is highly dependable on
the incorporation of regular objects found in our sur-roundings
those can be uniquely recognizable, con-trollable
and monitor-able such as sensors, actuators
etc. into Internet of Things. Just IP connectivity
won’t allow wire less sensor network (WSN) to be
included in Internet due to their limited resources like
bandwidth, memory, energy and communication ca-pabilit
ies [8]. Dynamic internet connectivity hap-pened
to be possible through Integration of WSN and
IoT. Task evaluation allows gaining benefits from
network heterogeneity, remotely accessing becomes
possible through efficient collaboration to achieve a
certain set of future challenges such as gaining con-text
information from surroundings [9].
Context is a term utilized to distinguish and de-scribe
the situation and state of any entity found in
our surroundings. It is the informat ion which is con-sidered
significant for the communication between
users and applications where identity, location, state
etc. of the objects are taken into account [10]. Con-text
networks itself can behave as a service since
results are collectively collected and turns fault toler-ant
and effective adaptive system; distribution of
service is maintained in the dynamic environment.
Inactivity of a fe w entit ies doesn’t affect largely for
the infrastructure and services can be still accessed
[11]. Context awareness bears a large prospect in
generation of novel services, resource sharing and
service quality development in IaaS and dynamic
services can be automatically adapted according to
context data through changing the service behavior.
Infrastructure as a Service (IaaS) is known to be
one of the most important methodologies to com-municate
with the services offered by cloud compu-ting
which preserve applicat ions, information in vir-tual
storages and servers and can be access via web
browser from internet [12]. IaaS also provides a solid
base to Software as a Service and Platform as a Ser-vice.
It is responsible to create an abstract layer (vir-

www.IJCSI.org 18
tual middleware environment) on physical devices
like storages, servers etc. along with offered services.
Opportunity is given to user to operate and configure
guest OS where storage, bandwidth and other per-formances
matrixes are previously fixed [13, 14].
Network as a service (NaaS) can be an integral
part of IaaS through the inclusion of contest aware
informat ion where networking loads will be shared,
applications will be virtualized and thereby quality of
services will be maintained [15]. Up -growing de-mands
of services can be solved through the flexibi l-ity
and scalability of context supported NaaS. Cur-rent
communication protocols are maintained and
managed by vendor and that’s why it is cha llenging
to establish new network services. These network
features shouldn’t be merged with running protocol
so that they can be introduced without changing the
current infrastructure. The current network should be
adapted to dynamic changes of these services. Net-work
as a service ensures the quality of information
and on-demand service through the dynamic configu-ration
of network devices and management [16]. The
joint collaboration of network as service and Open-
Flow can play a lead role in network virtualization
and can maximize the network utilizat ion through
resource saving, sharing and distributing among other
available nodes or entities.
The OpenFlow can split the traffic path into data
packet (maintained by underlying router or switch)
and control packet (maintained by a controller or
control server) which turn the physical device into a
simple one from a complicated mode since complex
intelligence programs are removed. Today OpenFlow
is supported by several major switch/router vendors
(especially a set of functions which are common) and
can support all sort of layers (2, 3, and 4) headers
[17]. It is also able to integrate the circuit and packet
switching technology and these can be treated sepa-rately
too. Core network also gain noteworthy bene-fits
due to control, management schemes from cost,
energy effectiveness and overall network perfor-mances
point of view [18, 19].
Flow-sensor is just like a typical sensor associated
with a control interface (software layer) and flow
tables (hardware layer). A Flow table contains a rule
(Header) with source and destination address, action
that takes the decision (either to drop or to forward
the packets) and a counter that maintains a statistics
of control and data packet. Control interface ex-changes
secure messages (control packet) via Open-
Flow and sensor buffer maintain typical TCP/IP with
access point (data packet exchange) [4].
The ultimate aim of IoT industry is to virtualize
and set up a common platform for pervasive compu-ting
where context information will be shared and
distributed among huge amount of physical entities
and create collaboration among mult iple services
without any centralize system. Within a very short
time the Internet of Things industry will be fully es-tablished
and prepared for large scale manufacture
maintaining the services requested by the clients and
managing the dynamic changes of the surroundings.
A standard conceptual framework has been proposed
taking that in to mind where it can generate context
informat ion out of raw data captured from surround-ings.
This layering concept will also permit new
technologies, protocols and services to be introduced
and upgrade the IoT technology based on the present
infrastructure.
3. Conceptual framework
The main tasks of this framework are to analyze
and determine the smart activit ies of these intelligent
devices through maintaining a dynamic interconnect-tion
among those devices. The proposed framework
will help to standardize IoT infrastructure so that it
can receive e-services based on context information
leaving the current infrastructure unchanged. The
active collaboration of these heterogeneous devices
and protocols can lead to future ambient computing
where the maximum utilization of cloud computing
will be ensured. This model is capable of logical di-vision
of physical devices placement, creation of
virtual links among different domains, networks and
collaborate among multiple application without any
central coordination system.
IaaS can afford standard functionalities to accom-modate
and provides access to cloud infrastructure.
The service is generally offered by modern data cen-ters
maintained by giant companies and organizat ion.
It is categorized as virtualization of resources which
permits a user to install and run application over vir-tualization
layer and allows the system to be distrib-uted,
configurable and scalable.
We plan to split the total infrastructure system into
4 layers to receive context supported e-services out
of raw data from the Internet of Things. These 4 lay-ers
establish a generic framework that does not alter
the current network infrastructure but create an inter-facing
among services and entities through network
virtualization. See figure 1.
3.1. Connectivity layer
This layer includes all the physical devices in-volved
in the framework and the interconnection
among them. Future internet largely depends on the
unification of these common objects found every-where
near us and these should be distinctly identifi-able
and controllable.

www.IJCSI.org 19
Syncronization
Context Service layer
information
Cloud infrastructure
OpenFlow
IOT gateway
Multicast
Sink nodes
Broadcast
Flow-sensors
Physical entities
Storage
management
Virtualization
management
Context
management
Feature
management
Resource
management
Internet of
Things
Services and
Applications
Service
management
Abstraction
layer
Access layer
Connectivity
layer
Meta data
Overlay
Internet
connectivity
Flow of data
Small range
communication
Very small range
communication
Broadcast
Storage as a
Service
Context
definition
Feature
definition
Random
placement
Integration
Devices/
Apps
Virtual link
Fig: 1. 4 layer context aware conceptual framework
This layer also involves assigning of low range
networking devices like sensors, actuators, RFID tags
etc and resource management checks the availability
of physical resources of all the devices and networks
involved in the underlying infrastructure. These de-vices
contain very limited resources and resource
management ensures the maximum utilization with
litt le overhead. It also allows sharing and distribution
of informat ion among mult iple networks or single
network divided into multiple domains.
RFID tags can be taken example of very short
range communicat ing devices and small enough to be
fitted anywhere. It can receive energy from reading
object which solves the requirement of battery or
external power supply. A large number of RFID tags
synchronizes with short range intelligent devices like
flow sensors to pass data in a multi-hopping scenario
with an aim to reach IoT gateway.
3.2. Access layer
Context Data will be reached to internet via IoT
Gateway as captured by short range devices in form
of raw data. Access layer comprises topology defini-tion,
network init iation, creation of domains etc. This
layer also includes connection setup, intra-inter do-main
communicat ion, scheduling, packet transmis-sions
between flow-sensors and IoT gateway. The
simulation was run later in this paper for different
scenario based on this layer. Feature management
contains a feature_filter which accept only acceptable
context data and redundant data are rejected. Large
number of sensor maintains lots of features but only a
small subset of features is useful generate a context
data.
Infrastructure as Service
Physical Devices Common Platform
Develop
Virtual Link
Creation
Storage,
Server,
Switch,
Routers,
Etc.
Sensor Networks,
Ad-hoc Networks,
Wireless
netwiorks,
Etc.
TCP/IP,
Cross Layer,
Experimental,
Pkt Switching,
Circuit Switching,
Etc.
System and Network
Mgmt,
Security Applications,
System Software,
Etc.
OpenFlow
Fig: 2. Infrast ructure and services offered
Feature filter helps to reduce irrelevant data transmis-sion,
increases the data transfer rate of useful data
and reduce energy and CPU consumption too. Nu m-ber
of features can be different based on the applica-tion
requirements and context data types.
The context management maintains a database
which store data received from sink nodes and db
controller to check and compare data_values and
thres_values and generates action_values. Initially
some predefined values are allocated (also known as
threshold values), later replaced by newly received
values are included (data_values). The database
stores only the change value where duplication is not
allowed. Database always compares the newly re-ceived
values with threshold values and creates a
decision (action_value) and notifies the IoT Gateway.
3.3. Abstraction layer
One of the most important characteristics of
OpenFlow is to add virtual layers with the preset lay-ers,
leaving the established infrastructure unchanged.
As shown in fig. 2, a virtual link can be created
among different networks and a common platform
can be developed for various communication systems.
The system is fully a centralized system from physi-cal
layer viewpoint but a distribution of service (flow
visor could be utilized) could be maintained. One

www.IJCSI.org 20
central system can monitor, control all sorts of traf-fics.
It can help to achieve better band-width, reliabil-ity,
robust routing, etc. which will lead to a better
Quality of Services (QoS).
Infrastructure as Service
OpenFlow
Common Platform
Virtualization
Smart
Objects/
Intelligent
Things
Sensor/
Things Server Others
Fig: 3. Three abst ract ion layers
In a multi-hopping scenario packets are transferred
via some adjacent nodes. So, nodes near to access
points bears too much load in comparison to distant
nodes in a downstream scenario and inactivity of
these important nodes may cause the network to be
collapsed. Virtual presence of sensor nodes can solve
the problem where we can create a virtual link be-tween
two sensor networks through access point ne-gotiation.
So, we can design a three a three layer plat-form
(fig. 3) where common platform and virtualiza-tion
layer are newly added with established infra-structure.
Sensors need not to be worried about
reach-ability or their placement even in harsh areas.
Packet could be sent to any nodes even if it is sited
on different networks.
3.4. Service layer
Storage management bears the idea about all sorts
of unfamiliar and/or important technologies and in-formation
which can turn the system scalable and
efficient. It is not only responsible for storing data
but also to provide security along with it. It also al-lows
accessing data effectively; integrating data to
enhance service intelligence, analysis based on the
services required and most importantly increases the
storage efficiency.
Storage and management layer involves data stor-age
& system supervision, software services and
business management & operations. Though they are
included in one layer, the business support sys -tem
resides slightly above of cloud computing service
whereas Open-Flow is placed below of it as present-ed
in figure 4 to include virtualizat ions and monitor
management.
Service
Management
Business
Operations
Network
Managemnent
Decision Analysis Office Support
Cloud Infrastructure
OpenFlow Controller
OpenFlow Mapping
Common platform
Automatic Overload
Internet
Fig: 4. Cloud infrast ructure over internet
All types of business models can find benefits
from cloud computing infrastructure. As for example
cost and flexibility from small business viewpoint
whereas total IT problems can be solved for large
companies. It will add advantages for companies,
their employees, consumers, distributor where the
overall business solution can be provided.
Service management combines the required ser-vices
with organizational solutions and thus new
generation user service becomes simplified. These
forthcoming services are necessitated to be co inter-related
and combined in order to meet the demand
socio- economic factors such as environment analysis,
safety measurement, climate management, agricul-ture
modernization etc. [21].
As specified previously any kind of context aware
services can be diagramed through this simplified
conceptual model. Besides due to heterogeneity man-agement,
the framework keeps provision for any
technology to be introduced. Most importantly it will
leave the established internet infrastructure and cloud
technology unchanged and running as well.
4. Work flow management diagram
OpenFlow architecture allows building a common
platform as found in fig. 5 for different routed-switched
traffic and requires to be mapped before

www.IJCSI.org 21
that. OpenFlow supports 2nd layer, 3rd layer and even
cross layer traffic where source and destination ad-dresses
are needed to previously set up. OpenFlow
mapping layer establish a connection between phys i-cal
devices and OpenFlow table via a secured Open-
Flow communication protocol. OpenFlow control
server generates a tree structure and locates the pos i-tion
of sensor devices. It also can monitor the packet
flow in downstream direction and observe the current
status of each sensor on a requirement or periodic
basis.
5. Model checking and concept
The PROMELA and SPIN combination has
proved to be a versatile and useful tool in the simula-tion
and verificat ion of software systems [22, 23, and
24]. Both have been extensively used in modeling
and verifying communication protocols. In particular,
SPIN shall be applied to simulate exhaustively the
correctness of flow sensor and provide verification in
Linear Temporal Logic (LTL) with respect to con-vergence.
5.1. Definition states
3 different states, shown in fig. 4 Match_pkt,
Translation and Send_pkt can be represented by П , μ ,
Ґ respectively.
Definition 1: Upon receiving, data packet will be
matched based on control server state, packet source
and packet information. Then the packet will be ei-ther
dropped or sent to the translation or mapping
state accordingly.
П ≠ D or π Pkt , where
receiving of packet = Pkt and packet dropping = D
Definition 2: Translation state maps the data into
the flow table and allocates the task into different
sensor networks.
μ|= F1 ∨ F2 …∨ Fn for id = {1, 2,…, n} and
we also achieve μ|= Fid
Different task allocations can be denoted by F1,
F2... Fn respectively along with network id as id.
Definition 3: Packet will be sent either to cache or
to translation state in case of acknowledgement or
data respectively.
Ґ |= cache ∨ μ iff Ґ |= cache or Ґ |= μ, where
Add_cache and translation state are represented by
cache and μ respectively.
OpenFlow
Mapping
Common
Platform
Automatic
workload
Network 1
Network 2
Network n
Virtualization
Feedback/Monitor
Management
Task Allocation
Connection
Establishment
Fig: 5. Work flow management
5.2. LTL formulas
The following LTL formulas are generated for the
definitions:
LTL1: □ (Receive_pkt ∧ o-
Match_pkt)
LTL1: □
∨ action ToTask_alloc 2 ∨ …. ∨ action To-
Task_alloc n))
LTL1: □ (Send_pkt ∧
ToAdd_cache ∨ action ToTranslation)
6. Packet transmission algorithm
The access node receives the flows of packets from
its own and different domain of flow-sensors. The
packet transmission algorithm consists of three phas-es
known as network initializat ion, transmission and
reception. Flow table matching and checking have
been explained in packet flow algorithm in one of our
previous papers [4].
6.1. Network initialization
At routing initiation phase, every access point maps
all the static nodes connected to it.
i.
x.

www.IJCSI.org 22
INIT Wait
Receive_pkt
Drop
Match_pk
t
Translation
Task_Alloc 1 Task_Alloc 2 Task_Alloc n
Send_pkt
Translation
Match_pk
t
Add_cache
Fig: 6. Data flow diagram
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
10
33
18 19
15
20
Fig: 7. Four different sensor networks
17 16
s_s(x,y)  calculates the sinal strength of
transmitting node x to node y.
def_ft(y)  define the flow table of receiving
node y.
chk_ft(x)  match the flow table of receiving
node y with transmitting node x.
6.2. Transmission
Source node, x ε X where X {source nodes}
trans_start(x) = schedule(t); // Transmission of
transmitting node x starts at scheduled time t.
for each transmitting node x,
for each receiving node y,
trans_range(x); // Calculate the transmission
range of node x using Friss model .
if (distance_required ≥ distance (x,y)) return
true,
X={X,y}; // add the receiving node y with
source nodes
If no new nodes are added to X, return;
if (y== dest_add); // check if the receiving node
is the destination node
return true;
trans_end() ; // end the transmission
else return;
10
33
18 19
15
17 16
20
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0 AP
1
2
3
4
5
6
7
8
9
11
12 13 14
21
22
23
24
25
26
27
28
29
30
31
32
34
35
36
37
38
39
40
Fig: 8. Individual routing for sensor networks
6.3. 6.3. Reception
schedule (t); // reception starts at time t
for each receiving node y,
rcv(bytes); // receive packets from x
chk_ft (x); // check the flow table of node y with
node x
if( t rue); trans_start (y); // accept and forward
the packet
else return; // ignore the packet item.
7. Reference topology model
The scenario is simulated based on access layer
as stated earlier. Total scenario is divided into 2 por-tions.
At first communicat ion is placed between sev-eral
networks. Then the network got divided into
several domains and performance is analyzed based
on intra and inter domain communication.
4 different sensor networks have been created with
an access point that can be found in fig. 7. All the
sensors of different networks will use the access
point as the gateway. Different sensor networks are
assumed to serve different applications where each
network contains 10 sensors. These sensors are ran-domly
sited and access point is situated somehow in
the middle. Red, black, green and blue sensors are
assumed to the 1st, 2nd, 3rd and 4th network respec-tive-
ly.
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
0
0 AP
1
2
3
4
5
6
7
8
9
11
12 13 14
21
22
23
24
25
26
27
28
29
30
31
32
34
35
36
37
38
39
40

www.IJCSI.org 23
10
33
18 19
15
17 16
20
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0 AP
1
2
3
4
5
6
7
8
9
11
12 13 14
21
22
23
24
25
26
27
28
29
30
31
32
34
35
36
37
38
39
40
Fig: 9. Sharing resources among different networks
At the beginning (fig. 8) all the sensors are as-sumed
to the typical sensors and sensors of one net-work
are not allowed to communicate with other
networks. In random networks, some nodes are al-ways
sited out of state or away from the range of
access point and other sensors. In 1st network node 7
and in 2nd network node 16, 17 and 19 are out of
range. That’s why we have 100% reach -ability in 3rd
and 4th network but 90% and 70% reach-ability in 1st
and 2nd network respectively.
Then in fig. 9 all the typical sensors are replaced
by flow-sensors and sensors of one network can ut i-lize
sensors of other networks for data transfer. We
can see node 28 of 4th network can reach node 7 of 1st
network. And node 16, 17 and 19 of network 2nd can
use node 34 of 3rd network as intermediate nodes in a
multi-hopping scenario. So now all the 4 networks
are assumed to be a single network virtually and
100% reach-ability can be achieved thereby.
The Ns-3 simulator has been used to simulate the
following scenario where IEEE 802.11 was taken as
a reference sensor model [25]. IEEE 802.11 is a
worldwide accepted model for consumer, public and
organizational applications [26]. To be noted Ns -3 is
an event supported and going to replace Ns -2 through
receiving all the models and features [27]; standard
physical and MAC layer functionalities performance
has been analyzed in terms of delay, jitter, through-put,
energy consumption etc. from various stationary
and mobile nodes viewpoint [28], [29] and [30]. We
have created a network topology with 24 nodes in fig.
10 where all the nodes are randomly placed.
Fig: 10. Random placement of flow-sensors and sink nodes
Fig: 11. Creat ion of mult icast domains
Fig: 12. Communicat ion between sink nodes

www.IJCSI.org 24
100
90
80
70
60
50
40
30
20
10
0
-20 -18 -16 -14 -12 -10 -8 -6 -4 -2
Tx power in dBm
Reachability (%)
Transmission power vs Reachability
1 Net/AP
2 Net/AP
3 Net/AP
All Net/AP
Fig: 13. Reachability comparison on varying t ransmission power
90
80
70
60
50
40
30
20
10
50 100 150 200 250 300
Topology
Reachability (%)
Reachability vs Topology size
1 Net/AP
2 Net/AP
3 Net/AP
All Net/AP
Fig: 14. Reachability comparison on varying topology sizes
4 nodes are acting as sink nodes; node number 0 to 3
where rest them are flow-sensors. Initially sink nodes
are not allowed to communication with each other.
So, 4 sink nodes have created 4 multicast domains in
fig 11. Sink node 0, 1, 2 and 3 contain11, 0, 3, 1
flow-sensor respectively. Some of the flow- sensors
can be in a state of outage and in the scenario. 5
flow-sensors are out of reachability.
Now we want to create a bigger mult icast domain
where sink node 1 and 3 can communicate with each
other and can transfer data as shown in fig. 12. In the
same way all sink nodes can be allowed to communi-cate
to create the largest domain. Sink nodes can
send data to IoT gateway and it receives data as a set
of flows. A single sink node defines the features
where IoT gateway generates context data from fea-ture
data and sent it to the cloud via internet structure.
8. Performance evaluation
The network performance was evaluated
based on three different scenarios; inter-network
communication, intra-domain
communication and inter domain communi-cation.
200
150
100
50
0
1 Net/AP
2 Net/AP
3 Net/AP
All net/AP
60 70 80 90 100 110 120 130 140 150
Nodes
Packets
Number of nodes vs Total packets
2
1.5
1
0.5
0
60 70 80 90 100 110 120 130 140 150
Nodes
Time
Number of nodes vs Simulation time
1 Net/AP
2 Net/AP
3 Net/AP
All Net/AP
Fig: 15. Total packets and simulation t ime comparison on varying
number of nodes
Fig: 16. Comparison of throughput based on varying node density
250
200
150
100
50
0
-18 -16 -14 -12 -10 -8 -6 -4 -2
Tx power (dBm)
Throughput (Kbps)
Tx power vs Throughput
1 MG
2 MG
3 MG
4 MG
Fig: 17. Throughput evaluat ion with a changeable t ransmission
power
and inter domain communicat ion. Result analysis
was performed following the ideal parameter values
by default provided in Table 1 else otherwise noted.

www.IJCSI.org 25
8.1. Inter-network communication
The scenario was simulated using Matlab where
the metrics include response time and total number of
generated packets for varying topology scenario, sen-sor
density and Transmission (Tx) power.
TABLE 1, SIMULATION PARAMETER
PARAMETER
VALUE OR
NAME
Communication stacks
Radio model
Node placement
Topology size*
Number of nodes*
Sensor density*
Data rate
Channel check rate
Simulat ion delay
Maximum retransmission
Tx range*
Interference range*
Path gain
Propagation constant
Packet size
Required SNR
Tx power*
Receiver sensit ivity
Transmission energy
Recept ion energy
Transmitter antenna gain
Receiver antenna gain
Node mobility
Simulat ion runs
*) will be varied during simulat ions.
RIME
UDGM & constant loss
Random 2D position
100*100
100
0.01 nodes/meter2
250 Kbit /s
8 Hz
0 Sec
15 t imes
10 meters
10 meters
-0.04 dBm
4
125 Byte
4 dB
-10.45 dBm
-80.5 dBm
30 nJ/bit
20 nJ/bit
0 dBi
0 dBi
No
70+ t imes
We have compared the performance of flow-sensor
and typical sensors where they are randomly
sited in maximum four networks with an access point.
In 1 Net/AP, sensors of one network are not allowed
to communicate with sensors of other networks and
they will behave as typical sensors. In 2 Net/AP, 3
Net/AP and 4 Net/AP, sensors of 2 networks, sensors
of 3 networks and sensors of all 4 networks will be
allowed to communicate as flow-sensors. We have
counted the total number of packets (average) and
simulation time (total) along with reachability based
on varying topology sizes, number of nodes and
transmission power.
Fig. 13 explains the reachability of typical sensors
and flow-sensors based on varying transmission
power. It’s true that in a very low and high transmis-sion
power both of them behave equally but it is im-portant
to know about the ideal scenario activity. All
Net/AP reaches 90% of reachability in -8.5 dBm
whereas typical sensor requires -4.2 dBm and 2
Net/AP and 3 Net/AP require -5 and -6.8 dBm re-spectively.
In an almost ideal Tx power scenario (-10
dBm), 1 Net/AP, 2 Net/AP, 3 Net/AP and 4 Net /AP
have the reach-ability of 41.56%, 52.84%, 61.56%
and 79.92% respectively.
500
450
400
350
300
250
200
150
100
50
50 100 150 200 250 300
Number of nodes
Number of transmitted packets
Number of nodes vs number of transmitted packets
4 MG
3 MG
2 MG
1 MG
Fig: 18. Comparison of number of t ransmit ted packets based on varying
number of nodes
Fig. 14 illustrates reachability counted on varying
topology sizes. Reachability of both the typical sen-sors
(1 Net/AP) and flow-sensors (All Net/AP) have
been decreased with the increase of topology size.
But in all the cases flow-sensors maintains better
reachability in comparison to typical sensor network
scenario. In a medium scale network (topology size
as 180*180), 1 Net/AP, 2 Net/AP, 3 Net/AP and 4
Net/AP have the reach-ability of 28.78%, 37.81%,
46.24% and 56.16% respectively.
In fig. 15 simulat ion time and total number of
packets have been calculated on the same varying
amount of nodes. In medium scale networks flow-sensors
requires more time to simulate and generate
more packets than typical sensors. But in case of
higher number of nodes, the difference between them
gets decreased. It is true for small networks both of
them bear low reachability as reflected in their simu-lation
time and generated number of packets. In a
medium scale network (number of nodes = 100), 1
Net/AP, 2 Net/AP, 3 Net/AP and 4 Net/AP have gen-erated
45.23, 61.32, 74.71 and 89.39 packets with a
simulation time of 0.55, 0.91, 1.10 and 1.36 sec re-spectively.
8.2. Intra-domain communication
The performance metrics comprises throughput for
changing node density and transmission power.
UDGM & constant loss has been exploited as a radio
model over RIME communicat ion stack to simulate
the scenario in Cooja simulator [31]. The problem is
addressed by deploying IETF supported IEEE
802.15.4 network model in the physical layer that is
capable to operate in low data rate.
The network topology was distributed into 1, 2, 3
and 4 multicast groups denoted as 1, 2, 3 and 4 MG
re-spectively. The comparison was carry out based

www.IJCSI.org 26
on node density, reachability, transmission power,
throughput and maximum number of hops.
0.18
0.16
0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
50 100 150 200 250 300
Number of nodes
Energy Consumption in joules
Number of nodes vs Energy consumption
4 MG
3 MG
2 MG
1 MG
Fig 19: Evaluat ion of energy consumption with changing number
of nodes
As found in figure 16, all of multicast domains had
a trivial throughput at low density but initiated
mounting up with high density as expected. Small
numbers of nodes generate fewer packets and most of
packets get dropped due to lower reachability. And
it’s almost equal for a ll g roups. As a result network
efficiency remains lower for all multicast groups at
low density. On the other hand packet drop hardly
occurs due to high reachability. But packet collision
increases with higher number of nodes.
4 MG had a lower packet collision in comparison
to other multicast groups that escalated its success
rate in highly dense network and so thus the through-put.
At node density 0.01 nodes/m2, 4 MG, 3 MG, 2
MG and 1MG accomplished the throughput of 65.32,
60.4, 54.02 and 48.55 Kbps respectively.
Entire groups bear almost equal throughput (very
low and very high) at low and high tx power (figure
17).
Reachability has also its effect on the throughput.
The throughput increases with the rise and decrease
with the decline of reachability. So, it can be claimed
that throughput and reachability are proportional to
each other in an ideal example (when other factors
remain constant).
8.3. Inter-domain communication
NS-3 was used to simulate the consequence where
the system performance metrics involve total number
of generated packets and energy consumption for
varying number of nodes.
As seen in figure 18, all of the mult icast groups
bear almost equal packet generation at the beginning
and differences are found with the increase in num-ber
of nodes. 4 MG transmits more packets than oth-er
multicast groups and seen to be rising for large
scale networks.
For 300 nodes, 4 MG, 3 MG, 2 MG and 1 MG
transmitted 490.43, 414.72, 372.15 and 340.06 pack-ets
respectively.
Fig 19 compares the energy consumption for vary-ing
number of nodes. As expected, 4 MG consumes
more energy in comparison to other multicast groups
for large networks. But the energy requirement dif-ferences
are very litt le for the networks of small
number of nodes.
4 MG, 3 MG, 2 MG and 1 MG consumed 0.172,
0.143, 0.125 and 0.111J energy respectively in case
of 300 nodes.
Reachability can affect both the packet generation
rate and energy consumption. To achieve better
reachability, more packets are required generated. On
the better reachable area, more packets will also be
received. As a result more energy will be consumed.
9. Conclusion
The proposed context supported framework can
systematize IoT infrastructure to receive e-services
out of raw data captured by physical devices. The
logical division of this model allows to distinct
placement of objects, coordination of applications
and management functions. A large number of sen-sors
can be divided into groups and send their data to
context server which is placed in the clouds via IoT
gateway. And the management functions merged
with different layers helps to acquire context infor-mat
ion from the raw data received from the sur-rounding.
Context awareness can play a noteworthy role in
attaining e-services and pervasive computing as well
since it allows interpreting of numerous contexts re-ceived
from surroundings. The explicit IoT dissection
and definite standard allows different manufacturers
and system vendors to collaborate their works and
large scale development to be fully operational.
Our proposed IoT virtualization can be applicable
in a random topology scenario where some of the
physical nodes can be sited out of state and inactivity
of those nodes can make unreachable from access
points. Network virtualization allows flow-sensors of
different networks to be used as intermediate nodes
under the same platform without establishing any
further physical networks. Thus enables resources to
be shared, establishment of multi operational sensor
networks and escalation of the reachability thereby.
In an inter network communication, All Net/AP
achieves more reachability by 18.36, 27.08, 38.36 %
points and generate more packets by 14.68, 28.07,
44.16 in comparison to 3, 2, 1 Net/AP in an ideal
scenario. On the other hand, 4 MG performed better
than other mult icast groups in intra and inter-domain
communicat ion. 4 MG generate better throughput by
4.92, 11.3, 16.77 Kbps at node density 0.01 node/m2
and more packets by 75.71, 118.28, 150.37 at node
density 0.03 node/m2 in case of intra and inter-domain
communication respectively. The result trend

www.IJCSI.org 27
shows that even better result is possible for large
scale networks.
Current network infrastructure cannot handle au-tomatic
tuning and adaptive optimization due to the
dynamic changes of networks and surroundings. So,
utilizat ion of network as a service with OpenFlow
technology can bring revolution over present network
infrastructure through maximizing the network ca-pacity
and fulfilling the demand of dynamic user
services and IT solutions specifically from bandwidth,
computation power, and storage etc. point of view.
Acknowledgements
Research founding from the European (FP7) MobiS
Project is deeply appreciated.
References
[1] Delphine Christ in, Andreas Reinhardt , Parag S. Mogre and
Ralf St einmet z, “Wireless Sensor Networks and the Int ernet of
Things: Select ed Challenges”, Mult imedia Communicat ions
Lab, Technische Universitat Darmstadt, Merckstr. 25, 64283
Darmstadt, Germany.
[2] Ovidiu Vermesan, Peter Friess, Patrick Guillemin, Sergio
Gusmeroli, Harald Sundmaeker, Dr. Alessandro Bassi,Ignacio
Soler Jubert, Dr. Margaretha Mazura, Dr. Mark Harrison,Dr.
Markus Eisenhauer, Dr. P at Doody. “Int ernet of Things St ra-tegic
Research Roadmap”,http://www.int ernet-of-things-reearch.
eu/pdf/IoT_Cluster_St rategic_Research_Agenda_2011
.pdf
[3] P eizhao Hu, Jadwiga Indulska, and Ricky Robinson, “An
Autonomic Context Management System for Pervasive Com-put
ing”, Sixth Annual IEEE Int ernational Conference on Per-vasive
Computing and Communications, 2008
[4] Arif Mahmud and Rahim Rahmani, Exploitat ion of OpenFlow
in Wireless Sensor Networks, Dept . Of Informat ion, Technol-ogy
and Media, Mid Sweden Universit y, “Int. Conference on
comput er Science and Network Technology, IEEE 2011”, pp
594-600, Harbin, China.
[5] Arif Mahmud, Rahim Rahmani and Theo Kanter, Deployment
of flow-sensors in Int ernet of Things’ virt ualizat ion via Open-
Flow, Dept. Of Computer and Systems Sciences, Stockholm
University, Sweden, “The 1st Int ernational Workshop on Int e-grated
Enabling Technologies, IEEE 2012, Vancouver, Cana-da.
[6] Arif Mahmud, Theo Kanter and Rahim Rahmani, Flow-sensor
Mobility and Mult icast Support in Internet of Things’ Virt ual-izat
ion, Dept. Of Computer and Systems Sciences, Stockholm
University, Sweden, “ Int ernat ional Conference on ICT Con-vergence,
IEEE 2012, Jeju Island, South Korea.
[7] Luigi Atzori , Antonio Iera , and Giacomo Morabit o, “The
Int ernet of Things: A survey”, University of Cagliari, Italy,
Computer Networks, Volume 54, Issue 15, 28 October 2010,
Pages 2787–2805.
[8] Delphine Christ in, Andreas Reinhardt , Parag S. Mogre and
Ralf St einmet z, “Wireless Sensor Networks and the Int ernet of
Things: Select ed Challenges”, Mult imedia Communicat ions
Lab, Technische Universit ¨at Darmstadt , Merckstr. 25, 64283
Darmstadt, Germany.
[9] Crist ina Alcaraz, Pablo Najera, Javier Lopez and Rodrigo
Roman, “Wireless Sensor Networks and t he Internet of
Things: Do We Need a Complete Int egrat ion?” Computer Sci-ence
Department University of Malaga, Malaga, Spain.
[10] Frieder Ganz, Payam Barnaghi, Francois Carrez and Klaus
Moessner, “ Cont ext -Aware Management for Sensor Net-works”,
5t h Int ernat ional Conference on Communicat ion
System Software and Middleware, USA
[11] Xiaoming Hu, Yun Ding, Nearchos Paspallis, George A.
Papadopoulos, Pyrros Bratskas, Paolo Barone, Alessandro
Mamelli, Yves Vanrompay, and Yolande Berbers, “A P eer-to-
Peer based Infrast ructure for Context Distribut ion in Mo-bile
and Ubiquitous Environment s”, OTM'07 P roceedings of
the 2007 OTM confederated international conference on On
the move to meaningful internet systems - Volume Part I,
Pages 236-239
[12] Rajkumar Buyya, Chee Shin Yeo and Srikumar Venugopal,
“Market-Oriented Cloud Comput ing: Vision, Hype, and Re-ality
for Delivering IT Services as Comput ing Ut ilit ies”,
Dept. of Comput . Sci. & Software Eng., Univ. of Melbourne,
Melbourne, VIC, The 10th IEEE Internat ional Conference on
High Performance Comput ing and Communications, 2008.
[13] Radu Prodan, Simon Ost ermann, “A Survey and Taxonomy
of Infrastructure as a Service and Web Host ing Cloud Pro-viders”,
Inst . of Comput . Sci., Univ. of Innsbruck, Innsbruck,
Aust ria, IEEE, Grid computing, 2009.
[14] Francesco Longo, Rahul Ghosh, Vijay K. Naik, and Kishor S.
Trivedi, “A Scalable Availabilit y Model for Infrastructure-as-
a-Service Cloud”, Dipt . di Mat ., Univ. degli St udi di Mes-sina,
Messina, Italy, IEEE 2011.
[15] Katarina Stanoevska-Slabeva and Thomas Wozniak, “Oppo r-tunit
ies and Threats by Mobile Plat forms: The (New) Role of
Mobile Network Operators”, Int elligence in Next Generat ion
Networks (ICIN), 2010
[16] Paolo Costa, Matteo Migliavacca, Peter Pietzuch, and Alex-ander
L. Wolf, “NaaS: Network-as-a-Service in the Cloud”,
2nd USENIX Workshop on Hot Topics in Management of
Internet , Cloud, and Enterprise Networks and Services (Hot-
ICE'12), USA
[17] “OpenFlow Swit ch Specificat ion”,
http://www.openflow.org/documents/openflow-spec-v1.1.0.
pdf
[18] R. Sherwood, G. Gibb, K.-King Yap, G. Appenzeller, M.
Casado, N. McKeown, and G. Parulkar, “FlowViso r: A Net-work
virt ualization Layer”, Technical report s, Deut che Tele-com
and Stanford University, October 2009
[19] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru
Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker,
and Jonathan T urner “OpenFlow: Enabling Innovat ion in
Campus Networks”, March 14, 2008.
ht tp://www.openflow.org/documents/openflow-wp-latest.pdf
[20] Robert Kraut, Mary Lou Maher, Judith Olson, Thomas W.
Malone, Pet er P irolli, John C. Thomas, “ Scient ific founda-t
ions: A case for technology- mediated social- part icipat ion
t heory”, IEEE 2010
[21] Gerard J. Holzmann. “The Model Checker SPIN”. IEEE
Transaction on software Engineering,23(5):1-17, May 1997.
[22] Gerard J. Holzmann, SPIN Online Reference. Bell Labs,
http://cm.bell-labs.com/cm/cs/what /spin/Man
/index.html)August 1997.
[23] Rob Gert h. “ Concise Promela Refence”. Technical report,
Eindhoven University, (http://cm.bell-labs.
com/cm/cs/what/spin/Man/Quick.html ) June1997
[24] Ns-3 simulator, http://www.nsnam.org/
[25] Zhong Ping, Shi Jianghong, Zeng Zhihong, Zhang Dezhong,
Zhou Liping and Chen Huihuang, “Performance Evaluat ion
of the IEEE 802.11 MAC for Mobile Wireless Sensor Net-works”,
The 6th Internat ional Conference on Comput er Sci-ence
& Educat ion (ICCSE 2011), August 3-5, 2011. Super-
Star Virgo, Singapore.
[26] J.L. Font , P. Iñigo, M. Domínguez, J. L. Sevillano and C.
Amaya,“ Analysis of source code metrics from ns-2 and ns-3
network simulat ors,” Simulat ion Modelling P ract ice and
Theory, 2011, vol. 19, pp. 1330-1346
[27] L. Adams, “ Capit alizing on 802.11 for Sensor Networks” In
The White Paper GainSpan Corporat ion: Los Gatos, CA,
USA, 2007.
[28] “Wireless LAN Medium Access Cont rol (MAC) and Physi-cal
Layer (PHY) Specificat ion”, IEEE St d. 802.11-2007 edi-t
ion (Revision of IEEE Std 802.11-1999), 2007.
[29] G. Bianchi, “P erformance analysis of the IEEE 802.11 dis-t
ribut ed coordinat ion funct ion”, IEEE Journal on Select ed
Areas in Communications, 2000, vol. 18, pp. 535-547
[30] The Cont iki OS, “htt p://www.cont iki-os.
org/p/download.html”

Фреймворк промышленного интернета

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to Фреймворк промышленного интернета (20)

More from Sergey Zhdanov (20)

Recently uploaded (20)

Фреймворк промышленного интернета