Content uploaded by Rozeha A Rashid
Author content
All content in this area was uploaded by Rozeha A Rashid on Dec 19, 2018
Content may be subject to copyright.
C16 Date: May 31, 2018 Time: 11:17 pm
577
16
Service-Oriented Architecture for IoT Home Area
Networking in 5G
Mohd Rozaini Abd Rahim, Rozeha A. Rashid, Ahmad M. Rateb, Mohd Adib
Sarijari, Ahmad Shahidan Abdullah, Abdul Hadi Fikri Abdul Hamid, Hamdan
Sayuti, and Norsheila Fisal
Universiti Teknologi Malaysia, Advanced Telecommunication Technology (ATT), Faculty of Elect rical Engineering,
Johor, Malaysia
16.1 Introduction
Internet of Things (IoT) is a network that interconnects objects from everyday
life to create smarter homes, cities, transport, and health care systems [1].
The number of IoT devices is expected to range between 30 and 75 billion
devices by 2020 [2–5], and hence they will represent the majority of the 5G
network terminals. This large population of machines will use the 5G network to
communicate with eachother, with the human user, and to send data collected
by embedded sensors to the cloud for analysis and processing. As a result,
IoT devices have acquired a significant share of the 5G systems design effort,
where several components of the 5G network are being designed to handle the
scalability, heterogeneity, power, and cost requirements of the IoT [6,7].
Smart cities and health monitoring are among the most prevailing vertical
applications of 5G networks [8]. Smart cities will involve a highly dense clusters
of wireless sensors that enable a large set of services and applications such
as household electrical power consumption monitoring to enable power grid
optimization, environmental services, access control, security system, and pol-
lution monitoring. These applications demand highly efficient utilization and
management of the sensor resources at the bottom level in order to secure sta-
ble operation and traffic intensity within the network that interconnects these
nodes.
5G Networks: Fundamental Requirements, Enabling Technologies, and Operations Management, First Edition.
Anwer Al-Dulaimi, X ianbin Wang, and Chih-Lin I.
©2018 by The Institute of Electrical and Electronics Engineers, Inc. Published 2018 by John Wiley & Sons, Inc.
C16 Date: May 31, 2018 Time: 11:17 pm
578 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
On the other hand, health services is going to be revolutionized by 5G due to
enabling of real-time health monitoring through wearables, in addition to en-
abling distant intervention by health specialist in cases of emergencies. Enabling
a highly reliable operation for these critical services requires viable guarantees
on system connectivity and latency, which might be hurdles due to network
congestion and inefficient management of sensors.
A large portion of IoT devices resides within the vicinity of our homes, such
as personal smartphones, wearable health monitors, smart light bulbs, smart
locks, security cameras, smart air conditioners. The interconnection between
all these devices creates a smart IoT home area network (HAN). Devices within
the IoT HAN enable smart home applications such as smart lighting, heating,
security, remote health care, entertainment [9–11]. Efficient implementation
of IoT HAN for smart home applications facesseveral challenges, among which
we mention the following:
1) Inefficient Utilization and Management of Sensor Nodes:Thestrongcou-
pling between application and hardware mandates that one or more sensor
nodes are allocated for every smart home application. For example, room
temperature control and fire alarm applications mainlysense the same quan-
tity, which is temperature. This introduces redundancy in the sensors and
the data they transmit due to limited reusability of sensor nodes that adds
cost and shortens node battery life. In addition, implementation of new
smart home applications will essentially imply installing more sensor nodes,
and hence the transmission of all sensed data from these nodes will rep-
resent an overload on the network, and leads to increasing its latency due
to the increased probability of collision. Conversely, 5G networks demand
stringent latency specifications [6].
2) Interoperability in Heterogeneous Networks: IoT smart home applications
involve installing a large number of sensing nodes from various manufac-
turers with essentially different wireless access technologies such as ZigBee,
Bluetooth Low Energy (BLE), and Wi-Fi [7]. Two nodes employing different
technologies cannot achieve direct machine-to-machine (M2M) communi-
cations and thus are incompatible [12,13]. For example, in a home security
application, a motion sensor that uses Bluetooth technology will not be able
to trigger a camera that uses Wi-Fi technology to capture a picture of an
intruder. A straightforward solution to this problem is to employ a gateway
server to connect these nodes, however, this solution has drawbacks such as
cost, difficulty of usage, and maintenance [14].
3) Application Development: The conventional approach for developing smart
home applications is usually tailored for a specific sensor node type, and re-
quires the developer to be well aware of low-level details of node operating
system and programming, sensor operation, and its wireless access tech-
nology. It becomes even more challenging to develop an application that
C16 Date: May 31, 2018 Time: 11:17 pm
16.2 Service-Oriented Architecture 579
supports interoperability of heterogeneous sensors that use different trans-
mission technology and/or run on different operating systems [12,15,16].
As a result, the overall application developmenttime and cost are high.
In this chapter, we introduce our proposed solution for the already men-
tioned problems. We present a novel service-oriented architecture that relies
on the concept of sensor virtualization, where the low-level functionalities of
sensor nodes are abstracted into a group of services that are made available to
the application developer, eliminating the need for the developer to be aware of
low-level details. This is achieved through development of highly scalable mid-
dleware that establishes interoperability between heterogeneous sensor nodes,
and optimizes resource utilization. The proposed solution has the following
state-of-the-art contributions:
∙Smart management and utilization of WSN resources, where the redundancy
in sensing data acquisition and transmission are minimized, and hence sens-
ing node battery life is maximized.
∙Ensures minimum network latency by limiting the data packets transmitted
by sensor nodes, which in turn minimizes the probability of packet collision.
∙Enables implementing new smart home applications without adding new
sensor nodes by reusing services provided by the existing nodes.
∙Hides low-level details of sensor node functionality and connectivity from the
application developer, which reduces application development time, effort,
and cost.
∙Enables seamless M2M communication between nodes that use different
wireless technologies without using a gateway.
∙Improves overall network reliability, where a data from a faulty sensor used
by one application can be automatically replacedby data from another sensor
used by another application in close proximity.
The proceeding section will describe the basic service-oriented architecture,
followed by related works in the implementation of service-oriented architec-
ture in wireless sensor network application. Next, the proposedservice-oriented
architecture for home area network will be explained in Section 16.4 with its
performance analysis presented in Section 16.5. Finally, the conclusion is drawn
in Section 16.6.
16.2 Service-Oriented Architecture
Service-oriented architecture is a distributed software architecture that consists
of multiple autonomous services. Services are distributed such that they can
execute on different nodes with different service providers [17]. A service is
comprised of a set of functions and each function defines the operation that
C16 Date: May 31, 2018 Time: 11:17 pm
580 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
Service directory
Publish service
Reply
Service query
Provide services
Request serviceService provider Service consumer
Figure 16.1 Basic operation of service-oriented architecture.
can be executed by the service and whether these operations are provided or
required [18].
Figure 16.1 shows the basic operation of service-oriented architecture.
Service-oriented architecture is divided into three elements: service provider,
service directory, and service consumer. The service provider is responsible to
design and develop the service. The developed service information will be pub-
lished into the service directory. The services inside the service directory will
publish the service information into the network. When the service consumer
requires the service, service consumer requests the service information from
the service directory and binds with the service provider to invoke the services.
The advantage of using service-oriented middleware is modularity, au-
tonomous operation, and well-defined interface by which the service can be
described, published, invoked, and discovered over network. The develop-
ment of service-oriented middleware should provide the following features
[16,19,20]:
Abstraction. The middleware system should hide as much as possible of the
heterogeneity of underlying environment from the developer.
Interoperability. Services should have ability to interact with different service
providers and wireless technologies.
Scalability. The middleware should have the capability to support a huge
number of sensor nodes or users in term of accessibility, and also provides
efficient query optimization.
Resource Utilization. The service may receive a large number of similar
requests in a relatively short period of time. By using mechanisms, such as
request similarity detection and caching, the service may be able to answer
most of the requests without requesting the same data again.
C16 Date: May 31, 2018 Time: 11:17 pm
16.3 Related Work 581
Cost Reduction. The services are expected to be reusable and often generic
in order to reduce application development cost.
Adaptability. The system should be able to adapt to network or environment
changes to maintain continuity of the communication system.
Topology. To provide a mechanism to support the ever-changing network
topology and guarantee its robustness.
Extensibility. To be able to add new sensor types or new data operators to
the software installed at the network nodes.
Programmability. It should be flexible, allowing for configuration or recon-
figuration of its features and functionality in the real time.
The mentioned features form the basis of the proposed service-oriented ar-
chitecture, specifically designed for a home area network that consists a large
number of heterogeneous devices and various applications. The main contri-
butions of the proposed architecture include a better utilization of available
devices, higher energy efficiency, and reduced latency. Consequently, the pro-
posed work offers a promising solution for device and sensor management in a
residential setting.
16.3 Related Work
Recently, several efforts have been carried out on the implementation of service-
oriented architecture into wireless sensor network middleware for various ap-
plications. Table 16.1 shows the summary of existing service-oriented middle-
ware features.
A Web Service Middleware for Ambient Intelligence (aWESoME) [21] is a
middleware developed to address the issues of universal, homogenous access to
the system function and fulfill functional and nonfunctional requirements from
the system architecture. It is based on ambient intelligence environment and
consumes low power without compromise, with reliability, and fast response
time. Service broker has been used for registering and providing the service.
USEME [22] middleware allows the combination between microprogram-
ming and node-centric programming to develop real-time and efficient ap-
plication for wireless sensor and actuator network. It provides the real-time
specification between services, uses group network structure, and supports
dependent-free platform. The USEME middleware allows the developer to
create application without knowing the low-level detail and repetitive task in
heterogeneous wireless sensor network.It is suitable for various wireless sensor
network application developments.
HERA [23] is an upgraded version of services layer over light physical device
(SYLPH), which is based on a distributed platform and implemented using an
SOA approach into heterogeneous wireless sensor network. The HERA archi-
C16 Date: May 31, 2018 Time: 11:17 pm
582 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
Table 16.1 Summary of the existing service-oriented middleware features.
Middleware Main Features Disadvantage
aWESoME •Supports universal and ho-
mogenous access to system
function
•Supports functional and
nonfunctional require-
ments
•Able to expose function and
data from various devices
•Only tackles interoperability problem
•Does not support code reusability
•Uses third-party software, therefore,
modifying the programming at gateway
is not possible
•Centralized topology results in every-
thing being done at the base station.
Node just sends the data to the base sta-
tion
USEME •Allows combination of
macro-programming and
node centric programming.
•Supports and allows the
specification of real-time
constrain between services
•Permits use of groups
to structure the network
platform independently
•Requires cluster head to manage the
group
•The cluster head will store all the infor-
mation about the node member
HERA •Allows different wireless
technologies of the device
to work together in a dis-
tributed way
•The platform is specially
designed to implement
hardware agent
•Capable of recovering from
error and more flexible
to adjust its behavior in
execution time
•High latency during the initialization of
HERA agent
•Requires many initial packet for HERA
initialization
•More focus on the service delivery
𝜇SMS •Applies a virtual sensor
service method using in-
network agentbased ser-
vices
•Uses event model and pub-
lishes/subscribes for ser-
vice discovery
•Sensor information will be sent to the
gateway before service formation
•One sensor for one sensor node
KASO •Integrates the WSN into
cloud service
•Offers advanced and en-
riched pervasive service to
everyone connected to In-
ternet
•Supports event-based and
on-demand service
•Requires cluster head to operate
•Only cluster head be able to communi-
cate to the sink node
•Two-level service composition at the
sensor node and cluster head
C16 Date: May 31, 2018 Time: 11:17 pm
16.3 Related Work 583
Table 16.1 Continued
Middleware Main Features Disadvantage
OASIS •Provides abstractions ob-
ject centric
•Supports ambient aware
•Provides tracking applica-
tion
•Only focuses on developing abstraction
for object-centric application
•Does not describe the method of data
collection from multiple sensors on a
single node and create the service
•Service-oriented architecture design
provides the standard data representa-
tion, information of service interface,
and service discovery
TinySOA •Independent programming
language
•Does not support multiple sensors on a
single node
tecture can operate into various sensor nodes platform with independent wire-
less technology, architecture, and programming language. It also uses reactive
agents with case-based planning features to recover from error by considering
the previous history. Generally, HERA can work together with wireless devices
from different technologies in a distributed way.
A micro-subscription management system (𝜇SMS) [24] middleware has been
proposed for smart infrastructure over wireless sensor networkby using service-
oriented architecture as a software architecture. The approach of this middle-
ware is to specify and develop the notion of virtual sensor services created for
smart environment via sensor network from tiny in-network services by using
agent-based technology. The developed middleware provided medical status
monitoring, perimeter surveillance, and location tracking. Generally, the main
purpose of this middleware focuses on translating the wireless sensor network
architecture into Internet-based architecture for world smart digital ecosystem.
Knowledge-Aware and Service-Oriented (KASO) [25] middleware tries to
integrate the wireless sensor and actuator network with service cloud. The
main key element of KASO is to offer advance and enrich pervasive services to
everyone connected to Internet. It will implement mechanism and protocol that
allows managing the knowledge generated in pervasive embedded networks in
order to disclose it to Internet user in a readable way. The energy consumption,
memory, and bandwidth are considered in developing of KASO middleware.
OASIS [26] middleware provides abstraction for object-centric, service-
oriented sensor network application, and ambient aware. It also provides loca-
tion tracking to track the heat source. The programming framework for OASIS
enables the program developer not to deal with low-level system and network
issues and also provides well-definedmodel. It also decomposesspecified appli-
cation behavior and produces the suitable node-level code for placement into
the sensor network. The development of middleware based on function block
C16 Date: May 31, 2018 Time: 11:17 pm
584 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
programming abstraction in Reference [19] provides reprogramming of sensor
node with new applications by injecting the base station with a mobile agent.
It also facilitates flexibility and adaptability features by making their operation
more complete and efficient even in dynamic environment and at the same time
keeping the complexity and overhead programming low. Wiring concept has
been used to link between function blocks in order to develop the application.
This method will hide the underlying hardware and software complexity from
the application developer.
TinySOA [28] is a service-oriented architecture middleware that lets pro-
grammers access WSN from their application based on a simple service-
oriented API over their own language programming. The approach does not
take into the account the nonfunctional capability. It consists of four compo-
nents such as gateway, node, server, and registry. The scope of TinySOA is to
cover monitoring and visualization application. The general target of TinySOA
is to facilitate the technique developer control and access of wireless sensor
network and incorporate them into application implementation.
In summary, most of the existing service-oriented middleware developments
focus on improving the abstraction and reducing the code(tm)s complexity in
order to simplify the application programmer in developing and integrating
the applications. In addition, many of the current service-oriented middleware
works are centralized in nature where the data collectedby the sensor node will
be sent to the cloud. The sensor data gathered by the sensor node is not able
to be transmitted directly to the base station. It needs to go through the cluster
head before being forwarded to base station. The focus also concentrates more
on the service delivery. By focusing on the service delivery, more packet needs
to be introduced in order to ensure the service reaches the destination. This
will result in an increase in latency.
16.4 Service-Oriented Architecture for Home Area
Network (SoHAN)
In this section, a more detailed description of the proposed SoHAN architecture
is described.
16.4.1 SoHAN Network
Figure 16.2 shows the proposed SoHAN network. The SoHAN network archi-
tecture is organized into four main parts, including home area network (HAN),
5G network, server, and monitoring devices.
The components of HAN are divided into two parts: sensor nodes and home
gateway. Wireless sensor nodes are responsible to collect and process data
sensed from the environment and send them to the gateway through other
C16 Date: May 31, 2018 Time: 11:17 pm
16.4 Service-Oriented Architecture for Home Area Network (SoHAN) 585
Figure 16.2 Proposed SoHAN network solution.
sensor nodes within the HAN. The typical sensor node consists of one or more
sensors that sense the environment, a processing unit such as microcontroller
to analyze the sensor data, and a wireless communication module to send the
processed data to the gateway. Each sensor node is equipped with a sensor and
an actuator to perform sensing and control operations, respectively. The sensing
operation includes temperature, humidity, fire, physiological signals, and light
in the home environment, while controling operation includes air conditioner,
washing machine, security system, television, and electric kettle. The wireless
sensor node in the proposed SoHAN middleware is implemented within mesh
network. In the mesh network, each sensor node is capable of relaying the
message from the origin to destination by using a routing technique or flooding
technique. All the sensor nodes are located inside the home.
The home gateway is responsible for enabling communication between the
sensor node and server via the 5G network. The gateway relays the message
from the sensor node to the server. At the same time, the gateway is also
responsible for channeling the message from the server to the destination node
within the HAN. The gateway in the proposed SoHAN is located within the
house premises.
A server plays a main role in the SoHAN system architecture. The server
contains a repository that consists of detailed information about the HAN
applications, such as temperature sensing data, wireless sensor node status,
wireless sensor node location,network status, home appliancesstatus, services,
and the elderly health status. The huge amount of information received from
C16 Date: May 31, 2018 Time: 11:17 pm
586 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
the nodes will be processed by analyzing and aggregating them based on the
requirement of system application. The decision or response based on that
process will also be carried out by the data center. For example, in the process
to trigger fire alarm, the normal routine is that the temperature node sends the
temperature reading to the data center for logging. If the temperature reading
exceeds some threshold, the data center will determine the location of that
wireless sensor node and starts to activate the fire alarm and sprinkler actuator
node to prevent the spread of the fire.
The user will access and request data from the server and wireless sensor
nodes via the Internet in order to create a monitoring or controlling system. To
monitor the data located at the server, a monitoring device such as smart phone,
tablet, notebook, or a personal computer can been used. End users options are
not only limited to request and display data, but also to be able to receivesystem
notification, control and check the status home appliances remotely via their
monitoring devices.
16.4.2 Proposed SoHAN Architecture
The proposed SoHAN architecture is organized into three main sections: sen-
sors, services, and applications as shown at Figure 16.3. Sensors section rep-
resents the number, type, and capability of the sensors available within the
SoHAN architecture. The services section shows the number and type of pos-
sible services that can be generated based on the sensors attached to the sensor
nodes. The combination of the servicesexisting in the SoHAN architecture will
create the application and resides at the application section.
Sensor section consists of the sensors or actuators attached to the sensor
node. It represents the existence of the various heterogeneous sensors in the
HAN network. All the sensor nodes are independent. The sensor data are the
values generated by either the sensors or by the actuators such as actuator
status. Typical examples of sensors include gap sensor, smoke sensor, tem-
perature sensor, motion sensor, and camera. On the other hand, examples of
actuators include magnetic door lock, siren controller, and fire sprinkler system
controller. The number of sensors and actuators attached to the sensor node
can be more than one sensor and one actuator.
The service section contains the services offered by the SoHAN architecture.
A service is a combination of the functionalitiesof sensors and actuators residing
on a single sensor node. The maximum possible numb er of services is dependent
on the number of sensor and actuators attached to a single node. For example,
let us say we have one sensor node with a gap sensor and a magnetic door
lock. The gap sensor is responsible to detect the door status either open or
closed, and the magnetic door lock operation is to lock and unlock the door.
The total number of services that can be generated fromthis sensor node is only
three: door status service that checks whether the door is open or closed, door
C16 Date: May 31, 2018 Time: 11:17 pm
16.4 Service-Oriented Architecture for Home Area Network (SoHAN) 587
Gap sensor
Magnetic door lock
Smoke sensor
Temperature
Siren
Camera
Motion sensor
Sensor Service Application
Surveillance monitoring system
Smart fire monitoring system
Smart intruder application
Fire detection service
Alarm service
Video and image service
Motion detection service
Door status service
Door lock service
Door locking system service
Home security system
Figure 16.3 Proposed SoHAN architecture.
lock service that enables locking/unlocking the door, and door locking system
service that combines the functionalities of both aforementioned services. The
services can be created by the combination of sensors/actuators residing on the
same sensor node only. Services are provided by node sharing data generated
by the sensors attached to the same node.
For example, with reference to Figure 16.3, consider the two services oper-
ating on the same node: video and image and motion detection services. The
latter only requires data from the motion sensor, while the former also requires
the motion sensor data to activate the security camera. As a result, two services
used data from the same sensor without requiring separate sensors. Therefore,
the SoHAN middleware features provide interoperability between the sensor
data and service when one sensor data can be utilized by two or more services
at one time.
Application section consists of the number of possible applications that can
be formed based on the services available at the service section. The applica-
tions are designed by integrating the multiple services offered by HAN nodes.
Application can be composed of more than one service. Unlike services, appli-
cations can utilize services provided by different nodes. For example, the smart
C16 Date: May 31, 2018 Time: 11:17 pm
588 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
Application layer
SoHan Middleware layer
Network layer
Medium access control layer
Physical layer
Figure 16.4 SoHAN network architecture.
fire monitoring system application is an integration of services such as alarm
service, fire detection service, and door locking system service. With reference
to Figure 16.3, alarm and fire detection services are providedby the same node,
while door locking system service is provided by another node. In this system
application, when the fire detection service is triggered, the alarm service and
door locking system service will be invokedas well. The alarm service operation
will activate the siren and the door locking system will automatically unlock
the door when fire is detected.
In SoHAN architecture, a single service also can be shared by multiple appli-
cations at the same time. For example, home security system application and
smart fire monitoring system application. Home security system application in-
tegrates motion detection service, video and image service, alarm service, and
door locking system service. Here we can see that both applications share the
alarm service. This feature makes SoHAN architecture highly flexible, where
the developer does not need to develop new services or acquire a new sensor
node if the service is provided by an existing node. Figure 16.4 illustrates the
position of SoHAN middleware layer compared to the OSI reference model.
SoHAN middleware layer is located between the network layer and application
layer. The SoHAN middleware layer consists of two sublayers, namely, sensor-
dependent sublayer and service-dependent sublayer. The sensor-dependent
sublayer mainly focuses on managing the sensor operation, while the service-
dependent sublayer focuses on managing the service in SoHAN architecture.
Both proposed sublayers are independent in terms of operation and implemen-
tation.
16.4.3 The Proposed SoHAN Middleware Framework
Figure 16.5 shows the proposed SoHAN middleware structure. SoHAN mid-
dleware structure mainly consist of two layer: sensor dependent layer and
C16 Date: May 31, 2018 Time: 11:17 pm
16.4 Service-Oriented Architecture for Home Area Network (SoHAN) 589
Sensor
aggregation
manager
QoS
manager
Sensor-dependent layer
Service-dependent layer
Sensor task
manager
Service
scheduling
manager
Service
registry
manager
Service
composition
manager
Service
discovery
Sensor
acquisition
manager
Figure 16.5 SoHAN middleware framework.
service-dependent layer. Sensor-dependent layer is responsible to manage the
sensor operation and service-dependent layer is responsible to manage the
serviceinSoHANmiddlewarestructure.
16.4.3.1 Sensor-Dependent Sub-layer
There are several component managers involved in the sensor-dependent
sublayer to manage the sensor activity in SoHAN middleware structure,
including sensor aggregation manager, sensor task manager, and sensor
acquisition manager.
Sensor Acquisition Manager The sensor acquisition manager is in charge
of issuing read requests to the sensor and receiving response data. Normally,
each sensor on the sensor node has three basic operations:sensor initialization,
sensor data register, and sensor data request. Sensor initialization is used to set
the sensor parameters before usage, such as analog-to-digital converter (ADC),
digital port, USART, and I2C setting. Sensor data register will be triggered
after sensor data request process is complete. Sensor data register will then
pass the requested data.
Sensor Task Manager Sensor task manager is the core manager in
sensor-dependent sublayer. Sensor task manager is responsible for handling
the multiple read request tasks initiated from the sensor aggregation manager
C16 Date: May 31, 2018 Time: 11:17 pm
590 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
to multiple sensors available on the sensor node. The requested sensor reading
tasks will be queued in the buffer. Sensor reading requests are processed
based on a first-in-first-out (FIFO) method. If two sensor reading requests are
received, the first will be processed, while the second is buffered. The second
request will be processed after the first sensor reading request is complete.
Sensor Aggregation Manager The sensor aggregation manager’s main op-
eration is to assemble and disassemble the sensor data required by each service.
The dissemble operation starts when the sensor-dependent sublayer receives
the service request from service-dependent sublayer. The sensor aggregation
manager converts the service request to a sensor request. When the process of
the sensor request is complete, the sensor result data will be assembled based on
the service request frame format and passed to the service-dependent sublayer
to process the service.
16.4.3.2 Service-Dependent Sublayer
Service-dependent sublayer is organized into five component managers to
manage the services in SoHAN middleware structure. It includes QoS manager,
service scheduling manager, service registry manager, service composition
manager, and service discovery manager.
QoS Manager QoS manager is responsible for assigning the priority level
for each services contained in the SoHAN middleware structure. Service
priority can be divided into three levels: high, normal, and low. The assigning
of priority level is based on service type. The assigning of service based on
priority is very important to make sure the service with high priority will be
served first compared with lower priority services.
Service Scheduling Manager Service scheduling manager is the main
part in service-dependent sublayer. It is responsible for handling the service
scheduling process. The service scheduling process will be executed based on
priority level assigned by the QoS manager.
Service Registry Manager The main operation of service registry manager
is to store the available services in the SoHAN middleware structure registry.
The service registry manager performs three tasks: adding a new service to the
registry, deleting a service when the service is not available, and lookup for
available services within the SoHAN middleware structure.
Service Composition Manager Service composition manager is responsible
for handling the multiple service combinations and for serving multiple ap-
plications in the SoHAN middleware structure. Service composition manager
enables a single service to be reused by multiple applications.
C16 Date: May 31, 2018 Time: 11:17 pm
16.5 Performance Evaluation 591
S1v1 (S1 ⊆ S)
a1 (V1 ⊆ V)
a2 (V2 ⊆ V)
ak (Vk ⊆ V)
v2 (S2 ⊆ S)
vm (Sm ⊆ S)
S2
S3
Sn
d
Figure 16.6 General network model for SoHAN.
Service Discovery Manager Service discovery manager is responsible for
discovering the services available from the sensor nodes within the SoHAN
middleware structure. It achieved this by broadcasting its services during its
initialization and the maintenance phase. Service discovery manager is also
responsible for updating the current status of a service in the registry.
16.5 Performance Evaluation
In this section, we evaluate the performance of our proposed architecture.
We start by describing the network model, and then we proceed to describe
the simulation setup, including the main parameters and reference scenarios.
Finally, we present and discuss the generated results.
16.5.1 Network Model
Figure 16.6 illustrates the network model for SoHAN middleware.
It consist of a sensor node denoted by 𝑑,towhich𝑛sensors are attached
denoted by ={𝑠1,…,𝑠
𝑛}.Thissensornodeiscapableofgenerating𝑚services
denoted by ={𝑣1,…,𝑣
𝑚}. Finally, 𝑘applications are constructed from the
available services denoted by {𝑎1,…,𝑎
𝑘}. In the proposed middleware, the
service can only be created using the data generated by sensors within the
same node. Only the related sensor data required by the service that meet the
application requirement will be sent to the base station or gateway.
16.5.2 Simulation Setup
We evaluate the performance of SoHAN middleware using a discrete event
simulator developed in MATLAB software and using IEEE 802.1.5.4 MAC
C16 Date: May 31, 2018 Time: 11:17 pm
592 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
Table 16.2 IEEE 802.14.5 MAC parameters setting.
IEE 802.15.4 MAC parameter Value
Collision avoidance scheme CSMA/CA
Maximum back-off time 5 cycles
Maximum number of retries 3 times
Header packet transmission duration 3 cycles
Sensor data packet transmission duration 7 cycles per sensor
protocol [29] as a reference standard model. Relevant parameter settings for
IEEE 802.15.4 MAC protocol used in our simulation were set according to
Table 16.2.
To simulate the real application of SoHAN architecture, we created two ap-
plications called 𝑎1and 𝑎2. Figure 16.7 shows the proposed applicationscenario
where 𝑎1is a combination between the service 𝑣1located at the sensor node
𝑑1and service 𝑣4located at the sensor node 𝑑2.Service𝑣1is based on data
generated by sensors 𝑠1and 𝑠2and service 𝑣4is based on data generated by
sensor 𝑠6. The second application is 𝑎2, where it is composed of service 𝑣2that
resides at sensor node 𝑑1and service 𝑣3that resides at sensor node 𝑑2.Service
𝑣2is based on data generated by sensor 𝑠3and 𝑣3is based on data generated by
sensors 𝑠7and 𝑠8. Figure 16.7 illustrates the two proposed applications. In our
S1
v1(S1 ⊆ {s1, s 2})
a1(V4 ⊆ {v1, v 4})
a2(V4 ⊆ {v2, v 3})
v3(S3 ⊆ {s7, s 8})
v2(S2 ⊆ {s3})
v4(S4 ⊆ {s6})
d1
d2
S2
S3
S4
S5
S6
S7
S8
Figure 16.7 Network model for simulation.
C16 Date: May 31, 2018 Time: 11:17 pm
16.5 Performance Evaluation 593
simulation, we set the probability of executing applications 𝑎1and 𝑎2to 0.005
and 0.0025, respectively.
We evaluate and compare the performance of the proposed SoHAN
framework with two other reference cases executing the same applications.
We describe the two cases as follows:
Case 1: In Case 1, the sensor node will send the sensor data based on the
application request. For example, if a sensor node has three attached sensors
and the application only requires data from two sensors, the sensor node will
send two sensor data packets, where each packet carries data from one of
the sensors. The total number of packets transmitted depends on how many
sensors are required to forward their data to the application.
Case 2: For Case 2, each sensor node will transmit all its sensor data together
in one packet regardless of whether the application requires data from these
sensors or not. For example, if a sensor node consists of four sensors and
application only needs data from two sensors, the sensor node will combine all
sensor data it has in one packet and send it to the application. In this case, the
total number of transmitted packets does not depend on the number of sensors
required to forward their data to the application. However, the transmitted
packet length depends on the type and number of sensors attached to each
node. Therefore, we may deduce that packet size in Case 2 is larger than or
equal to that of Case 1.
16.5.3 Results
The SoHAN framework performance evaluation is presented in this section.
SoHAN framework has been evaluated using four criteria, namely, packet loss,
packet latency, total packet generation, and energy consumption. Figure 16.8
shows the total number of packets dropped versus time for the proposed So-
HAN framework and the two references schemes, namely, Case 1 and Case 2.
From the displayed results, the average packet drop rate for the SoHAN frame-
work is calculated to be 3.17 × 10−3 packet/cycle, while for Case 1 and Case 2
is 9.5×10
−3 and 3.15 × 10−3 packet/cycle, respectively. The packet drop rate
for SoHAN framework is significantly less than Case 1 due to the fact that in
Case 1 each sensor data is transmitted in a separate packet, leading to a large
number of generated packets. Hence, the number of collisions increases. This
can be confirmed by referring to Figure 16.8, where the number of packets
generated versus time is illustrated. In Figure 16.9, the rate by which packets
are generated with time for Case 1 is 2.73 × 10−3 packet/cycle compared to
1.05 × 10−3 packet/cycle for SoHAN.
On the other hand, packet drop rate for SoHAN is comparable to that of
Case 2 since both follow a similar approach based on producing a single packet
C16 Date: May 31, 2018 Time: 11:17 pm
594 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
0 0.5 1 1.5 2 2.5
× 104
0
50
100
150
200
250
Time (cycle)
Number of packet drop
Case 1
Case 2
Proposed
Figure 16.8 Number of drop packet versus time.
0 0.5 1 1.5 2 2.5
× 104
0
10
20
30
40
50
60
70
80
Time (cycle)
Total packet generated
Case 1
Case 2
Proposed
Figure 16.9 Total packet generated versus time.
upon sensor data request. From Figure 16.9, packet generation rate for Case
2is0.7×10
−3 packet/cycle, which is less than SoHAN. However, packet size
produced in Case 2 is larger since it includes data from all sensors. Since the
probability of packet collision is directly proportional to packet generation rate
and packet size [27], similar packet drop rates are observed for Case 2 and
SoHAN.
Figure 16.10 shows the latency versus the number of cycles. It can be observed
clearly that SoHAN achieves lowerlatency than both Case 1 and Case 2 over the
wholetimespan.SoHANachievesanaveragelatencyof37 cycles compared to
53 cycles for Case 1 and 78 cycles for Case 2. This performance improvement
C16 Date: May 31, 2018 Time: 11:17 pm
16.5 Performance Evaluation 595
0 0.5 1 1.5 2 2.5
× 104
30
40
50
60
70
80
90
Time (cycle)
Latency (cycle)
Case 1
Case 2
Proposed
Figure 16.10 Average packet latency over time.
is referred to the fact that SoHAN transmits fewer packets than Case 1, hence
avoids latency caused by increased probability of collision. On the other hand,
SoHAN packet size is smaller than Case 2, hence it avoids latency caused by
long packet transmission time. Furthermore, consider that one cycle is equal
to one symbol duration (i.e., 16 𝜇s) [13,29], hence, the corresponding average
latencies are 0.85, 1.2 and, 0.59 ms for Case 1, Case 2, and SoHAN, respectively.
It is clear that SoHAN manages to achieve a latency below the target latency
for 5G systems that is, 1 ms [30].
Finally, Figure 16.11 illustrates the normalized energy consumption versus
time in cycles. With reference to parameters in Table 16.3, energy consumption
in packet transmission can be calculated as 𝐸=𝑁𝑝𝑁𝑏𝐸𝑏. On the other hand,
normalized energy consumption is calculated as
𝐸=𝐸∕𝐸𝑏=𝑁𝑝𝑁𝑏.Weob-
serve that SoHAN consumes less energy over time than both Case 1 and Case
2. SoHAN achieves average normalized power consumption of 14.23 × 10−3
cycle−1 compared to 27.25 × 10−3 and 21.6×10
−3 cycle−1 for Case 1 and Case
2, respectively, where normalized power consumption is defined as normalized
energy consumption per cycle.
Table 16.3 summarizes the performance criteria achieved in the presented
case studies. We observe that packet drop rate for SoHAN is 67% less that Case 1
and only 0.6% higher than Case 2. Packet generation rate for SoHAN is 62% less
that Case 1 and 50% higher than Case 2. Therefore, we can deduce that SoHAN
performance in terms of the aforementioned criteria is significantly improved
compared to Case 1, while basically similar to Case 2. On the other hand,
for average latency and power consumption, SoHAN achieves performance
improvement over both Cases, by which SoHAN average latency is 30% less
than Case 1 and 52% less than Case 2, and power consumption 48% less than
C16 Date: May 31, 2018 Time: 11:17 pm
596 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
0 0.5 1 1.5 2 2.5
× 104
0
100
200
300
400
500
600
700
800
Time (cycle)
Normalized energy consumption
Figure 16.11 Normalized energy consumption versus time.
Table 16.3 Summary of SoHAN performance evaluation.
Criterion Case 1 Case 2 SoHAN
Packet drop rate (packet/cycle) 9.50 × 10−3 3.15 × 10−3 3.17 × 10−3
Packet generation rate (packet/cycle) 2.73 × 10−3 0.70 × 10−3 1.05 × 10−3
Average latency (cycle) 53.00 76.80 36.98
Normalized power consumption (cycle−1 )27.25 × 10−3 21.60 × 10−3 14.23 × 10−3
Case 1 and 34% less than Case 2. Therefore, SoHAN achieves a significant
overall performance improvement compared to the other studied Cases.
16.6 Conclusion
This chapter presents the service-oriented middleware architecture for efficient
Internet of Things (IoT) home area network in 5G. The SoHAN architecture
is organized into three divisions, namely, sensor, service, and application. Sen-
sor acts as a service provider, while the service acts as a service directory
and followed by the application as a service consumer. The SoHAN middle-
ware layer consists of two sublayers, namely, sensor-dependent sublayer and
service-dependent sublayer. The sensor-dependentsublayer focuses on the sen-
sor management while the service-dependent sublayer concentrates on service
operation.
C16 Date: May 31, 2018 Time: 11:17 pm
References 597
The SoHAN performance evaluation was carried out by comparing two
conventional methods and the result was promising in terms of reliability,
latency, and power consumption. This work provides smart management and
enhances resource utilization in home area network. It promotes cost efficiency
by reusing the services offered by the existing sensor node in composing new
application by minimizing the complexity of low-level details from application
developer.
References
1A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash, “Inter-
net of Things: a Survey on enabling technologies, protocols, and applications,”
IEEE Commun. Surv. Tutor., vol. 17, no. 4, pp. 2347–2376, 2015.
2W.Ejaz,A.Anpalagan,M.A.Imran,M.Jo,M.Naeem,S.B.Qaisar,andW.
Wang, “Internet of Things (IoT) in 5G wireless communications,” IEEE Access,
vol. 4, pp. 10310–10314, 2016.
3ABI Research, More than 30 billion devices will wirelessly connect tothe Internet
of Everything in 2020, 2013.
4T. Danova, Morgan Stanley: 75 billion devices will be connected to the Internet
Of Things by 2020, 2013.
5D. Evans, The Internet of Things: How the Next Evolution of the Internet Is
Changing Everything, CISCO white paper, 2011.
6I.F.Akyildiz,S.Nie,S.-C.Lin,andM.Chandrasekaran,“5Groadmap:10key
enabling technologies,” Comput. Netw., vol. 106, p. 17–48, 2016.
7M.R.Palattella,M.Dohler,A.Grieco,G.Rizzo,J.Torsner,T.Engel,andL.
Ladid, “Internet of Things in the 5G era: enablers, architecture, and business
models,” IEEE J. Select. Areas Commun., vol. 3, no. 34, pp. 510–527, 2016.
8G. Eastwood, A Guide to 5G Drivers and Vertical Applications,vol.11,pp.
4380–4392, 2017.
9M. S. Obaidat and P. Nicopolitidis, “Smart Cities and Homes: Key Enabling
Technologies,” Elsevier, 2016.
10 O. Vermesan and P. Friess, Internet of Things: Converging Technologies for Smart
Environments and Integrated Ecosystems, River Publishers, 2013.
11 O. Vermesan and P. Friess, Internet of Things Applications: From Research and
Innovation to Market Deployment, River Publishers, 2014.
12 N. Mohamed and J. Al-Jaroodi, “A survey on service-oriented middleware for
wireless sensor networks,” Serv. Oriented Comput. Appl., vol. 2, no. 5, pp. 71–85,
2011.
13 M.A.Sarijari,A.Lo,M.S.Abdullah,S.H.D.Groot,I.G.M.M.Niemegeers,
and R. A. Rashid, “Coexistence of heterogeneous and homogeneous wireless
technologies in smart grid-home area network,” 2013 International Conference
on Parallel and Distributed Systems, 2013, pp. 576–581.
C16 Date: May 31, 2018 Time: 11:17 pm
598 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
14 M. R. B. A. Rahim, N. Fisal, R. A. Rashid, and Z. Khalid, “A service oriented mid-
dleware for smart home and ambient assisted living,” in 2015 1st International
Conference on Telematics and Future Generation Networks (TAFGEN), 2015, p.
49–53.
15 J. Leguay, M. Lopez-Ramos, K. Jean-Marie, Kathlyn and V. Conan, “An efficient
service oriented architecture for heterogeneous and dynamic wireless sensor
networks,” 2008 33rd IEEE Conference on Local Computer Networks (LCN),
2008, pp. 740–747.
16 A. Rezgui and M. Eltoweissy, “Service-oriented sensor-actuator networks:
promises, challenges, and the road ahead,” Comput. Commun., vol. 13, no.
30, pp. 2627–2648, 2007.
17 H. Gomma, Software Modelling and Design, Cambridge University Press, 2011.
18 E.Canete,J.Chen,M.Diaz,L.Llopis,andB.Rubio,“Aservice-orientedapproach
to facilitate WSAN application development,” Ad Hoc Netw., vol.3,no.9,pp.
430–452, 2011.
19 J. Al-Jaroodi and N. Mohamed, “Service-oriented middleware: a survey,”J. Netw.
Comput. Appl., vol. 1, no. 35, pp. 211–220, 2012.
20 I. Chatzigiannakis, G. Mylonas, and S. Nikoletseas, “50 ways to build your ap-
plication: a survey of middleware and systems for wireless sensor networks,” in
IEEE Conference on Emerging Technologies and Factory Automation, 2007.
21 T. G. Stavropoulos, K. Gottis, D. Vrakas, and I. Vlahavas, “aWESoME: a web
service middleware for ambient intelligence,” Expert Syst. Appl., vol. 11, no. 40,
pp. 4380–4392, 2013.
22 E. Caete, J. Chen, M. Diaz, L. Llopis, and B. Rubio, “USEME: a service-oriented
framework for wireless sensor and actor networks,” in Eighth International
Workshop (ASWN ’08), 2008, pp. 47–53.
23 S.R.Alonso,D.I.Tapia,J.Bajo,O.Garcia,J.F.dePaz,andJ.M.Corchado,“Im-
plementing a hardware-embedded reactive agents platform based on a service-
oriented architecture over heterogeneous wireless sensor networks,” Ad Hoc
Netw., vol. 1, no. 11, pp. 151–166, 2013.
24 M. S. Familiar, J. F. Martnez, I. Corredor, and C. Garca-Rubio, “Building service-
oriented smart infrastructures over wireless ad hoc sensor networks: a middle-
ware perspective,” Comput. Netw., vol. 4, no. 56, pp. 1303–1328, 2012.
25 I. Corredor, J. F. Martnez, S. M. Familiar, and L. Lourdes, “Knowledge-aware and
service-oriented middleware for deploying pervasive services,” J. Netw. Comput.
Appl., vol. 2, no. 35, pp. 562–576, 2012.
26 M. Kushwaha, I. Amundson, X. Koutsoukos, N. Sandeep, and J. Sztipanovits,
“OASiS: a programming framework for service-oriented sensor networks,” in
2nd International Conference on Communication Systems Software and Mid-
dleware, 2007, pp. 1–8.
27 S.H.Nguyen,H.L.Vu,andL.L.H.Andrew,“Packetsizevariabilityaffectscolli-
sions and energy efficiency in WLANs,” in 2010 IEEE Wireless Communication
and Networking Conference, 2010, pp. 1–6.
C16 Date: May 31, 2018 Time: 11:17 pm
References 599
28 E. Aviles-Lopez and J. A. Garca- Macas, “TinySOA: a service-oriented architec-
ture for wireless sensor networks,” Serv. Oriented Comput. Appl., vol. 2, no. 3,
pp. 99–108, 2009.
29 IEEE Computer Society, IEEE Standard for Information Technology -
Telecommunications and Information Exchange Between Systems - Local
and Metropolitan Area Networks Specific Requirements Part 15.4: Wireless
Medium Access Control (MAC) and Physical Layer (PHY) Specifications for
Low-Rate Wireless Personal Area Networks (LR-WPANs), 2003, pp. 1–670.
30 P.Schulz,M.Matthe,H.Klessig,M.Simsek,G.Fettweis,J.Ansari,S.A.Ashraf,
B. Almeroth, J. Voigt, I. Riedel, A. Puschmann, A. Mitschele-Thiel, M. Muller, T.
Elste, and M. Windisch, “Latency critical IoT applications in 5G: perspective on
the design of radio interface and network architecture,” IEEE Commun. Mag.,
vol. 2, no. 55, pp. 70–78, 2017.
Mohd Rozaini bin Abd Rahim received the B.Eng and master’s degrees from Q1
the University Teknologi Malaysia, in 2007 and 2011, respectively, both in
electrical engineering. He is currently pursuing the Ph.D. degree with the Ad-
vanced Telecommunication Technology (ATT)Research Group. His research
interest include wireless sensor network, service-oriented middleware, and
wireless biomedical sensor network.
Rozeha A. Rashid received her B.Sc. degree in electrical and electronic
engineering from the University of Michigan, Ann Arbor in 1989. She
received her M.E.E. and Ph.D. degrees in telecommunication engineering
from Universiti Teknologi Malaysia (UTM) in 1993 and 2015, respectively.
She is a senior lecturer in the Department of Communication Engineering,
Faculty of Electrical Engineering, Universiti Technologi Malaysia. Her research
interests include wireless communications, sensor network, cognitive radio,
and Internet of Things.
Ahmad M. Rateb received his Ph.D. in 2013 from Universiti Teknologi
Malaysia (UTM), Malaysia. Currently, he is with the Advanced Telecommuni-
cation Technology research group (ATT) in UTM as a postdoctoral research
fellow. His research interest covers compressed sensing, 5G communications,
and cognitive radio technology.
M.A.B (Mohd Adib bin) Sarijari received his bachelor’s degree in engineering
(first class, and with honors) in 2007, and the Master of Science in electrical
C16 Date: May 31, 2018 Time: 11:17 pm
600 16 Service-Oriented Architecture for IoT Home Area Netwo rking in 5G
engineering in 2011, both from Universiti Teknologi Malaysia (UTM), Johor,
Malaysia. In 2012, he received his Ph.D. from Delft University of Technology,
the Netherlands. He is currently a senior lecturer at the Department of
Communication Engineering, Faculty of Electrical Engineering, UTM. His
general research interest lies in the field of communications, optimization,
and system design. In particular, he is interested in cognitive radio, home area
networks, wireless sensor networks, software defined radio, smart home, and
smart city.
Ahmad Shahidan Abdullah received the B.Eng. degree in telecommunication
engineering and Ph.D. degree in electrical engineering from the Universiti
Teknologi Malaysia (UTM), Johor Bahru, Malaysia, in 2009 and 2014,
respectively. In 2009, he joined the Communication Engineering Department,
Faculty of Electrical Engineering, UTM, as a tutor, and later as a lecturer,
in 2014. His current research interests include channel and network coding,
wireless sensor networks, and IoT applications.
Abdul Hadi Fikri Abdul Hamid received the B.Eng. degree from the
Universiti Teknologi Malaysia, in 2007, and the master’s degree from the same
university, in 2011, both in electrical engineering. He is currently pursuing
the Ph.D. degree with the Advanced Telecommunication Technology (ATT)
Research Group in UTM. His research interests include wireless sensor
network, cognitive Radio, and embedded system.
Hamdan Sayuti received the B.Eng. degree in computer engineering and the
master’s degree from the Universiti Teknologi Malaysia (UTM), Johor Bahru,
Malaysia, in 2007 and 2016, respectively. He is currently a research officer at
UTM. His research interests include wireless sensor network, IoT system, and
cloud system design.
Norsheila Fisal received her B.Sc. degree in electronics communication
from the University of Salford, Manchester, United Kingdom, in 1984,
M.Sc. degree in telecommunication technology, and Ph.D. degree in data
communication from the University of Aston, Birmingham, United Kingdom,
in 1986 and 1993, respectively. Currently, she is a professor with the Faculty
of Electrical Engineering, Universiti Technologi Malaysia, and the head of the
UTM-MIMOS Telecommunication Technology Research Group.
C16 Date: May 31, 2018 Time: 11:17 pm
Author Query
Q1 Kindly provide us the photosfor Mohd Rozaini bin Abd Rahim, Rozeha A.
Rashid, Ahmad M. Rateb, Mohd Adib bin, Ahmad Shahidan Abdullah, Abdul
Hadi Fikri Abdul Hamid, Hamdan Sayuti and Norsheila Fisal.
