A cross layer protocol based on mac and routing protocols for healthcare applications using wireless sensor networks

International Journal of Advanced Smart Sensor Network Systems (IJASSN), Vol 4, No.1/2, April 2014
DOI:10.5121/ijassn.2014.4201 1
A CROSS LAYER PROTOCOL BASED ON
MAC AND ROUTING PROTOCOLS FOR
HEALTHCARE APPLICATIONS USING
WIRELESS SENSOR NETWORKS
Muhsin Atto1
and Chr Guy2
School of System Engineering University of Reading United Kingdom.
ABSTRACT
Using Wireless Sensor Networks (WSNs) in healthcare systems has had a lot of attention in recent years. In
much of this research tasks like sensor data processing, health states decision making and emergency
message sending are done by a remote server. Many patients with lots of sensor data consume a great deal
of communication resources, bring a burden to the remote server and delay the decision time and
notification time. A healthcare application for elderly people using WSN has been simulated in this paper.
A WSN designed for the proposed healthcare application needs efficient MAC and routing protocols to
provide a guarantee for the reliability of the data delivered from the patients to the medical centre. Based
on these requirements, A cross layer based on the modified versions of APTEEN and GinMAC has been
designed and implemented, with new features, such as a mobility module and routes discovery algorithms
have been added. Simulation results show that the proposed cross layer based protocol can conserve
energy for nodes and provide the required performance such as life time of the network, delay and
reliability for the proposed healthcare application.
KEYWORD
WSN, Healthcare Monitoring, Cross Layer,APTEEN,Mobility.
1. INTRODUCTION
Wireless Sensor Networks(WSNs) have recently attracted a great deal of attention from
researchers both in academia as well as industry. This is primarily due to their capability to
support promising applications in areas like health care, fitness, sports and the military. Providing
the required performance for WSNs is one of challenges which needs to be solved using
different protocols. A WSN is composed of tiny, battery powered devices, called sensor nodes.
The design and implementation of WSNs face several challenges, mainly due to the limited
resources and limited capabilities of sensor nodes, such as power and storage. To accomplish
their task, sensor nodes are required to communicate with each other and act as intermediate
nodes to forward data on behalf of others so that this data can reach the sink, which is responsible
for taking the required decision [1].
Recent studies have led to the development of small, intelligent, wearable sensors capable of
remotely performing critical health monitoring tasks using WSNs, and then transmitting patient’s
data back to health care centres over wireless medium. Such wireless health monitoring platforms
aim to continuously monitor mobile patients needing permanent surveillance. However, to set up
such platforms several issues along the communication chain should be resolved [2].

2
Routing is an essential feature in WSNs; in such networks, a node should have the capability to
deal with data transmission as required between source nodes and a sink in different situations.
These capabilities may cause consumption of extra energy. Hence, efficient MAC and routing
protocols need to be designed to enhance the lifetime of the network, and these protocols require
efficient algorithms to deal with different situations. In this paper, a cross layer protocol based on
APTEEN [3] and GinMAC [4] has been proposed, with new features such as multi-hops and
mobility modules have been implemented for the proposed application.
The rest of the paper is structured as follow. Motivations for the paper is given in Sections 2. The
implementation of APTEEN including the proposed mobility module are described in Section
3. A cross layer based protocol is debated in Section 4. The proposed healthcare including the
simulation scenarios and results are described in Sections 5. A conclusion and proposals for
future work are presented in Section 6.
2 MOTIVATIOS
The novel motivations for this paper are the following:
1. Design MAC and routing protocols for healthcare application where the required energy
sav-
1. ing, reliability and delay for delivered data need to be considered.
2. Design a mobility management module for the proposed application.
3. Design a cross layer protocol based on APTEEN and GinMAC to add new features to im-
prove its applicability to real-time applications which require mobility, such as
application as described in [5].
4. Simulate a cross layer implementation for the proposed application where different
scenarios
5. need to be considered.
3. CLUSTER BASED ROUTING PROTOCOL USING WSNS
Energy-efficient routing protocols have been proposed in the literature to deal with the limited
battery life of sensor nodes in order to increase the life time of the network. In general, routing
protocols are classified, based on the network structure, into flat, hierarchical and location based
protocols. In the hierarchical based routing protocols, nodes are divided into different clusters
with different roles. All nodes of flat routing based protocols are assigned the same role. In the
location-based protocols, the geographic information of nodes is used for relaying data . Cluster
based routing protocols have been often preferred over other routing protocols as some nodes take
a role behalf of others and hence energy can be saved and the life time of the network can be
extended [6].
The Low Energy Adaptive Clustering Hierarchy (LEACH) [6] is a cluster based routing pro-
tocol for WSN where energy can be conserved by distributing energy usage between nodes over
time. This protocol can not be used for applications where data do not need to be transmitted all
the time. Most of applications using WSN do not need high traffic rates, so based on this fea-
ture, the Hierarchy Threshold-sensitive Energy Efficient (TEEN) protocol [7] has been designed.
A TEEN lets nodes transmit their data only when this data is in the range of the interest based on
some thresholds, otherwise, data is discarded. Based on this, users may not be updated with data
for a long time, because data is not satisfying the given thresholds. Adaptive Periodic Threshold-
sensitive Energy Efficient (APTEEN) [3] has been proposed to solve the problems associated

3
with both LEACH and TEEN using Counter Time CT and handling queries. APTEEN has been
selected in this paper because of the following important features:
1. By sending query over time to the different parts of the network, users can have a
complete picture of the network.
2. It can be used for critical and non critical delivered data related applications by using
different thresholds. This allow users to choose thresholds according to the requirements
of the proposed applications.
3. Energy can be conserved by distributing the load of the energy usage between nodes in
the network.
4. Delay can be decreased and energy can be conserved by aggregating and reducing
redundant copies of data at the intermediate nodes in the network.
5. Nodes in each cluster need only send their data to their cluster heads over one single hop
using their allocated slots, so energy is conserved.
6. Only cluster heads are involved for routing and forwarding data toward a sink, this
reduces the routing complexity in large WSNs.
7. Only cluster heads need to aggregate data from their members thus saving energy.
8. Data are transmitted toward a sink using the best available links based on the different
link costs, such as Receiver Signal Strength Indicator (RSSI) and remaining energy.
3.1. Implementation of APTEEN for Real-time Applications
This implementation of APTEEN is based on LEACH [6] for selecting cluster heads and creating
the Time Division Multiple Access (TDMA) schedules. The APTEEN design given in [3] does
not support mobility, however, this implementation does so. A new algorithm has been designed
to discover routes dynamically for transmitting data toward a sink between nodes, based on the
different link costs, considering multi-hops cluster based topologies. Some scenarios are
simulated to validate this implementation in term of the required performance, such as energy,
delay and reliability for delivered data over multi-hops WSN based applications. A new mobility
module has been implemented to provide the required connectivity, when some nodes are mobile.
A TDMA for APTEEN implementation given in [3] has been modified to handle new features
such as thresholds and queries. More details about APTEEN and its implementation in this paper
are debated below.
3.1.1.An Overview of the APTEEN Protocol
APTEEN [3] is a self-configuration clustering based routing protocol which has been designed
for WSNs. This protocol uses a randomization related technique to distribute energy usage be-
tween nodes over time, which conserves energy and reduces collisions. Nodes are joined into a
set of different groups when they turn on their radios, each group is called Cluster, where nodes
belonging to each cluster are monitored by a special node which is called Cluster Head(CH). CHs
are assigned to have more power and energy than other nodes, to deal with TDMA creation and
data aggregation. Nodes send their data to their cluster heads and then go to sleep to save energy
and reduce collisions in the network. Cluster heads receive and aggregate this data and send it
back to higher cluster heads until this data is reached by a sink. Since cluster heads are selected
based on their remaining energy, then the chance of nodes dying quickly is low. Data aggregation
using APTEEN needs to be designed according to the requirements of the proposed applications.
APTEEN lets nodes transmit their data only when the sensed data is in the range of interest, based
on the given data thresholds. This will reduce the number of unnecessary transmissions and hence
allow APTEEN to be used for critical and non critical related applications using WSNs. Cluster
heads are selected based on the probability that each node has not been selected for a period of

4
time. When cluster heads are selected, they need to advertise themselves to the rest of the nodes
in the network. After the CHs advertisement, TDMA schedules are created and broadcast so that
the required slots for members can be allocated. After cluster heads are selected and TDMA
schedules for members are allocated, nodes can transmit their data to their cluster heads in which
this data will be aggregated and send it back to a sink [3]. An example of the cluster based
topology using WSN is given in Figure 1.
Figure. 1. Cluster based Topology [8]
3.1.2. Details of the APTEEN Protocol
The operations of the APTEEN protocol are divided into rounds, where each round starts with
three different phases which are set-up, routes discovery and data transmission. In the set-up
phase, nodes organize themselves into different clusters, where each cluster needs to be moni-
tored by a cluster head, followed by an advertisement phase, where cluster heads need to
advertise themselves to the nodes in the network. Non cluster heads ask to join to different
clusters, based on the different costs. In the route discovery phase, cluster heads are required to
find different routes for relaying data from members to a sink. Based on this, a new algorithm
needs to be implemented to select routes between CHs and a sink to take into account different
situations. In the data transmission phase, nodes start to send data to their selected cluster heads
over a singe hop communication and then go to sleep to save energy. APTEEN needs to be
scalable for different cluster based topologies, for instance single level and multiple levels cluster
based topologies.
3.1.3. Cluster Heads Selection Using APTEEN
As mentioned before, APTEEN uses a cluster heads selection technique used by LEACH[6], so
when each node turns on its radio, it needs to decide whether or not become a cluster head in the
current round. This decision is based on the suggested percentage of the nodes that needs to be
selected as cluster heads in the network and the number of rounds that this node has not been
selected as a cluster head yet. The selection of the node n to become a cluster head in the current
round depends on the probability of a random number between 0 and 1 which is denoted by (rn)
and the pre defined threshold value which is represented by T(n) as described in [6]. The T(n) is
defined as follow:

5
Where P is a percentage of cluster heads that need to be selected, r is the current round and G is a
set of nodes that have not been selected as cluster heads in the previous 1/P rounds. If rn is less
than T(n), then the node n is selected to be a cluster head in the current round r. One of the
drawback for the APTEEN probability algorithm for selecting cluster heads given in [6] is that a
sink does not consider the remaining energy for nodes when selecting cluster heads. Hence,
nodes may be prone to die in their early stages. Based on this problem, [8] proposed a new
solution by considering remaining energy for nodes before becoming cluster heads, using the
following equation:
where Ecur is current energy and Emax is initial energy of the node n. This algorithm lets the
sink selects nodes with the maximum remaining energy to be cluster heads in each round whilst
extends the life time of the network. The APTEEN implementation given in this paper is based
on this method for selecting cluster heads.
3.2. Multi-Hops Clustering and Routes Discovery Using APTEEN
The required algorithm for selecting routes over multi-hops between different nodes in the
network is not described in the APTEEN specifications given in [3], so a lot of options were
considered when this version of APTEEN was implemented. A new module to discover routes,
considering multi hops between clusters heads and a sink has been designed. This module
considers the remaining energy, location and RSSI for selecting different routes to forward data
toward a sink.
The APTEEN design given in [3] has been modified so that routes for delivered data between
cluster heads and a sink can dynamically be discovered using different link costs. While the sink
has global information about all nodes in the network, such as remaining energy and locations,
then in this implementation, the sink is assumed to be responsible for dividing the deployed
network into different levels. Based on this, cluster heads close to the sink are selected as first
level cluster heads and then these cluster heads send data to the sink via single hop
communication. However, nodes far away from the sink can be selected as low level cluster
heads. Low level cluster heads in the network are required to select higher level CHs to relay
their data toward a sink, based on the following three link costs: remaining energy, distance and
RSSI. Based on these metrics, the best routes are selected between nodes. Since only cluster
heads are involved in routes selection, then the energy consumption can be optimized, by simply
forcing the rest of the nodes to go to sleep.
3.2.1. Proposed Routes Discovery Algorithms Using APTEEN
A new algorithm has been designed to select next hops (routes) for cluster heads after their se-
lection, these algorithms are defined in 3.1. Some scenarios are simulated to evaluate the
modified APTEEN for the proposed applications using these algorithms. The proposed routes
discovery algorithms provide valid routes between cluster heads and a sink. CHs check first if
they have valid routes before sending data. In the case where no routes are available, then CHs
ask for urgent routes from their neighbours to send their data as soon as possible.

6
3.3. Thresholds Values Implementation Using APTEEN
APTEEN saves energy and reduces packet collisions from other nodes in the network by
reducing the number of the transmissions, using pre defined thresholds. These parameters need to
be ini- tialized according to the proposed application. After cluster heads selection, all of the
following parameters need to be broadcast in the network:
1. Attribute(A): This is a physical parameter which the user is interested in to collect data
about. For instance, collect the temperature of the a part of the environment and then send
it back to a sink, to take the required decision. Users can define different attributes to
collect different parameters from the deployed environments.
2. Hard Threshold(HT): Nodes need to be forced to transmit data when the current sensed at-
tribute is bigger than this value. In this case, nodes only need to transmit data in case
sensed data become above HT, otherwise data is ignored and then energy is conserved.
3. Soft Threshold(ST): This value represents the small change that force nodes to transmit
their sensed data.
4. Counter Time (CT): When nodes do not send data during this time period, then nodes are
forced to send their data any way. It is a time between two successive reports sent by
nodes. It can be multiple of frames. This parameter allows nodes to share the connection
even in case they do not have data to be transmitted.
Based on these parameters, APTEEN lets nodes transmit their data according to this equation:

7
Where SV and LSV are current and previous sensed values. These threshold values have been
used in this APTEEN implementation. In case sensed data from nodes are satisfying the given
thresholds as described above, then packets are forwarded to the network layer, however, if the
received data does not satisfy the given thresholds, data needs to be discarded. In this case, only
packets with data satisfying the given thresholds such as HT and ST are forwarded and
transmitted. Hence, the number of transmissions are reduced and both energy consumption and
collision are minimized. If nodes do not transmit their data, because of the data are not satisfying
the threshold values for a very long time, then APTEEN forces these nodes to transmit their data
using Counter Time CT. A CT is a period of time that nodes need to send their data, this implies
that user can update CT according to the requirement of the proposed applications.
3.4. A Modified TDMA Schedule Using APTEEN
Each newly selected cluster heads needs to allocate different slots for their members using
TDMA schedules, to let their members transmit data and handle queries. It has been assumed that
a sink creates and sends queries to different parts of the network and then nodes reply as soon as
they have data matching the query. So in some cases, nodes need to have different slots to deal
with query and data transmissions. In addition, CHs need to have their own slots for finding
routes and aggregating data. Based on these requirements, TDMA schedules using APTEEN are
classified into five types of slots: slots for data transmission, slots for answering queries, slots for
finding routes, slots for aggregating data and slots for mobility related issues, as shown below. A
sink should not ask nodes to answer a query at the same time as they are transmitting their own
data [3].
A TDMA schedule using APTEEN consists of the following fields [3]:
1. Member Slots: Each cluster head creates a TDMA schedule for each member using TX
and QA slots, TX is used for transmitting data and QA is used for answering queries. In
this implementation, a sink sends queries to randomly selected nodes in the network.
Mobile members should have another slot for mobility control related issues, such as
move detection.
2. Aggregation Slots (AG): Cluster heads use these slots to aggregate data from their
members.
3. Route Discovery(RD) Slots: Cluster heads use these slots to discover routes between
nodes when transmitting aggregated data from their members toward a sink.
4. TX Slots: Cluster heads use these slots to transmit their own data toward a sink.
As shown before, a sink is responsible to send queries to the nodes in the network when they are
not transmitting their own data. Therefore, cluster heads create TDMA schedule for each mem-
ber so that each member has one slot (TX) for sending data, and another slot (QA) for answering
queries. When mobility is supported, mobile nodes need another slot for mobility related issues.

8
After the TDMA schedules are created, routes from cluster heads to a sink need to be discov-
ered using RD slots and then AG slots are used for aggregating data from members. The allocated
TDMA schedules allow members from the different clusters to deal with data communication
only in their allocated slots and then go to sleep in the rest of the frame. This saves energy and
avoids collisions from the other nodes in the network. When mobility is considered, new
algorithms need to be designed to update TDMA schedules according to new attachments.
Figure. 2. TDMA Schedule for APTEEN
A sink is provided with unlimited power so it can reach all nodes in the network, however, sen-
sor nodes have a limited amount of power, so they need to reply to queries in their allocated slots.
APTEEN supports three types of query: Historical, One time and Persistent. A Historical query is
mainly used to report and analyse historical data about the deployed environment according to
the data stored in a sink. A One time query is used for reporting and analysing data for a specific
part of the network and Persistent query is used to report and analyse data over a period of time
from the network [3]. By combining all these factors, a TDMA schedule using APTEEN can be
defined as shown in Figure 2.
3.5. Mobility Module Using APTEEN
A new challenge is posed when mobility needs to be considered in a WSN. In this case topology
control, resource management and performance control need to be designed to provide good con-
nectivity between static and mobile nodes in the network and provide the required performance.
Mobility and topology control for critical applications using WSNs are described in [9]. The pro-
posed mobility management module in this paper follows the same messages and concepts as in
the above paper.
3.5.1. Mobility Management Module in Cluster Based Routing Protocols
Designing a new mobility module for the cluster based routing protocols is one of the most
challenging issues in WSNs. Some mobility modules have already been implemented for the
cluster based routing protocols, such as LEACH [10]. However, a mobility module for
APTEEN has not been implemented yet. To understand how the network behaves under different
mobile situations, the node mobility using APTEEN has to be simulated in a reasonable way.
The mobility manager is responsible for enabling and controlling node mobility within the
simulation area. In this context, a new mobility module has been designed to fully support mobile
applications using APTEEN. As the APTEEN protocol is a cluster based routing protocol, it has
been assumed that only nodes belonging to each cluster are allowed to move. So members attach
to a different cluster based on three different links costs and metrics: strength of the signal
received (RSSI), remaining energy and the location.
There may be cases when moving from one cluster to another in the network effects the con-
nectivity of the network and then reconfiguration algorithms are needed to ensure the network is
connected. In order to support mobility for real-time applications using APTEEN, control mes-

9
sages which need to be transferred between static and mobile nodes to find a better attachment
have been defined. Some of the possible control messages are Advertisement(ADV ), join
(JOIN), and join acknowledgement( JOIN ACK) messages.
After cluster heads are selected, they need to send ADV messages to the network and then wait
some time. When mobile nodes receive these ADV messages they will ask to join the network.
When a static node receives JOIN messages from the mobile nodes they will send back a JOIN
ACK message to let the mobile node know that the request to join has been accepted. So using
these control messages connectivity between mobile nodes and cluster heads will be established.
Mobile nodes may have more than one cluster they could join, so they have to decide which
cluster will be selected for transferring data toward their parents. In this APTEEN
implementation, the cluster with the maximum Receiver Signal Strength Indicator (RSSI) and
maximum remaining energy is considered the best one to be selected for the new attachment.
Cluster nodes send ADVs including available positions over time and when mobile nodes receive
ADV, they compare the RSSI and energy from their current CHs to the received RSSI and energy
from the current ADV messages. In the case that a new cluster head has a better route, mobile
nodes need to leave their current cluster and attach to this new cluster which is included in the
currently received ADV message. When a new attachment is selected then a join request needs to
be sent to that cluster. Upon receiving the JOIN request from a mobile node, JOIN ACK needs to
be sent by the selected clusters.
Slots in each frame need to be updated according to the new attachments. Mobile nodes need to
release the first TDMA slot after it is attached to the second cluster address, so in this case slots
allocated for the new clusters need to be increased and slots allocated for the old clusters need to
be decreased. A new algorithm for updating slots is needed for APTEEN to balance allocated
slots for nodes according to the different attachments. A new algorithm has been designed to
update channel allocations according to new movements and changes in the topology of the
network.
3.5.2. Move Detections in APTEEN
There are some cases when nodes can move without being detected. For instance, cluster heads
may be unaware of leaving mobile nodes and then will keep space in the channel for that
particular node. This will consume more energy and reduce the reliability of the network. There
may be cases when cluster heads are not available for attachment any more without letting mobile
nodes know. So an additional two control messages for this new mobility module for the
proposed routing protocol have been used, which are denoted by KEEPALIVE and
NODEALIVE. The KEEPALIVE control message is used by cluster heads to let its currently
attached mobile nodes know that this cluster head is still available and NODEALIVE message is
used by mobile nodes to let their attached clusters know that they are still available for
attachment. Mobile nodes wait for a specific interval to receive messages from the attached
clusters, if they do not receive anything during that interval, a NODEALIVE message needs to be
sent, to let a cluster know that they still want to use that cluster. If no reply is received then
mobile nodes need to search for a new cluster to make a new attachment.
4. CROSS LAYER PROTOCOL BASED ON MAC AND ROUTING
PROTOCOLS
In order to minimize the energy consumption and increase the required performance such as re-
liability for delivered data, extensive research has been conducted in the literature on designing
energy efficient protocols at each layer aside [11]. Regarding the MAC layer [12], the most com-

10
mon way to conserve energy consists of putting the transceiver and the processor of a sensor
node into a low power, sleep state when it is unused. As such, the wasted energy due to
collisions, over- hearing and idle listening is reduced. On the other hand, [3] addressed the
problem at the network layer by proposing new routing solutions that take into account the sleep
state of some nodes, by distributing energy usage between nodes over time, which increases the
life time of the entire network.
At the MAC layer, as it has been debated in [12], MAC protocols only care about energy saving
and can not provide good scalability and the required routing for different applications, when the
number of nodes is high. On the other hand, as illustrated in [3], routing protocols can not
provide the required reliability without using efficient MAC protocols. This implies that
combining MAC and routing protocols can provide much better performance than the individual
layer, this is because there is an interaction between MAC and network layers which let nodes be
active at the same time.
GinMAC is a suitable MAC protocol to be used in real-time applications as shown in [13], where
the reliability, energy saving and delay can be guaranteed. Challenges and requirements that need
to be considered before designing MAC protocols for such applications are also described in the
same paper. Based on these features, GinMAC has been modified and implemented for real time
applications, where a low number of nodes is considered. GinMAC can not provide the required
routing for mobile nodes in the proposed applications, when the number of nodes is high. Based
on this, APTEEN [3] has been modified and new features, such as mobility modules and new
algorithms for transmitting data over multi-hops WSNs have been designed.
In this paper, a cross-layer based protocol to improve the lifetime of the network and the reli-
ability of delivered data by considering jointly GinMAC and APTEEN is designed. The proposed
cross layer based protocol involves two stages, the first stage starts by using APTEEN as a
network layer, in which extends the life time of the network by distributing energy usage between
nodes, using clustering concepts as shown above. Hence, APTEEN drains energy slowly and
uniformly among nodes, leading to the death of all nodes nearly at the same time. The Second
stage of the proposed cross layer involves using GinMAC as the MAC layer, which uses a retry
limit of retransmissions over each wireless link according to its properties and the required
packet delivery probability. Usually, the MAC layer retransmits a packet whose transmission was
not successful up to m retries, where m is the same retry limit for all the wireless links. In each
retry a sender waits for an acknowledgement from the next hop to make sure that a packet has
been received. If no reply is comes, then the same packet is retransmitted and so on until either
the packet is received or m retries are used. In the same way, next hop uses retry
acknowledgements to let a sender knows that a packet is received to avoid sending redundant
packets. The proposed reliable transmission algorithm used by GinMAC in the proposed cross
layer protocol is shown in Figure3.
4.1. A Modified GinMAC for the Proposed Cross Layer Protocol
A GinMAC implementation given in [13] has been modified so that it can be combined with the
APTEEN implementation given in section 3. GinMAC is not responsible any more for selecting
routes between nodes in the network. This implies that GinMAC follows information given from
APTEEN and then just confirms that data is delivered to a next hop over single hop
communication using the algorithm given in Figure 3. Hence, based on this, most of the
operations that need to be made in the proposed cross layer are taken by APTEEN, such as
selecting cluster heads, finding routes and then providing the connection between mobile and
static nodes.

11
4.2. Reliable Transmission Using GinMAC
A reliable data transmission between source nodes and a sink in real-time related applications
with high accuracy is one of the most important requirements for designing efficient protocols
using WSNs. Different applications have different requirements in term of the required
reliability. A lot of Medium Access Control (MAC) protocols have been proposed to provide the
required reliability for data delivered, however, there are still problems for offering the required
reliability for real time and critical delivered data related applications using WSNs [11].
In WSNs critical applications, such as healthcare and forest fire related applications, data about
events collected by the sensor nodes need to be reliably delivered to the sink for successful mon-
itoring of an environment, providing the required performance for the given applications. There-
fore, given the nature of error prone wireless links, ensuring reliable transfer of data from
resource constrained sensor nodes to the sink is one of the major challenges in WSNs [11]. A
reliable transfer of data is to confirm that the packet carrying event information arrives at the
destination. In WSNs, reliability can be classified into different levels: Event reliability level and
hop-by-hop or end-to-end reliability level.
Figure. 3. Reliable Transmission Algorithm Using GinMAC
Packet or event reliability is concerned with how much information is required to notify the sink
of an occurrence of something happening in the target environment. Packet reliability requires
all the packets carrying sensed data from all the sensor nodes in the network to be reliably
transmitted to a sink. To achieve packet reliability in terms of recovering the lost packets at the
hop-by-hop or end-to-end level is through the use of retransmissions and an acknowledgement. A
retransmission is simply the retransmissions of the lost information in which can either be per-
formed on end-to-end or hop-by-hop basis. End-to-end retransmission requires the source node
that generated the packet to retransmit the lost information. Hop-by-hop retransmission allows
the intermediate nodes to perform retransmission of lost information by caching it in their local
buffers. The GinMAC implementation given in [13] has been modified to implement reliable
transmission using ACK and SENT packets as shown in Figure 3.

12
5. A Healthcare Application
Because of the fast growing numbers of people aged over 80 years old, the cost of medical care is
increasing day by day. Recent advances in technology have led to the development of small,
intelligent, wearable sensors capable of remotely performing critical health monitoring tasks
using Wireless Sensor Networks (WSNs), and then transmitting patient’s data back to health care
centres over the wireless medium. Such health monitoring platforms aim to continuously monitor
mobile patients needing permanent surveillance. However, to set up such platforms several issues
along the communication chain need to be resolved [5].
The healthcare field is always looking for more efficient ways to provide patients with the best
and most comfortable care possible. Providing proper monitoring can be expensive for their
family and may force them to move from their homes because living alone will be too much of a
risk to their health. It has been assumed, such as in [5], that a WSN could be used to monitor and
treat patients remotely, based on the data collecting from the body of the patients.
One way to approach this task is to use an application to monitor the health of patients that allow
a caregiver or relatives to keep watch on the patients health status with much lower cost and
without forcing them to move their patients into a unfamiliar environments such as hospitals.
Furthermore, these applications can be helpful to the elderly people who suffer from poor mem-
ory problems by providing them with advanced features such as helping them to take medicine,
locating important objects in their homes and so on [14].
In this paper, an application based on the prototype given in [5] has been used to monitor the
healthcare of patients remotely in their homes where mobility and reliability are the biggest
issues. There is a large amount of data to be managed in the proposed application, therefore, an
efficient protocol needs to be designed in order to provide the required performance by the
proposed application.
Based on the above criteria, a cross layer based on the proposed MAC protocol and mobility
module given in [1] and APTEEN given in [3] is used to provide the required performance for
this healthcare application. Some simulations have been performed to evaluate the performance
of the proposed cross layer based protocol. Energy saving, delay, reliability and mobility are
considered as the most important QoS parameters in this application.
5.1. Structure of the Proposed Application
The proposed healthcare system consists of four different parts as elaborated in [5] and shown in
Figure 4. The first part is the home monitoring part where sensor nodes are probed to get multiple
sets of data on the health status using a Body Sensor Network (BSN), and living environment
information via a Home Sensor Network (HSN). The HSN is distributed in the living room, bed-
room, kitchen, bathroom and corridor, to collect the required data. BSN and HSN sensors need to
be attached to the body of the patients and to the environment that these patients are living in,
without effecting their daily activities.
The second part is the decision part which is the most important function in the proposed
application, because the performance of the whole application depends of the decision made by
this part. This part depends on the data received from Base Station (BS) using both BSN and
HSN. The required medical decisions need to be given depending on the data collecting from
home, data from body of the patients and the previous status of the patients. Hence, the BS is
responsible for collecting data from both the HSN and BSN and forwarding to the Health Centre
(HC) or caregivers (doctors and relatives). Therefore, the BS needs to be smart enough to deal

13
with data collecting from different parts of the network and to send to the medical centre which
will take the required decisions.
The third part involves care-givers, including doctors or nurses in the hospital and possibly
relatives. These are responsible for dealing with the medical report messages (normal or alarm
messages), that are sent to them. In the proposed application there should be the possibility for
relatives to check the elder’s current health status through online web pages using some sort of
authentication techniques.
The fourth part is Public Communication Network (PCN) including Internet, GSM/GPRS,
Ethernet, and WI-FI. The PCN delivers generated messages from BS to care givers to do the
required operations.
5.2. WSN in the Healthcare System
The first part of the proposed healthcare system using WSNs is deployed in a home to monitor
and collect data from the home and body of the patients. Each patient is monitored by a WSN
divided into two sub networks which are a BSN and a HSN. A Base Station receives data from
both BSN and HSN and then gives commands to the corresponding network.
5.2.1. Design of Body Sensor Networks(BSNs) for the proposed Healthcare Application
Sensors for each BSN need to be deployed according to the physical diseases that the system is
aimed at monitoring, for example heart rate sensors. More about physical processes and their is-
sues can be found in Section 5.4. In the proposed healthcare application only one physical
medical parameter is considered for monitoring which is body temperature. So, the BSN consists
of one sensor attached to the body of the patient, data that represents temperature needs to be
collected from this sensor and then combined with the sensors in the environment that these
patients are living in, such as kitchen, living rooms and so on, and finally sent back to the BS, to
take any required medical decisions.
If the proposed application needs to be used for more than one disease, then the BSN needs to be
modified to sense data from all parts of the body and send back to a sink. In this Body Area
Network ( BAN), with several nodes, each node deals with one disease. The biggest challenges in
this case is how to combine the BAN with the wider WSN and to combine this with data from the
environments that these patients are living in.
In order to provide a comfortable system which does not effect the patients daily activities, there
will be a lot of challenges which need to be considered, such as size of sensors that need to be
attached on the body of the patients. Each sensor needs to be as small as possible so that it can
easily be attached to the body of the patients without affecting their daily activities, whilst still
providing the required quality of service and performance.
5.2.2. Design of Home Sensor Networks(HSNs) for the Proposed Healthcare Application
HSNs in the WSNs for each patient needs to be designed to monitor the environment that a pa-
tient is living in. In this case, each room will have a number of sensors to measure the data needs
to be collected and must cooperate with BSNs when the patient is in that room. The collected
data then needs to be forwarded to the BS to take the required decisions. An efficient mobility
module needs to be designed to provide the required connection between BSNs and HSNs when
patients are moving from one room to another.

14
5.2.3. Design of Base Station (BS) for the Proposed Healthcare Application
As mentioned before, data from each patient needs to be collected and forwarded to the BS
before transferring to the caregivers. Hence, in the proposed application, the BS becomes the core
of the healthcare system. Thus, the proposed healthcare application needs a smart BS to deal with
data collection from patients, for instance dealing with patient’s activities, their behaviours, deal-
ing with the required reports, such as normal and emergency alarms and so on.
In the proposed healthcare application, each patient needs to be registered under at least one
doctor in the medical centre so that all reports related to this patient can be forwarded to his or
her caregivers. In addition, each patient needs to have at least one other contact in case there is an
emergency. Therefore, a BS needs to include a data base to store information about all patients in
the system including their close relatives and doctors such as names, addresses, phone numbers
and so on.
Regular (not emergency) reports about health status of patients needs to be sent to their relatives
over time. One way for providing reports for patients to their relatives is using personal web
pages for each patient subject to some required authentication process. Two types of reports are
provided in the proposed application; regular and healthcare reports. Regular reports record the
health status for each patient over time during the application, while health reports show what
medical operations and other necessary care needs to be carried out by relatives or doctors within
a given time frame.
5.3. Data Communication in the Proposed Healthcare Application
Each sensor node has a limited energy supply to cater for the sensing, data processing, data
storage and transceiver without the capability to recharge very often, or never. The majority of
the energy is consumed by the communication system, so an efficient energy-conserving
communication protocol has to be used. The bandwidth is limited and must be shared among all
the nodes in the sensor network, but reliable and efficient communication of the acquired data is
very important, to avoid any loss of vital during diagnosis. This only can be achieved by
implementing efficient MAC and routing protocols for the proposed system.
Based on the required criteria for the proposed healthcare application given in this paper, a cross
layer based on GinMAC implementation given in [1] and APTEEN specification described in [3]
has been used to provide the required performance such as energy saving, delay, reliability and
mobility. Some simulation results and conclusions will be given about the proposed cross layer
protocol for the proposed healthcare system to demonstrate that this protocol is a suitable
protocol to be used for this application.
5.4. Designing Physical Process for the Proposed Healthcare Application
Nodes in the simulated system can be fed by the physical process being monitored using three
different cases, the first case is feeding nodes with static data. The second case is feeding nodes
with different data based on the different sources, where each source can change in time and
space. The third case is using a trace file, where nodes are assigned from the trace file. The
simulation parameters using Castalia determines the physical process at a certain time using the
equation given in [15].

15
Figure. 4. Structure of the proposed Healthcare Application [16]
5.5. Simulating Cross Layer Based Protocol for the Proposed Healthcare
Application
The Cross Layer based protocol is simulated in terms of performing the required performance for
the proposed healthcare application. Reliability is considered to be the most important factor
which needs to be guaranteed for this application, but energy consumption, delay and mobility
also are measured. Three different scenarios, where the number of nodes is high, have been
simulated using cross layer based on APTEEN and GinMAC, with different parameters. More
details about the simulation parameters and scenarios are given below.
Parameter Value
Number of Nodes 50, 100 and 400
Number of beds(in each ward) 25
Number of sinks (receptions) 1,2 and 8
Number of sensors in an environment 24
Number of wards 1,2 and 8
Network Dimensions(meters in squares) 50, 150 and 250
Distance Between pair of nodes 25-30 meters
Cross Layer GinMAC + APTEEN
Physical Parameter Temperature
Tempreture range 30 – 40
Temperature Hard Threshold 38
Counter Time (Frames) 5
Simulation Duration 10 minutes
Measurement Metrics Life time, delay and reliability
Sensing Intervals (packet per second(s)) 100

16
mobility speed(meters in seconds) 1
Move interval(in minutes) 2
Mobility Detection interval (in seconds) 60
Initial Energy(in Joules) 18720
Real Radio CC2420
Slot Length (in ms) 80
Round Length (in sec) 50
Percentage of CHs 5 - 15
Multi hop 4
5.5.1. Simulation Scenarios and Parameters
Castalia has been used in this work, because of its capabilities for simulating protocols for WSNs
based on the real data, as shown in [15]. Royal Berkshire Hospital in Reading is the proposed
healthcare application simulated in this paper, where data needs to be collected from patients and
environments and send this data back to healthcare centre to take the required operations.
Informa- tion about numbers of patients, size and number of wards have been taken from the
administration office in the hospital. It is assumed that hospital has set of wards and each ward
has set of beds and environments as described in 5.
Three different scenarios are simulated, which are simple scenario, when number of nodes is 50
(25 mobile nodes(patients), 24 static nodes (environments) and 1 sink). The second scenario is 2
wards having the same information as in the first scenario, in this case, patients are assumed to be
monitored between both wards. The third scenario is a complex scenario, where the simulated
scenario involves 8 wards, each ward has the same information as previous scenarios. Further
details about the simulated scenarios and parameters can be found in Tables 1.
A cross layer based on APTEEN and GinMAC is simulated using the metrics defined in the next
section. Details about the proposed healthcare application are given in section 5. Energy saving,
data delivered and delay are considered to measure the performance of the proposed cross layer
based protocol. Based on this, some conclusions can be drown in terms of applying the modified
cross layer protocol to the proposed healthcare application.
1. Reliability Reliability is considered to be the percentage of packets successfully
delivered from source nodes to the sink.
2. Energy Saving and Lifetime The lifetime of the network is the maximum days that a
WSN can survive, whilst spending energy at a given rate. Let consumed energy by each
node be denoted by C joules, initial energy by E joules and current simulation time by T
seconds, then the lifetime of given MAC protocols for each node in the network has been
calculated as follow: Lif eT ime(indays) = ((E/C ) ∗ T )/86400 (1) where 86400 is
number of seconds in each day. It has been assumed that nodes in the proposed
healthcare application can be recharged every week.
3. Delay Calculation Delay is defined as the difference between the time when each packet
is sent from its source node to the time when the same packet is received by its final
destination.
Delay in real-time applications needs to be measured to ensure that all data is delivered within a
bounded delay, i.e., each packet that is delivered after this delay is considered to be lost and will
be ignored. All data needs to be collected from the source nodes and then delivered to the sink
within a minimum delay.

17
5.5.2. Results Discussion
1. Delivered Packets and Reliability: It is shown in the Figure 7 that the proposed cross
layer based protocol can offer the applications requirements in term of reliability using
various scenarios. The Cross layer based protocol delivers more than 96% of packets
from source nodes to a sink. This is because packets are relayed based on different
reliable links. Thus, it can be said that the designed cross layer protocol based on
GinMAC and APTEEN can be used for the proposed healthcare application when
reliability is the biggest issue.
2. Energy Saving and Lifetime: Figure 5 shows the average life time of the nodes in the
network using cross layer based on GinMAC and APTEEN using different scenarios. It
can be seen that a WSN using the proposed cross layer can survive more than 7 days
using the third simulated scenario and around 11-15 days using the first and second
simulated scenarios. This implies that cross layer can be used for the proposed
application when life time of the network needs to be considered.
3. Delay for Delivered Data: In Figure 6, MaxLatency defines the bounded latency that all
packets need to be delivered, which represents the threshold for latency in the proposed
applications and MaxColumns defines the number of columns to be used for measuring
the latency for given MAC protocols. Any delivered packets after the last column are
considered to be lost and may be discarded. The proposed cross layer offers a good
performance in term of delivered data within a minimum delay. According to the results
from Figure 6, all packets from
CastaliaResults -i 140204-203953.txt -s Life --sum | CastaliaPlot -o LifeTimeLast.pdf --xtitle
Three Scenarios --ytitle Life Time (in days) -s histogram –invert
CastaliaResults -i myFile.txt -s Latency -p | CastaliaPlot -o LatencyLast_Avg.pdf --xtitle Latency
in secs --ytitle Received Packets (An Average) -s histogram
Figure. 5. Life time of the Network using Cross Layer Based Protocol
17
17

18
CastaliaResults -i 140204-203953.txt -s Reliability --sum | CastaliaPlot -s histogram --yrange
0.95:1 -o RelLast.pdf --xtitle Three Scenarios --ytitle Reliability for hop-by-hop(Local
Reliability) –I the first simulated scenario are delivered within the first 2 minutes. Packets from
the second simulated scenario and most of the packets from the third simulated scenario are
delivered within 4 minutes. The rest of packets are delivered after 4 minutes.
Figure. 6. Latency for Delivered Data using Cross Layer Based Protocol
Figure. 7. Reliability of Delivered Data using Cross Layer based Protocol
5.5.3. Final Results
To conclude above results, reliability and energy saving are the most important performance
criteria in which need to be guaranteed in the proposed healthcare application given in this pa-
per, the proposed cross layer based protocol achieves a very good performance in term of both
reliability and energy saving using numerous scenarios. This concludes that the cross layer based
protocol can be used for the proposed application.
18
18

19
6. CONCLUSION AND FUTURE WORK
An implementation of cross layer based on APTEEN and GinMAC including mobility and routes
discovery modules for healthcare application using WSNs, where data needs to be collected from
the body of patients and sent to a medical centre has been described in this paper. It has been
shown that this cross layer based protocol including a mobility module can be used for the target
application where the number of nodes is high. Energy saving, delay and reliability for the deliv-
ered data have been considered for measuring the proposed cross layer based protocol.
Simulation results show that the modified cross layer based protocol can extend the life time of
the network, by distributing energy usage between nodes. The delay for transmitted data can be
minimized by reducing the number of non critical data transmissions, reliability of delivered data
over multi- hops WSNs can also be guaranteed. Based on these features, it has been shown that
the proposed cross layer based on APTEEN and GinMAC can be used for the proposed
application where reliability, energy saving and delay need to be considered. This protocol can
be improved further so that patients can be monitored using real time images and videos.
ACKNOWLEDGEMENT
The authors would like to thank Adonias Pires and Claudio Silva from the Federal University of
Para, for their help for providing the basic ideas about the LEACH and its implementation. The
authors would also like to thanks Dr Athanssions Boulis for information about Castalia simulator
which helped a lot.
REFERENCES
[1] M. Atto and C. Guy, “Wireless sensor networks: MAC protocols and mobility management module
for real-time applications,” in The Ninth International Conference on Wireless and Mobile
Communications (ICWMC 2013), Nice,France, July 2013, pp. 1 – 6.
[2] X.-S. Yi, P.-J. Jiang, X.-W. Wang, and S.-C. Zhang, “Survey of energy-saving protocols in wireless
sensor networks,” in Robot, Vision and Signal Processing (RVSP), 2011 First International
Conference on, Nov. 2011, pp. 208 –211.
[3] M. A. and A. D.P., “Apteen: a hybrid protocol for efficient routing and comprehensive information
retrieval in wireless sensor networks,” in Parallel and Distributed Processing Sym- posium.,
Proceedings International, IPDPS 2002, Abstracts and CD-ROM, 2002, pp. 195–202.
[4] P. Suriyachai, J. Brown, and U. Roedig, “Time-critical data delivery in wireless sensor networks,” in
6th IEEE International Conference on Distributed Computing in Sensor Systems DCOSS ’10).
IEEE, June 2010.
[5] H. Huo, Y. Xu, H. Yan, S. Mubeen, and H. Zhang, “An elderly health care system using wireless
sensor networks at home,” in Sensor Technologies and Applications, 2009. SEN- SORCOMM ’09.
Third International Conference on, June 2009, pp. 158 –163.
[6] D. Zhixiang and Q. Bensheng, “Three-layered routing protocol for wsn based on leach algorithm,” in
Wireless, Mobile and Sensor Networks, 2007. (CCWMSN07). IET Conference on, Dec. 2007, pp. 72
–75.
[7] A. Manjeshwar and D. Agrawal, “Teen: a routing protocol for enhanced efficiency in wireless sensor
networks,” in Parallel and Distributed Processing Symposium., Proceedings 15th International, April
2001, pp. 2009 –2015.
[8] L. Tang and S. Liu, “Improvement on leach routing algorithm for wireless sensor networks,”in
Internet Computing Information Services (ICICIS), 2011 International Conference on, Sept. 2011, pp.
199 –202.
[9] Z. Zinonos, R. Silva, V. Vassiliou, and J. Silva, “Mobility solutions for wireless sensor andactuator
networks with performance guarantees,” in Telecommunications (ICT), 2011 18th International
Conference on, May 2011, pp. 406 –411.

20
[10] S. Awwad, C. Ng, N. Noordin, and M. Rasid, “Cluster based routing protocol for mobile nodes in
wireless sensor network,” in Collaborative Technologies and Systems, 2009. CTS 09. International
Symposium on, 2009, pp. 233–241.
[11] T. K. Rudranath Mitra, “Secure and reliable data transmission in wireless sensor network: A survey,”
International Journal Of Computational Engineering Research, vol. 2, no. 3, pp. 748–754, May-Jun
2012. [Online]. Available: www.ijetae.com
[12] Donovan, T., Brown, J., Roedig, U., Sreenan, J. C.J. and, Dunkels, A., Klein, A., J. Silva, Vassiliou,
V., and L. Wolf, “Ginseng: Performance control in wireless sensor networks,” in Sensor Mesh and Ad
Hoc Communications and Networks (SECON), 2010 7th Annual IEEE Communications Society
Conference on, June 2010, pp. 1 –3.
[13] M. Atto and C. G. Guy, “Wireless sensor networks: MAC protocols and real time applications,” in
The 13th Annual Post Graduate Symposium on the Convergence of Telecommunications, Networking
and Broadcasting (PGNet2012) (PGNet2012), Liverpool, UK, United Kingdom, June 2012.
[14] S. Khan, A. Khan, P. Nabil, and A. Alrajeh, Wireless Sensor Networks: Current, Status and Future
Trends. France: CRC Press, Taylor and France Group, November 2012.
[15] A. Boulis, “Castalia: A simulator for wireless sensor networks and body area networks,” in
http://castalia.npc.nicta.com.au, NICTA, [retrieved: April, 2014], March 2011, pp. 1 – 120. [16] Y.
Zatout, “Using wireless technologies for healthcare monitoring at home: A survey,” in e-Health
Networking, Applications and Serv (Healthcom), 2012 IEEE 14th International Conference on, 2012,
pp. 383–386.

A cross layer protocol based on mac and routing protocols for healthcare applications using wireless sensor networks

Recommended

More Related Content

What's hot (16)

Similar to A cross layer protocol based on mac and routing protocols for healthcare applications using wireless sensor networks (20)

Recently uploaded (20)

A cross layer protocol based on mac and routing protocols for healthcare applications using wireless sensor networks