Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a
Multi-Hoping Wireless Body Sensor
Garrick Bugler (3017767)
October 28, 2008
Academic Supervisor: Mehmet Yuce
A thesis submitted in partial fulﬁllment of the requirements
for the degree of Bachelor of Engineering in Telecommunications Engineering at The
University of Newcastle, Australia.
A wireless body sensor network (WBSN) is a wireless network that incorporates embed-
ded sensors on the human body with the aim to monitor physiological parameters from
multiple patient bodies. WBSNs increases the comfort and mobility of patients while al-
lowing remote access of data whenever necessary. This project aims to investigate various
aspects of IEEE 802.15.4 in a heterogeneous WBSN using OPNET. This project designs a
multi-hop, multi-patient WBSN for the purpose of applying optimum protocol parameters
to give priority to critical patent data, to develop an interference model to study interfer-
ence eﬀects and to implement a simulation model of a WBSN using services dedicated for
medical data. It was found that a maximum of six patients could be supported before exces-
sive data loss became a problem. Optimum settings for Minimum Backoﬀ Exponent, ACK
Mechanism, and Maximum Number of Backoﬀs were investigated. It was found that ACKs
should only be enabled on critical data and that the critical data should use the smallest
Minimum Backoﬀ Exponent without disabling collision avoidance. This report was success-
ful in the design and construction of an interference model that accurately models various
IEEE 802.11b applications. It was found that the designed WBSN has suﬃcient quality of
service considerations to handle low interference levels. However it is recommended to use
diﬀerent, non-overlapping channels as some WLAN applications were found to completely
prevent transmissions. Interference analysis is important because loss of medical data can
be potentially life threatening. Using IEEE 802.15.4 for medical data collection is not ideal
as it does not comply with medical standards. There are services available that have been
deﬁned speciﬁcally for use in this area, such as the Medical Implant Communication Service
(MICS) and Wireless Medical Telemetry Service (WMTS). This report implements IEEE
802.15.4 using these services by modifying existing OPNET source code.
The author has made the following contributions toward the completion of this project.
1. Design, simulation and performance evaluation of multi-hop, multi-patient wireless
body sensor network.
2. Investigate quality of service considerations for critical patient data by varying pro-
tocol parameters and consideration of network backbone infrastructure.
3. Proposed ﬁnal design wireless body sensor network with recommendations and con-
4. Design and construction of an interference model for various wireless local area net-
5. Simulation and evaluation of interference on the designed wireless body area network.
6. Implementation of IEEE 802.15.4 using dedicated medical services by editing existing
OPNET source code.
7. Contribution to development of OPNET’s Zigbee models by identifying inconsistences
and errors in implementation from the Standards.
Garrick Bugler Mehmet Yuce
1.1 Wireless Sensor Network Evolution
In the past, the most common form of information processing has been done on multi-
purpose computational devices , with the most common being the home PC or oﬃce
server. These applications are generally controlled by the user and are not directly inﬂu-
enced by their physical environment . There is an opposing system where the physical
environment has a large inﬂuence on and is also the focus of the system . In these appli-
cations the computer system exerts control on the physical system, its actions and reactions
are predeﬁned by human programming. These embedded applications do not require an
operator and are designed to operate automatically. Embedded sensors are used extensively
throughout industry and are not a new concept. It has been estimated that up to 98% of
all computational devices are used in an embedded application . Embedded micropro-
cessors can be found in many everyday items such as washing machines, mobile phones and
in cars . All these embedded microcontrollers have a similar purpose, revolving around
data processing and communication. For many applications these embedded sensors are
built using wired network technologies . Wired network technology works well for some
systems but as the network grows wires can become a problem. These problems are cost,
maintenance and the lack of mobility . In the last few years a solution to these problems
has emerged . Wireless Sensor Networks (WSN) are made up of individual nodes that
sense and control their physical environment while also communicating wirelessly between
each other to achieve their goal. WSNs usually have three main functionalities, these are
computation, wireless communication and sensing or control .
1.2 WSN Applications
The technological advancement that led to sensor networks becoming wireless has opened
up a range of new applications that were once not viable. These include but are certainly
not limited to:
• Machine Surveillance and Preventive Maintenance: Sensor nodes are ﬁxed
to machinery in positions that are diﬃcult to reach or dangerous for the operator.
The sensors can then detect vibrations to predict when maintenance is necessary.
Examples where this is being used include on train axles and in spacecrafts .
• Precision Agriculture: Sensor nodes are placed to detect humidity and soil compo-
sition in paddocks to allow precise irrigation, fertilisation and pest control measures
• Intelligent Buildings: Sensor nodes monitor real-time values of temperature, hu-
midity, airﬂow and other physical parameters in a building to eﬃciently control air
conditioning to optimise power consumption .
• Telematics: Sensors embedded along the roadside monitor traﬃc conditions and can
then update electronic billboards informing drivers of traﬃc congestion .
• Logistics: Sensor nodes can be embedded in product shipments or even in individual
packets to track deliveries and update stock counts .
• Medical Applications: Sensors can be used to monitor critical parameters of a
patient in intensive care, for the long term monitoring of elderly patients at home and
also for automatic drug administration .
This is the end of our discussion of WSNs as a whole. From here on in we will focus on
WSNs in a medical environment.
1.3 WSNs in Medical Environments
Monitoring patients and collecting data for analysis is a major issue for health and disease
management . The use of Wireless Body Sensor Networks (WBSN) for this application
makes the task seamless and easy . WBSNs are the same concept as WSN but with
sensor devices embedded on the human body. WBSNs provide timely and accurate access
to complete patient information, which is required for saving lives and improving the comfort
and recovery time of patients . Many current day hospitals collect patient data using RS-
232 port interfaces that are permanently connected to the monitoring device . WSNs
have been earmarked for use in medical applications for a number of reasons, these include:
• Cost Eﬀectiveness: Many hospitals located in old buildings are not suitable for
wired technologies from a cost-eﬀective view point .
• Mobility: Doctors can access patient information from anywhere in the hospital or
remotely over the internet whenever needed .
• Installation Flexibility and Scalability: Wireless networks can reach places that
are restricted to wires while also being conﬁgured to diﬀerent topologies depending
on the current need .
• Integratable: WBSNs eliminate incompatibility issues where each manufacture cre-
ates its own proprietary data link layer . They can operate as an independent
system or in conjunction with an already existing WLAN or LAN . This also helps
oﬀer complete information to an industry where information is often fragmented and
not properly centrally stored .
There are a number of diﬀerent ways in which WSNs can be used in medical applications.
• Measuring Physiological Parameters: WBSN can be used to measure multiple
patient parameters such as blood pressure, ECG and heart rate [6, 7] just to name a
few. This reduces the workload on nurses, which in turn can help to reduce human
• Drug Administration: WBSN can be used to automatically administer drugs to
patients  based on a time schedule or on measurements taken from the patient by
the WBSN. This can eliminate human error in drug overdoses.
• Monitoring From Home: WBSN make it possible for patients, especially the el-
derly, to go home and still be monitored by doctors . This gives patients back some
independence, puts them in a familiar, relaxing environment and frees up a bed for a
more needing patient.
• E-Prescriptions: This is related to the above point and involves the automatic
prescription generation based on sensor data .
• Alarm Notiﬁcations: This can be used for patients in a critical condition where
response time is crucial. It can also be used for alarms when patients are given the
wrong drugs or for Alzheimer’s patients when they wander oﬀ .
• Patient Transfers/ Asset Tracking: WBSN can be used to know where patients
and equipment are at all times, even when being transferred between hospitals .
They can also ensure that patient data is easily shared between hospitals.
Current Use and Future Direction
The Institute of Electrical and Electronics Engineers (IEEE) 1073 work group is currently
researching standards for use in medical wireless communication applications for the patient
bedside . The main outcome of this work group is to evaluate the suitability of existing
standards and develop a universal interface for medical equipment that is transparent to
the end-user, easy to use and quickly conﬁgured and reconﬁgured . The new standard
will deﬁne the physical (PHY) and media access control (MAC) layer to develop a low cost,
ultra low power and highly reliable wireless network . It is likely to be based on the
IEEE 802.15.4 MAC layer with a new PHY layer deﬁned . Two services speciﬁcally for
medical data collection have also recently been released . These are the Medical Implant
Communication Service (MICS) and Wireless Medical Telemetry Service (WMTS). WBSN
are currently being used in multiple medical applications . An example of a WBSN in
use today is for detection and prediction of physiological parameters including wakefulness,
fatigue and stress . In this application the patients have unobtrusive sensors connected to
a wireless device that transmits the data to a central server. WBSNs in medical applications
are potentially very beneﬁcial but also ethically controversial . In practical applications
issues such as the security of the patient’s data must be considered , this is not discussed
in the report but is covered in .
2.1 MAC Protocol Overview
The MAC protocol in a WBSN must achieve the following tasks: establish communication
links, create network infrastructure and control access to the medium so that communication
resources are evenly and eﬃciently shared among devices . Furthermore in a medical
environment the MAC protocol must be reliable, have ﬂexible transmission mechanism
and have a high channel eﬃciency . The three primary MAC protocols that have been
earmarked for medical applications are Time Division Multiple Access (TDMA), polling,
and contention based protocols . TDMA and polling do not use contention to access the
medium. TDMA uses synchronisation for devices to know when to transmit while polling
uses control traﬃc to control who is transmitting. These protocols do not perform well as
the network increases in size. The protocol being considered in this report is a contention
based protocol. This type of protocol does not require any centralised controller and has
minimum delays when operating with moderate loads . The performance of a contention
based protocol could degrade when the load increases past this point but this is improbable
in a medical WBSN .
2.2 IEEE 802.15.4
This report speciﬁcally deals with the IEEE 802.15.4 protocol. The IEEE ﬁnalised this
standard in October of 2003 . IEEE 802.15.4 deﬁnes both the PHY and MAC sub-
layer  of the data link layer . It was designed as a Wireless Personal Area Network
(WPAN) with low complexity, low cost and low power consumption as it’s key parameters
, making it ideal for a WBSN in a medical environment. It was designed for use between
ﬁxed and portable devices and has found applications in home and building automation and
industrial sensor and actuator networks [14, 15] where the wireless distance is 10m or less
[18, 7]. Some texts use the terms IEEE 802.15.4 and Zigbee interchangeably. Zigbee is an
emerging standard from the Zigbee Alliance  that uses IEEE 802.15.4 for its PHY and
MAC layers, while adding its own network, security, application and other layers . The
upper layers are deﬁned by the Zigbee Alliance  as seen in Figure 2.1 adapted from .
In this report the terms Zigbee and IEEE 802.15.4 are used interchangeably.
Figure 2.1: IEEE 802.15.4 and Zigbee Open System Interconnection (OSI) Model
2.2.1 Physical Layer
IEEE 802.15.4 uses a spread spectrum technology called Direct Sequence Spread Spectrum
(DSSS). This is where the bandwidth occupied by the transmitted waveform is much larger
than what is actually needed to successfully transmit the data. This is done to reduce the
eﬀects of narrow band noise and interference . IEEE 802.15.4 operates at a range of
frequencies, speeds and modulation types for diﬀerent geographical regions. A summary of
these parameters can be seen in Table 2.1. The three frequency bands listed are part of
the Industrial Scientiﬁc Medical (ISM) band . The 2.4 GHz band provides the highest
Frequency Bandwidth (kb/s) Modulation Location No. Of Channels
2.4 GHz 250 OQPSK Worldwide 16
915 MHz 40 BPSK Americans 10
868 MHz 20 BPSK Europe 1
Table 2.1: IEEE 802.15.4 Technical Speciﬁcations
bandwidth per channel and the greatest number of channels (16 non overlapping) and is
the dominant band for IEEE 802.15.4 chips . The 2.4 GHz frequency is what we will be
concerned with when referring to Zigbee or IEEE 802.15.4 for the remainder of this report.
This frequency has the greatest channel capacity partly because of the modulation scheme
used. It uses Orthoganal Quadrature Phase Shift Keying (0-QPSK) as opposed to Binary
Phase Shift Keying (BPSK) for the other two frequencies . There are a total of 27
diﬀerent channels between the three frequencies but it must be noted that IEEE 802.15.4
is a single channel protocol and can only use one channel at a time .
2.2.2 Medium Access Control Layer
IEEE 802.15.4 uses Carrier Sense Multiple Access (CSMA) as part of it data transfer pro-
cedure. When a node has data to transmit it has to perform a Clear Channel Assessment
(CCA). This involves listening to the medium for a predetermined amount of time . If the
channel is idle the device transmits at the relevant time, and if the channel is busy it waits
a random time before re-sensing the medium [1, 7]. The random time it waits can be based
on various algorithms (examples are explained in ) such as persistent and non-persistent
CSMA. CSMA doesn’t have provisions against hidden-terminal problem such as a Request
to Send (RTS)/ Clear to Send (CTS) handshake. Instead it uses random delays to reduce
the probability of collisions, thus actually making it Carrier Sense Multiple Access with
Collision Avoidance (CSMA/CA) . IEEE 802.15.4 has a beaconed enabled mode and a
non-beaconed mode that use slotted CSMA/CA and unslotted CSMA/CA respectively.
2.3 Network Architecture
There are two types of nodes deﬁned by the IEEE 802.15.4 MAC protocol, they are:
• Full Function Device (FFD): This device can be used as any one of three roles :
1. Personal Area Network (PAN) Coordinator (Coordinator)
2. Simple Coordinator (Router)
3. Simple Device (End Device)
• Reduced Function Device (RFD): This device can only operate as a simple device
(End Device) .
Each RFD associates with a coordinator that has to be a FFD and FFDs can be associated
with multiple RFD. The RFD can only communicate with its associated FFD, thus creating
a star network. Multiple coordinators can then from a PAN, with one of these coordinators
becoming that PAN coordinator. The main tasks of a coordinator are:
• To manage a list of RFD associated with itself 
• To allocate addresses to these RFD 
• To broadcast beacons in beacon-mode 
• To exchange data packets with RFD and with peer coordinators .
Coordinators, Routers and End Devices can form a one-hop star topology or a multi-hop
peer-to-peer topology  as seen in Figure 2.2 adapted from .
Figure 2.2: Zigbee Topologies
2.4 Non-Beaconed Mode
IEEE 802.15.4 supports both a beacon enabled mode and a non-beaconed mode which
supports slotted CSMA/CA and unslotted CSMA/CA respectively. OPNET only currently
has a standard library that supports the non-beaconed mode. For this reason this report
focuses on this version, but includes an introduction of the beaconed mode in Appendix
A. Future versions of OPNET will support both versions and there are currently available
third party implementations of the beaconed mode .
2.4.1 Data Transfer
In non-beaconed mode the entire channel access time is made up of one continuous con-
tention access period (CAP). The lack of a beacon means that the devices are not time syn-
chronised with the coordinator. This lack of synchronisation forces all devices to transmit
all data using unslotted CSMA/CA. In this version coordinators must always be switched
on but can ’sleep’ to conserve power. Devices ’sleep’ and only wake to send packets or
receive packets. This mode is best suited to a star topology where the coordinator has easy
power access and the devices are more power constrained  . This mode is simpler and
uses much less overhead than the slotted version .
2.4.2 Unslotted CSMA/CA
When nodes need to send data they use unslotted CSMA/CA. This is a contention based
protocol where a possible opportunity to transmit can be acted upon by multiple devices
. The behavior of unslotted CSMA/CA is determined primarily by two parameters, the
Backoﬀ Exponent (BE) and the Maximum Number of Backoﬀs (NB). The actual process
of unslotted CSMA/CA and its relation to the previous parameter are listed below and can
be seen in Figure A.3 adapted from .
• The variables NB and BE are initialised with NB is set to zero and BE is set to
macMinBE . macMinBE is a protocol parameter in the range [0, 3] which is user
deﬁned with a default of 3. BE can have a value in the range macMinBE and aMaxBE
(5). NB has a user deﬁned maximum value in the range [0, 5], with a default of 4.
• The number of delay backoﬀ periods is found randomly from the interval [0, 2BE − 1]
• A CCA is performed after the delay to sense if the channel is busy .
• If the channel is sensed as idle the node sends a packet. If the channel is sensed to be
busy NB and BE are both incremented .
• If NB is below it’s maximum value it recalculates a new delay period. When NB
reaches it’s maximum value a transmission failure is reported .
2.5 Interference and Coexistence
Wireless systems continue to gain popularity at an increasing rate . This applies to
Wireless Local Area Networks (WLANs) that are also operating in the license-free ISM
band. In this band neither resource planning or bandwidth are guaranteed to its users
 which raises the issue of mutual interference and coexistence with neighboring wireless
systems. It is highly likely that an IEEE 802.15.4 system will not be in an environment
completely free from interference . Some applications are resilient to packet loss from
interference but in a medical environment the highest reliability in transmission is needed
. There are currently three wireless standards in the ISM band, not including other EM
sources like microwaves and cordless phones . These standards use diﬀerent modulation
and channel access schemes and include IEEE 802.15.4 (Zigbee), IEEE 802.11 (WLAN)
and IEEE 802.15.1 (Bluetooth). This opens the possibility of signal interference between
diﬀerent standards which could result in performance degradation . This Quality of
Service (QoS) issue is not only related to packet loss and transmission delays but also
includes jitter, availability and security . For all the previously mentioned systems to be
able to function correctly within this same frequency range, coexistence must be achieved.
Multiple devices and systems coexist if they occupy the same area without signiﬁcantly
impacting the performance of any of the other device or system . For each individual
standard, channel access and collision avoidance were designed to work only within that
one system . It is now necessary for each standard to deal with interference form other
standards to be able to function correctly.
IEEE 802.11b is one protocol out of a group of protocols that deﬁne WLANs. The terms
IEEE 802.11b and WLAN will be used interchangeably throughout this report. IEEE
802.11b operates at the 2.4GHz and 5GHz frequencies. Since both IEEE 802.15.4 and
WLANs use spread spectrum techniques, it is theoretically possible that coexistence can be
achieved by choosing non-overlapping channels [7, 15] as seen in Figure 2.3. Because the
Figure 2.3: Channel Overlap Between IEEE 802.15.4 and IEEE 802.11b
bandwidth of IEEE 802.11b is larger than that of IEEE 802.15.4, the interference power
of IEEE 802.11b can be considered as Additive White Gaussian Noise (AWGN) on IEEE
802.15.4. Also the interference power of IEEE 802.15.4 can be considered as a partial band
jamming signal , although the interference eﬀect on WLAN is not considered in this
report. Also an important point to realise while considering interference between the two
systems is that the power transmission of a WLAN is thirty times greater than that of IEEE
Some IEEE 802.11b Wireless Access Points (WAPs) make use of Dynamic Channel Selection
(DCS). In this process the WAP analyse the utilisation of diﬀerent channels before deciding
on which channel to transmit on . IEEE 802.15.4 has an Energy Detection (ED) function
to determine the activity of another system but lacks a DCS tool .
Literature Review and Proposed
This report has three main objectives as highlighted by the sections below. Here a literature
review and discussion of the proposed work is presented for each area.
3.1 Multi-Patient WBSN Design
In  the performance of a single hop star topology was evaluated in terms of number of
nodes, inter-arrival time, symbol rate, frequency and packet size and was extended in 
to examine the performance of a IEEE 802.15.4 MAC based WBAN operating in diﬀerent
patient monitoring environments.
This report will aim to improve on this work to design, simulate and evaluate a multi-patient
WBSN hospital room based on a hardware prototype developed in [6, 8]. This new design
will incorporate a multi-hop topology not yet simulated in any of the above work. Design
constraints will be outlined as well as any limits on the system.
3.2 Priority For Critical Data
In  slotted CSMA/CA was enhanced to allow higher QoS for the delivery of high priority
frames in emergency situations. A high priority toning strategy is used, where devices send
a emergency tone signal before the beacon transmission . The PAN coordinator receives
the tone signal and repeats it in the beacon frame to all other devices. All other nodes,
without critical data, delay their transmissions and the critical data will occupy the earliest
frames in the CAP . This prototype is extended in  to allow high priority frames to
perform only one CCA, instead of the usual two . This frame tailoring strategy aims
to avoid collisions between data frames and ACK frames . These two approaches were
successful in improving the QoS of time critical data but did require additional hardware
and these changes were non-compatible with other IEEE 802.15.4 systems.
In  the CSMA/CA protocol parameter’s are varied and applied alongside some basic
queuing strategies (FIFO and priority queuing) . This paper shows that by adequately
tuning various parameters of slotted CSMA/CA improvements can be made to the QoS
for time critical data .  showed that for large scale WSNs the average delay of
broadcast frames increases with the minimum back oﬀ exponent, although this does not
aﬀect the BER . It also shows that for small scale WSNs the BER decreases with an
increase of the minimum backoﬀ exponent .  uses these results by not having the
same parameter values for the two diﬀerent types of traﬃc (data and command traﬃc).
In addition to changing the parameter values, priority queuing can also be implemented
to reduce the queuing delay of high priority data .  presents slotted CSMA/CA
using priority scheduling to select frames from a queue and then apply the parameters
corresponding to that frame type. Others such as [34, 14] have evaluated the performance
of individual protocol parameters and  has created a simulation model for a optimised
MAC processes. Also  has created a Markov chain model to provide insight into the
strengths and weaknesses of varying protocol parameters.
Once a multi-patient WBSN has been designed, simulated and evaluated QoS considerations
will be made for critical data. These considerations will not incorporate any changes to the
protocol but will investigate optimised values for MAC and CSMA/CA parameters for a
multi-hop tree network as opposed to the single hop star network used in . Particular
attention will be given to delay, throughput and BER. The parameters that will be optimised
for critical data include:
• Maximum Number of Backoﬀs
• Minimum Backoﬀ Exponent
• ACK Mechanism
This report will also consider the eﬀects of using other standards as the backbone of the
network that connects multiple hospital rooms to the data storage and remote access loca-
3.3 Interference Analysis
 investigates the interference between multiple IEEE 802.15.4 systems. This mutual in-
terference can be avoided by choosing diﬀerent channels for diﬀerent systems, as there are
16 to choose from. This can be done through manual conﬁguration or by implementing op-
tional dynamic procedures .  investigated the eﬀects when two IEEE 802.15.4 systems
used the same channel, with each system having four devices, with the two coordinators
only 1m apart. They observed a 18% packet loss and 79% throughput. They concluded
that the packet loss observed is similar to that obtained if all transmitters were connected
to a single cocordiantor.  also investigated the eﬀects of WLANs on IEEE 802.15.4 for
diﬀerent applications, including ﬁle transfer protocol (FTP), hyper text transfer protocol
(HTTP), email, and video. The IEEE 802.15.4 transmitted four types of data while the
previous WLAN data transfers were taking place. The IEEE 802.15.4 signals were ECG,
blood analysis, supervisory data and alarm status. This was done with the IEEE 802.15.4
doing a CCA on only its data frames and also while doing a CCA on both it’s and the
WLAN’s frames. For the former situation signiﬁcant packet loss was observed. The worst
case was when the WLAN was transmitting FTP or video. In the case of video there was a
100% packet loss in the IEEE 802.15 system. In this situation  concluded that the likele-
hood of data not reaching its destinalltion is so high that one should not use IEEE 802.15.4
under these circumstances. For the latter situation where IEEE 802.15.4 used CCAs on
both its frames and WLAN frames it was observed that the packet loss was lower for al-
most all applications but was still at an unacceptably high level. The WLAN packet loss
was negligible in this scenario as the IEEE 802.15.4 system sensed the channel and did not
interrupt the WLAN data. This allowd the WLAN to get unlimited access to the medium
and provided preferential treatment to the WLAN data . It can therefore be stated that
in  it was shown that WLANs signiﬁcantly impact IEEE 802.15.4. In some situations the
BER in the IEEE 802.15.4 system was so high that communication was impossible. These
results are backed up by multiple other studies including  which used hardware instead
of simulations to show a coexistence issue and also by  which examined the reduced
interference when systems are moved apart in both the frequency and distance domains.
All the scenarios in the above research looked at the interference eﬀects on a single-hop
Zigbee network and did not look at multi-hop topologies. It is for that reason that this
report will reproduce the results in [4, 14] and then extend the research to cover interference
on a multi-hop, multi-patient WBSN. To achieve this, interference source will have to be
designed and constructed in OPNET as the standard WLAN and Zigbee libraries cannot
be simulated in the same environment.
3.4 MICS and WMTS Services
The Medical Implant Communication Service (MICS) and Wireless Medical Telemetry Ser-
vice (WMTS) are new services dedicated to data collection in the medical environment. 
has reviewed regulatory standards and the characteristics of MICS transceivers. [39, 40, 6]
has developed a multi-hop sensor network system to monitor physiological parameters from
patient bodies that utilised both MICS and WMTS for short range and long range commu-
This report aims to model IEEE 802.15.4 using the WMTS and MICS services by mod-
iﬁcation of existing OPNET source code. This model will be based on the implantation
presented in  in relation to speciﬁc transceiver parameters. This new model will give a
simulation base for future analysis and improvement to the prototype presented in .
OPNET and Theoretical Limits
4.1 Theoretical Delay and Throughput
To be able to understand the results from our simulations we need a theoretical basis of
comparison. The two parameters that describe a network’s capability to carry data are
capacity and throughput. Throughput is how much data can be delivered by a network
and it’s upper bound is the channel capacity. Here we will be considering the non-beaconed
mode. In addition to being the version used in OPNET this version also has the lowest
overhead so will give the best results for the upper bound of throughput and lower bound
of delay . The following calculations are taken from  and are presented using values
relevant to our design. The calculations are based on an ideal channel with the following
• The throughput is calculated using one transmitter and one receiver located close to
• The previous point allows us to assume that there are no losses due to collisions and
the Bit Error Rate (BER) is negligible.
• No data is lost due to queuing buﬀer overﬂow.
• The transmitting device always has adequate packets to send.
To calculate the throughput, the delay ﬁrst needs to be calculated. This delay includes
the delay from sending the data packet and also the delay caused by elements of the frame
sequence (backoﬀ schemes, inter-frame spaces, sending of ACKs etc.) The delay to transmit
one packet is related to the throughput by the following equation:
TP = (4.1)
Where x is the payload in bytes that has been received from the network layer and the
delay on each packet is given by:
delay(x) = TBO + Tf rame (x) + TT A + TACK + TIF S (x) (4.2)
• TBO is the backoﬀ period
• Tf rame (x) is the transmission time for x payload bytes
• TT A is the turn around time
• TACK is the transmission time for an ACK
• TIF S is the inter-frame spacing (IFS) time
In regards to the IFS a Short Inter-Frame Spacing (SIFS) is used when the MAC Protocol
Data Unit (MPDU) is smaller than or equal to 18 bytes. If the MPDU is greater than this
a Long Inter-Frame Spacing (LIFS) is used and this is the case that we will be considering.
Now we need to consider the time associated with the backoﬀ period. The back oﬀ period
is expressed as follows:
TBO = BOslots • TBOslots (4.3)
• BOslots is the number of unit backoﬀ slots
• TBOslots is the time for each backoﬀ slot (aUnitBackoﬀPeriod)
As seen earlier the number of backoﬀ slots is a random number in the interval (0, 2 BE − 1)
where BE is the backoﬀ exponent and has a default minimum of 3 . As we are assuming
ideal conditions and only one transmitter, this value can be treated as a constant. Therefore
the number of backoﬀ slots can be represented as the average of the interval, which is 3.5.
Also the time for each backoﬀ slot is given by 20 symbol periods or 320µs.
The total duration of the frame is given by:
SP HY + SM AC HDR + Saddress + x + SM AC FTR
Tf rame (x) = 8 (4.4)
• SP HY is the size of the PHY overhead in bytes
• SM AC HDR is the size of the MAC header in bytes
• SADDRESS is the size of the MAC address info ﬁeld
• SM AC FTR is the size of the MAC footer in bytes
• Rdata is the raw data rate
Equation 4.1 can now be graphed for both throughput and delay. Figure 4.1 shows this
graph for ACKs enabled and using 16 bit addressing.
Figure 4.1: Theoretical Limits of Throughput and Delay
4.2 OPNET Channel Capacity
All simulations are done using OPNET (Optimized Network Evaluation Tool) which is a
network technology development environment that is used to run discrete event networking
simulations. Before running any simulations it is important to understand how OPNET has
implemented IEEE 802.15.4. The following values of overhead were discovered by running
simulations, reading source code and by contact with OPNET technical support. The
PHY Overhead 6
Frame Length and Reserved Bit 1
MAC Overhead 12
Frame Control 2
Sequence Number 1
Address Fields 7
Table 4.1: MAC and PHY OPNET Overhead
packet size attribute in OPNET refers to application data payload. It is this payload with
the addition of the MAC overhead from Table 4.1 that makes up the MAC Protocol Data
Unit (MPDU). The Physical Protocol Data Unit (PPDU) is a combination of the MPDU
and the PHY overhead from Table 4.1. The frame structure used in OPNET is seen in
Figure 4.21 . The standard deﬁnes the maximum packet size as 128 bytes, so considering the
overhead this leaves a maximum data payload of 110 bytes. The standard does not support
fragmentation so if a data payload greater than this value is entered the MAC layer should
reject these packets. This is not what happens in OPNET, it accepts a higher layer packet
regardless of size and sends it in a single MPDU. For this reason any simulation with more
than 110 bytes of payload data will produce inaccurate results, see Appendix E for more
information. From simulation the length of the ACK frames were also found to be 5 bytes
at the MAC layer and 11 bytes at the PHY layer. Figure 4.3 shows the size of the ACK
The address ﬁelds have a length of 7 bytes but this is not completely accurate of a real system, see
Appendix E for more information.
Figure 4.2: MPDU and PPDU Data Frames used in OPNET
Frame at the PHY and MAC layer. This value corresponds to a non-addressed ACK frame
Figure 4.3: MPDU and PPDU ACK Frames used in OPNET
OPNET Calculated Channel Capacity
The speciﬁcations stated in the standards can be misleading if you do not have a good
understanding of the protocol. For example the standard speciﬁes that 65 536 nodes are
supported  in a single network. However there is not enough bandwidth to support such
a large network (assuming each node transmits kb/s) and possible transmission time for
each node would be minimal . The number in the standard actually comes from the 16
bit addresses in IEEE 802.15.4. At the frequency that we are concerned with in this report
(2.4 GHz) the maximum channel capacity is 250kbps. But this is not all pure data and has
to include header bytes, CSMA waiting times and other such overhead . We will now
see a derivation of the actual channel capacity. The actual channel capacity for a single-hop
connection in a non-beaconed network can be found using :
C = CP (4.5)
Tpayload + Tack + Toverhead + Twait
Tpayload = ,
Tack = ,
A description of all terms is seen below:
• Twait is the minimum time the radio has to wait before sending a packet
• Tpayload is the time it takes to transmit the actual data payload
• Tack is the time it takes to send the ACK packet over the air
• Toverhead is the time it takes to send the MAC and PHY overheads over the air
• Spayload is the size of the payload
• Sack is the size of the ACK packet
• Soverhead is the total size of the MAC and PHY overhead
• CP is the total channel capacity (250 kb/s)
The values from Table 4.1 are used in this calculation 2 . The result for maximum channel
capacity for one node is:
C ≤ 250kb/s
3.52ms + 0.352ms + 0.576ms + 1.152ms
C ≤ 157.14kb/s (4.6)
This equates to 63% of the maximum stated channel capacity.
The minimum CCA wait time, minimum radio turnaround time and minimum inter-frame spacing are
used to get a wait time of 1.152 ms 
OPNET Performance Evaluation
It was shown that the actual pure channel capacity is less than 157.0 kb/s. The maximum
channel capacity of this same type of system was modeled in OPNET. This was done by
placing one device and one coordinator in close proximity. Only one device was transmitting
and it’s load was varied while noting the throughput of the system. The results in Figure 4.4
were produced. The throughput of the system increases in proportion to the available load
Figure 4.4: OPNET Throughput and Theoretical Channel Capacity
up to the point where the bandwidth resource starts to become stretched. After this point
the load is more than the system can handle and congestion starts to become apparent.
At this point the device is trying to produce a greater load than what can actually be
transmitted. The throughput gradually increases to a maximum value of approximately
114 kb/s. Therefore it can be stated that OPNET’s maximum channel capacity is 114 kb/s
as compared to the theoretical maximum of 157 kb/s. These two values do not agree and
have a diﬀerence of 13.4%. The cause of this variation was investigated and was found to
be due to an error in the OPNET implementation of overhead. This error eﬀectively counts
the MAC overhead twice, further limiting the channel capacity. For more information about
this problem see Appendix E.
4.3 Transmission Power
The Zigbee modules have a default receiver sensitivity of -85dBm. This deﬁnes the received
power threshold value for arriving packets at the radio receiver. Packets with a power
less than this threshold are not decoded by the receiver and are treated as noise. These
packets can cause interference and bit errors if they collide with valid packets at the receiver.
Packets with a received power higher than the threshold are treated as valid packets and
are decoded by the receiver unless they get bit errors from interference, background noise
or collisions with valid packets. To ensure a packet’s received power is above this threshold
it’s transmit power must be large enough to accommodate for the path lose between the
transmitter and receiver. Path loss is deﬁned as:
P L = 20 • log (dB) (4.7)
• d is the distance between transmitter and receiver
• λ is the wavelength of the signal and is equal to f where c is the speed of light and f
is the frequency
By using Equation 4.7 and the receiver threshold the maximum transmission distance be-
tween two nodes was determined for a range of transmit powers and these values were then
compared to the OPNET simulated values. The results are presented in Figure 4.5 and as
can be seen the simulated results in OPNET agree with that of the theory. It is therefore
assumed that this ﬁgure is an accurate method to determine the transmit powers for the
Figure 4.5: IEEE 802.15.4 Transmitter Power
Multi-Patient WBSN Hospital
5.1 Design of a Multi-Patient WBSN Hospital Room
The aim of this project is to design and simulate a multi-hop, multi-patient WBSN hospital
room using the Zigbee modules in OPNET. The model will be based on the physiological
parameters from  as seen in Table 5.1.
Physiological Parameter Inter-Arrival Sample Data
Signal Range Time Size Rate
(sec) (bits) (kb/s)
Blood Flow 1-300 ml/s 0.025 12 0.48
ECG 0.5-4 mV 0.002 12 6.0
Respiratory Rate 2-50 breaths/min 0.05 12 0.24
Blood Pressure 10-400 mm Hg 0.01 12 1.2
Blood pH 6.8-7.8 pH units 0.25 12 0.048
Body Temperature 32-40 deg C 0.025 12 0.0024
Table 5.1: Physiological Parameters
The proposed topology for the design is seen in Figure 5.1 and includes the following
• Sensors: These devices are responsible for physical data collection and are embedded
on the patient’s body.
• Patient Control Unit (PCU): These devices receive data from the sensors on the
patients body. This unit is located on the patient’s waist for mobile patients and at
the bedside for bed-ridden patients.
• Central Control Unit (CCU): This device is the main controller of the network
and is the PAN coordinator. The CCU receives data from the PCUs and forwards it
for storage or processing.
• Database (DB): This device is where all the data is sent to be stored or processed.
This device will support multiple hospital rooms. The connection of the DB to the
CCU can either be wired or wireless. This is also the point where remote access to
the data is available.
Figure 5.1: Topology of the Multi-Room, Multi-Patient WBSN
The distances used in the simulation are; 7m from PCU to CCU and 0.5m from sensor to
PCU. For this design the PCU, CCU and the DB do not generate any data. The sensors
are the only devices that generate data, which is addressed to the DB via a PCU and the
The ﬁrst step in the design of this network was to determine the respective transmission
power of each device. The sensor devices have the most stringent power requirements. The
CCU and DB could theoretically both have mains power supplied to them. This is not the
case for the sensors or PCU as they are embedded on the patient’s body. Large battery packs
are not appropriate due to weight in regards to patient comfort and mobility requirements.
Using the results from Figure 4.5 the transmission powers in Table 5.2 were initially used
and take topology requirements into account. This was necessary to ensure that devices
Device Max. Transmission Power Transmit
Type Distance (m) Constraint Power
Sensor 0.5 High -50 dBm
PCU 8 High -26.6 dBm
CCU 8 Low 0 dBm
DB 10 Low 0 dBm
Table 5.2: Preliminary Device Speciﬁc Transmit Powers
associate and form the PAN in the manner needed for the scenario in Figure 5.1. In a
hardware prototype the transmission power may diﬀer as the calculations in Chapter 4 only
take into account path loss and not other real world sources of signal degradation such as
obstructions, reﬂections, refraction, scattering and interference.
Hidden Terminal Problem
By changing the transmit power of the devices we are increasing the possible chance of
collisions caused by the Hidden Terminal Problem. In this design, devices such as the CCU
and DB can ’hear’ transmissions from each other and PCUs but not transmissions from
sensor devices as the sensor transmit power is not strong enough. This is also true for PCU
transmissions, as they can ’hear’ transmissions from their own two sensors but not that
from sensors of other PCUs. This could possibly lead to devices sensing the medium as idle
when it actually is not.
Aggregation of Multiple Samples
The six parameters from Table 5.1 were ﬁrst modeled in a network that generated one
packet per sample. This was done to investigate the eﬀect of the speciﬁc inter-arrival times
and data rate before being placed in the WBSN design. The results for this showed large
amounts of delay for the two parameters with the lowest inter-arrival times. In fact the
system did not handle the ECG data at all and its delay was found to be monotonically
increasing. The cause of this was determined not to be the data rate, as the ECG data
rate of this system is only 6.0 kb/s. This value is below both the theoretical limit and the
OPNET simulation limits seen in Chapter 4. The problem was determined to be due to
the low inter-arrival times of the data. The ECG data has an inter-arrival time of of 0.002.
This means that a packet is generated every 2ms. From Equation 4.5 it can be calculated
to show that is takes 2.08ms to send each packet, including overhead, ACKs and wait times.
This shows why the delay is rising monotonically, the packets are being generated at a rate
that is not physically possible to transmit. Another important point to note is that each
packet has 144 bits of overhead at the PHY layer, this overhead is twelve times larger than
the actual data payload, i.e. it is taking 72kb/s to transmit 6kb/s of application data. This
would be a bandwidth ineﬃcient design. The components of the delay were investigated and
the delay was found to be due to the MAC queuing delay which supports the assumption
that data is being generated faster than can be transmitted. The solution to this problem
is to aggregate multiple samples into one packet. This will increase packet size but will also
increase the inter-arrival time thus lowering the packet generation rate. By decreasing the
number of packets being sent we are also reducing the total overhead.
Aggregation of Multiple Measurements
In a real WBSN each measurement would not have its own wireless transmitter. For this
design to model a real life scenario the six measurements will also be aggregated into two
groups, with one sensor for each group. The measurements will be split as follows:
• Sensor 1: This group includes ECG, body temperature and blood pH
• Sensor 2: This group includes blood ﬂow, blood pressure and respiratory rate.
The choice for this segregation was made to spread the average inter-arrival time of diﬀerent
measurements. The data rate required for these sensors are seen in Table 5.3. To physically
aggregate these samples into the same packets it was proposed to create traﬃc source models
at the node model level of OPNET. This was done using the above values and equations
but a problem was encountered when trying to connect these traﬃc sources to the Zigbee
modules. The source code of the application and network layers of the Zigbee modules are
intentionally withheld by OPNET Technologies. Without access to this source code it is
not possible to connect the newly created traﬃc sources. To have access to the source code
you must be a member of the Zigbee Alliance, discussed more in Appendix E. As a result
the calculated data aggregation values have been entered manually into the attributes of
With the data aggregation now deﬁned the inter-arrival times and packet sizes can be
deﬁned. Originally a packet size of 200 bits was modeled to agree with . It was found
that a packet size this small required an inter-arrival time that only supported a WBSN
with two patients. It therefore is not practical to use the packet size presented in  for
an application with these requirements. To solve this problem the data was aggregated
into packets with the maximum size of 128 bytes (1024 bits), with 880 bits available after
considering overhead. The inter-arrival times used are seen in Table 5.3. This takes the
packet generation to approximately 9 packets/s, down from 40 packets/s for the 200 bit
packet size. This design will allow 73 samples to be aggregated into a single packet. When
Parameter Sensor 1 Sensor 2
Data rate (kb/s) 6.0504 1.92
Inter-Arrival Time (s) 0.145 0.485
Table 5.3: Sensor Parameters after Aggregation
considering the delay of a packet the time required to aggregate the samples into the packet
must be considered. The worst case scenario is for the ﬁrst sample to arrive that has to
wait until the 73rd sample has arrived. So the aggregation delay is 145 ms and 485 ms for
sensor 1 and sensor 2 respectively. This has to be added to the end-to-end transmission
delay for a total delay ﬁgure.
5.2 Multi-Patient WBSN Simulation Results
Using the above design the WBSN was simulated form one to six patients 1 . The perfor-
mance of this design is evaluated below with the protocol parameters in Table 5.4 applied.
The average end-to-end delay of the sensor application data is seen in Figure 5.2. As would
ACK Retry Limit 5
Meshed Routing Disabled
Table 5.4: Simulation Parameters
be expected the delay increases as the number of patients increases. The worst case delay is
approximately 170ms with six patients. This is an acceptable delay for medical application
data, an unacceptable delay will be deﬁned here as 2s . This result diﬀers from results
 where delay is the indicator that the system is failing.
Figure 5.3 shows the amount of application data generated alongside the amount success-
fully received at the DB. The network is functioning with reliable data transfer for one to
three patients. The throughput drops to 80% when there are four patients in the network
and this quickly drops to 50% for six patients. After the forth patient is added there is no
increase in application data delivery even though more data is being generated with each
new patient added. Figure 5.3 is used to show both the decreasing throughput as patients
are added and also to show the distinct limit where the network starts to fail. This happens
when there is more than 25 kb/s load. This is well below the limits deﬁned in Chapter 4
and the loss of data could be caused from a number of reason including:
The simulations were run for 5 diﬀerent seed values for a duration of 600s. The average was then taken
to get the results presented
Figure 5.2: End-to-End Application Data Delay
Figure 5.3: Application Data Throughput
• ACK Retry Threshold Exceeded: This is application data dropped by the MAC
layer due to ACKs not being received and the ACK retry limit being exceeded. This
could be due to collisions or the packet’s timeout parameter being exceeded.
• Number of Backoﬀs Exceeded: There is a ﬁnite number of attempts that the
MAC layer has to try and access the medium. If this limit is reached a channel access
failure is reported and the data is lost.
• PAN Formation Errors: If a device fails to form as part of the PAN or is forced
to disassociate and all data generated is discarded. PAN formation errors could occur
for a number of reasons but most commonly is due to problems in the communication
To investigate where the data in our design is being dropped consider Figure 5.4 showing
both the data dropped due to PAN formation errors and ACK retransmission limit being
exceeded. This shows the main loss of data in this network is from PAN formation errors,
Figure 5.4: Dropped Data
although there is still over 3kb/s of data lost to the ACK retransmission limit being ex-
ceeded. When there are six patients in the network 43.8% of all application data generated
is not even attempted to be tranmsitted due to the device not currently being part of the
PAN. This PAN formation error is commonly due to a problem with the communication
channel. When there is a problem with the communication channel a device can become
an orphan if it loses communication with its coordinator , or disassociates. When this
occurs the device stops transmitting data and broadcasts orphan notiﬁcations to try and
rejoin the PAN. These orphan notiﬁcations are similar to the management data sent at
initial PAN formation. The reason for the large amount of disassociation in the network
is due the hidden terminal problem. The only devices disassociating are the sensors which
have a lower transmission power than the other devices. This causes other devices not to be
able to detect transmissions from the sensors allowing them to transmit at the same time
causing collisions at the PCU receiver. In the design each PCU can only detect transmission
from their own sensors, and not that from neighbouring patients. The BERs of the three
receiving devices are seen in Figure 5.5. This BER cannot be used to calculate the packet
error rate (PER) as the bit errors are not independent and evenly distributed. Converting
BER to PER using P ER = 1 − (1 − BER)L , where L is packet length, gives a much larger
PER than there actually is. As can be seen all devices experience a large jump in BER from
Figure 5.5: PCU, CCU and DB BER
three to ﬁve patients. This BER is the critical factor limiting this network’s performance.
Another reason for the large amount of collisions in this scenario is the maximum value of
the Backoﬀ Exponent used in IEEE 802.15.4. It’s maximum value is deﬁned as 5 which
limits the number of backoﬀ slots to 31 (more details of this are given in Chapter 6). This
is much lower than that used in IEEE 802.11 which has 1023 maximum backoﬀ slots .
This will degrade performance quicker as more nodes are added because this small backoﬀ
period makes collisions more likely. Collisions not only limit throughput but they also add
more delay. This is due to retransmissions of the data and collisions also require an increase
in the Minimum Backoﬀ Exponent (discussed in more detail in Chapter 6) which increases
the probable time that the device has to wait to retransmit, thus increasing the MAC delay.
From the results presented in this section it can be stated that the maximum number of
patients supported by this network is three. Adding patients beyond this causes excessive
data loss that is unacceptable for medical data. Chapter 6 will attempt to increase the
network performance and eﬃciency while focusing on the QoS of data from critical pa-
tients. In doing this it is hoped to increase the number of supported patients to six. The
current design, while supporting six patients, has a throughput of 53% and a goodput of
33%. Throughput is deﬁned as the total application data received as a percentage of total
application data generated and the goodput is deﬁned as the application data received as
a percentage of total bits received by the DB’s radio receiver. In addition to the results
presented here the full results are presented in Table B.1. It must be noted that the IEEE
802.15.4 MAC layer can not easily support diﬀerent throughput performance for individual
nodes . Therefore in our system, with nodes generating data at diﬀerent data rates,
network eﬃciency will be hard to achieve.
Improvements for Critical Patient
Now that a WBSN has been designed, simulated and evaluated it is now time to improve
the QoS for critical patient data. Initially it was decided to treat one sensor (the one
containing ECG data) as critical and the other sensor as non-critical. For this scenario the
parameter changes would only be valid for one hop, the following hops would treat both
data types equally. To get around this I introduced a critical patient scenario where all
the data from half the patients is treated as critical and all the data from the other half is
treated as non-critical. This ratio between critical and non-critical patients has been chosen
arbitrarily and doesn’t model any real hospital scenario. The data rates of the two patient
types has been kept constant although in reality non-critical patients may not need all data
6.1 Network Backbone
The topology used so far is based on  where the CCU in every room transmits wirelessly
to the DB (or equivalent device) where central processing and remote access takes place.
This type of network becomes very congested as the number of rooms increases as it intro-
duces a ’bottleneck’ into the network. A better alternative is to connect the rooms using a
wired connection, as used in  or possibly by a wireless standard that can handle the larger
load as in . The latter raises interference concerns that are investigated in Chapter 7.
For the remainder of this chapter we will consider a topology that replaces the ﬁnal wireless
hop to the DB by a WLAN. The WLAN hop will not be simulated and therefore analysis of
the network will stop at the CCU. In the current network structure all the data that is sent
to the CCU is forwarded to the DB. Each patient generates approximately 9 packets/sec.
Combined with all six patients this in 54 packets/sec. This data needs to be forwarded to
the CCU which brings it to 108 packets/sec, and the ﬁnal link to the DB doubles it again
to 216 packets/sec. This is an approximation and does not include retransmission, which
would aﬀect the results signiﬁcantly in such a congested network. The network was re-
simulated with the ﬁnal hop replaced by a theoretical WLAN link to produce the following
results. The end-to-end delay was decreased by 58%, although the ﬁnal WLAN hop is not
included. The less congestion has reduced the loss of data from PAN formation errors by
55% and 50% less data is lost due to exceeding the ACK retranmsission limit. The goodput
of the network has doubled and is now 65% which is expected as we have halved the total
load on the network. More importantly the throughput has increased to 75%, an increase
of 22%. In addition to the results presented here the full results are presented in Table
B.2. When considering the results from this point on it must be remembered that the ﬁnal
WLAN link is not included in the simulation.
6.2 CSMA/CA and MAC Parameter Modiﬁcations
As discussed in Chapter 2 and as seen in Figure A.3 there are multiple parameters that aﬀect
the performance of the unslotted CSMA/CA protocol. In this section the results of varying
these parameters are presented. To improve the QoS of the critical patient data diﬀerent
CSMA/CA parameters will be applied to the data of diﬀerent patients. It is predicted that
by treating critical patient data diﬀerently it’s delay can be reduced at the cost of, within
limits, the non-critical patient data. The following parameters are investigated:
• Maximum Number of Backoﬀs: This is the maximum number of backoﬀs that the
CSMA/CA algorithm will perform while trying to access the medium before declaring
a channel access failure .
• Minimum Backoﬀ Exponent: This is the minimum value of the backoﬀ exponent
in the CSMA/CA algorithm which is used to randomly ﬁnd the number of backoﬀ
• ACK Mechanism: This is the mechanism used to ensure reliable transmission of
data. If the ACK is not received during the ’macAckWaitDuration’ it will be marked
as failed and the MAC will retransmit . This is repeated until the retry limit,
’aMaxFrameRetries’, is reached and the packet is discarded.
Each parameter we are going to vary has a direct impact on Equation 4.2 and therefore a
direct impact on the delay of the data. The maximum number of backoﬀs and minimum
backoﬀ exponent both aﬀect TBO while the ACK mechanism aﬀects TT A and TACK .
6.2.1 ACK Mechanism
When the ACK mechanism is enabled the receiver must send an ACK packet to the trans-
mitter when it successfully receives data packets. The following results compare the network
performance when ACKs are enabled on all data, no data and on only critical patient data.
When ACKs are completely disabled the critical data has an unacceptable loss of 28%. For
this reason alone this scenario cannot be used, independent of the 46.8% reduction in end
to end delay. The scenario where only critical data is acknowoledged is ideal for our appli-
cation. By partialy disabling ACKs the end-to-end delay of both critical and non-critical
data has been reduced by 24.5% and 59.5% respectively. In addition to this the critical
data has negligible data loss while the non-critical data is losing 26.1% of data genarated,
which is acceptable for this type of data. In addition to the results presented here the full
results are presented in Table B.3. This improvement in delay requires an understanding of
the ACK mechanism process. When ACKs are disabled on all or some devices less control
data needs to be transmitted. These ACK packets do not use CSMA/CA to access the
medium, instead they uses timing to ensure that nodes don’t transmit until after the ACK
frame has been received. The timing for ACK frames is seen in Figure 6.1. So while the
ACK frames do not actively contest for the medium they do occupy bandwidth by using
dedicated timing intervals, Tack and TT A , that otherwise could be used for data transfer.
By disabling ACKs both TT A and TACK can be excluded from Equation 4.2. TACK is the
time it takes to transmit the ACK packet and TT A is the turnaround time which is used to
Figure 6.1: ACK Timing Diagram
give the device time to change from receive state to transmit state. These parameters have
TT A = 0.192ms (6.1)
TACK = = = 0.352ms (6.2)
TT A + TACK = 0.544ms (6.3)
In our system 108 packets are generated per second excluding retransmissions. Therefore
the minimum time required every ACK transmission is 58ms. This is 5.8% of the total
time available for tranmsission. This value is the minimum boundary and will rise when
restrnamsisisons are necessary, which as seen in Chapter 5 are common in this design.
The ACK retry threshold (aMaxFrameRetries) was also investigated to ﬁnd an optimal
value and Figure 6.2 was produced. This shows that almost 80% of failed data attempts are
Figure 6.2: Eﬀect of ACK Retransmission Limit (aMaxFrameRetries)
sucessful on the ﬁrst retransmission and 94% are sucessful after the second retransmission.
This success rate does not reach 100% until seven retransmissions. The eﬀect of increasing
the ACK retransmission limit was found to have no eﬀect on delay and minimum eﬀect on
management data transmission with only 455 bits/sec extra from two to seven retranmsis-
From the results presented in this section the ﬁnal WBSN design will only enable ACKs for
critical patient data. This will improve network performance while ensuring critical data
reliability. The ACK retransmission limit will be increased suﬃciently to ensure complete
critical data delivery, as increasing this limit has acceptably low degradation eﬀects on net-
work performance. The reduction in control data sent could also have a positive eﬀect on
power consumption and battery life, presently there is no function to measure this.
6.2.2 Minimum Backoﬀ Exponent
The number of backoﬀ slots for each delay period is randomly chosen from the range
[0,2BE − 1]. The Backoﬀ Exponent (BE) is initially set to macMinBE. So by reducing
macMinBE (the lower bound of the random interval) the average backoﬀ period can be
reduced. The standard deﬁnes aMaxBE to 5 and macMinBE has a default value of 3, but is
user deﬁned between 0 and 3. In this section macMinBE was varied for the critical patient
data for values of 3, 2, 1 and 0 (collision avoidance disabled for the ﬁrst iteration of the al-
gorithm). This was done to all critical data nodes (sensors and PCU) and again for only the
PCU. The results for these two scenarios are quite similar, having the same shape curves.
For simplicity the scenario where only the PCU macMinBE was varied is presented here
as it had slightly better performance due to a lower BER. Figure 6.3 shows a decreasing
delay with decreasing macMinBE, which agrees with , excluding when collision avoid-
ance is disabled which is discussed shortly. The reason for the decreases in delay can be
explained by referring back to Equation 4.3. By reducing macMinBE it reduces the number
of individual backoﬀ slots, given by BOslots in the equation. The reduction in the delay is
speciﬁcally due to a decrease in the MAC delay. The cause for this decrease in MAC delay
is because when macMinBE is decreased lower than its default the lower boundary of the
range of possible backoﬀ values decreases as well . This will shorten the average waiting
time when the CCA senses the medium busy or when a packet collision occurs. With this
Figure 6.3: macMinBE Eﬀect on Delay
higher probability of selecting a shorter backoﬀ time, more CCAs will be attempted per
time interval which increases the chance of a successful transmission . This increases
the critical data throughput, as seen in Figure 6.4. This agrees with [34, 4] which found
that the throughput of nodes with smaller macMinBE increased. Except it must be noted
that there is a drop in throughput when macMinBE is one. This stepped increasing curve is
also seen for the scenario where the sensors macMinBE is edited as well. This same result is
obtained when averaged against more simulations at diﬀerent seed values and also for longer
simulation runs. This eﬀect is though to be due to synchronisation among transmitters with
constant traﬃc generation parameters coupled with the limited randomness in the backoﬀ
period . This was veriﬁed by re-running the simulations with exponential inter-arrival
time. The results did not show the same stepped increase. Exponential distribution is not
a valid parameter in our design as the sensors in real medical devices usually produce data
at a constant rate.
When macMinBE is zero there is a drop in the non-critical data throughput which corre-
sponds with a rise in delay. This is due to collision avoidance being disabled for the ﬁrst
iteration of the CSMA/CA protocol. For this scenario the channel access timing is deﬁned
by the minimum inter-frame spacing (aMinLIFSPeriod) . This means that the critical
data does not perform random backoﬀs before attempting a CCA. This has a dramatic eﬀect
Figure 6.4: macMinBE Eﬀect on Throughput
on the BER of the network as seen in Figure 6.5 which in turn causes the lower throughput
and higher delay. This rise in BER does not have a negative impact on the critical data
throughput because retransmission are enabled although the retransmissions do increase
the delay. The critical data has more chance to transmit as it is accessing the channel with
It is important to note at this stage that while the shape of the curves shows an improve-
ment for the critical data the actual improvement is limited. The increase in throughput is
only 1.45b/s for the critical data. This can be explained by the ﬁndings of  which found
that a smaller macMinBE results in lower throughput when there are suﬃcient nodes in
network. The number of nodes in this design is not enough to have a decrease in throughput
although the increase is extremely limited. This is because in our network design there are
many collisions from the hidden terminal problem. Whenever a collision occurs the node
will have to backoﬀ and try again with an incremented macMinBE. In our network, because
of the large amount of collisions, the maximum backoﬀ exponent is quickly reached. Con-
sequently most of the transmission will use the maximum backoﬀ exponent and the eﬀect
of decreasing macMinBE will be limited .
Using the above results it is concluded that the default value of macMinBE is not the op-
timal value for critical data. It is recommended to use a macMinBE of one for the critical
Figure 6.5: macMinBE Eﬀect on BER
data. This gives improvements in delay and throughput without incurring the increase in
BER that degrades the non-critical data, seen when collision avoidance is disabled.
6.2.3 Maximum Number of Backoﬀs
Every time a backoﬀ is performed and the CSMA/CA protocol senses the channel as busy
the number of backoﬀs is incremented until its maximum limit is reached. When this limit
is reached a channel access failure is declared and the data is dropped. This limit is the
macMaxCSMABackoﬀs parameter and is user deﬁned in the range [0,5] with a default value
of 4. This eﬀectively limits the number of CCAs that can be performed before the data
is dropped. This section deals with the results of varying macMaxCSMABackoﬀs for the
non-critical patient data in an attempt to make it less persistent and free up the medium
for critical patient data. It was found that as macMaxCSMABackoﬀs was varied from its
maximum to it minimum value (0-5) there was no change in the network performance at all.
This result could be obtained from a network that is operating at a low load where the data
is successfully transmitted ﬁrst attempt and does not require multiple attempts to access the
medium. This is not the case for our design that is operating near capacity.  found that
by decreasing the backoﬀ value and thus increasing the transmitters persistence, achieves a
higher goodput. To ensure that the unexpected results are not due to our speciﬁc multi-hop
topology the simulation from  was repeated and it was found the there was still no eﬀect of
varying macMaxCSMABackoﬀs. From this it can be concluded that the Maximum Number
of Backoﬀs attribute in OPNET is not functioning correctly, this conclusion was conﬁrmed
by OPNET Technical Support, see Appendix E for more information. As a consequence no
results could be obtained for this section.
6.3 Transmission Power
The CCU and DB have a relatively high transmit power of 0 dBm due to the fact that they
are not power constrained devices. This high transmit power could actually be having a
negative eﬀect on the performance of the network as it is transmissions from these devices
that cause collisions at the PCU receiver. This section treats these transmit powers as if they
are power constrained devices and the BER is investigated. By reducing the transmit power
to that in Table 6.1 the CCU, DB and PCU BERs were improved by 74.0%, 72.9% and 79.2%
respectively. One eﬀect of reducing the transmit powers is that a device’s transmissions do
Sensor PCU CCU DB
Transmit Power -50.0 dBm -26.6 dBm -26.6 dBm -26.6 dBm
Table 6.1: Final Device Speciﬁc Transmit Powers
not reach as far and therefore do not have an impact on as many receivers. Another factor
is that when there is a collision the interfering signal has a lower power and the SNR is
higher leading to a lower probability of a bit error.
6.4 Combined Results
The following ﬁnal simulation of the WBSN incorporate all the previous improvements. The
improvements are WLAN backbone, partly disabled ACK mechanism, increased ACK retry
limit, macMinBE of one for critical data and a reduced transmit power for the non power
constrained devices. It was found that all aspects of delay (queuing, MAC and end-to-end)
have been improved. The delay improvements for non-critical data are better than that of
the critical data, with end-to-end delay improvements of 87% and 64% respectively. The
reason for the delay of the critical data not having as great an improvement is due to the
overhead introduced to ensure reliable data delivery. The application data throughput for
critical data has improved to 100% where as the non-critical data is only at 61%. Therefore
it can be stated that by improving data reliability we are introducing overhead that can
actually limit any delay improvements. This trade-oﬀ needs to be considered along with
data delivery requirments when optimising QoS. The critical PCU, non-critical PCU and
CCU BERs have improved by 43%, 55% and 77% respectively. Even after considering these
improvements collisions from the hidden terminal problem are still a problem. One solution
is to use a RTS/CTS handshake or by using the GTS in the beacon-enabled version of
the protocol. This would allow data transfer to be centrally controlled thus eliminating
multiple devices trnamsitting at the same time. The overall goodput has been increased
to 70%. This improvement is mainly due to the exclusion of the ﬁnal hop to the DB.
This extra hop limited the performance of the system and is better replaced with either a
wired standard or a WLAN link. Overall improvements can also be seen by the complete
elimination of data lost from PAN formation errors and from ACK retransmission threshold.
In addition to the results presented here the full results are presented in Table B.4 and B.5.
As introduced in Chapter 2 both IEEE 802.15.4 and IEEE 802.11b use the unlicensed ISM
frequency band to transmit data. This section relates to modeling interference eﬀects of
IEEE 802.11b on IEEE 802.15.4 that might exist in a hospital environment. More speciﬁ-
cally the results from [14, 4] are continued for a multi-hop WBSN in a medical environment.
7.1 Modeling Interference in OPNET
When attempting to model Zigbee and WLAN devices in the same simulation environment
OPNET records ’recoverable errors’. This is because the WLAN and Zigbee models are
not compatible to co-exist in the same simulation environment. The errors are due to
limitations in the wireless pipeline stages used by the WLAN model in OPNET. Those
pipeline stages can handle only WLAN packets and unformatted packets, creating errors
when they receive Zigbee packets, see Appendix E for a detailed explanation. It is possible to
model these two standards in the same simulation if the distance between them is suﬃcient
so that the Zigbee transmissions don’t exceed the reception power threshold of the WLAN
receivers. This means that WLAN will not sense the packet and the networks will interfere
with each other. This scenario is not useful to us we require the devices to be in close
proximity. Two solutions to this problem were devised. The ﬁrst of them being the creation
of interference sources at the node level to model WLAN transmissions, and the other being
the modiﬁcation of existing WLAN modules to allow compatibility with Zigbee.
7.1.1 Modiﬁcation of Existing Nodes
The existing WLAN nodes were edited to allow compatibility with Zigbee so that the
interference eﬀects could be studied. The WLAN radio receiver at the node model level
was edited to support Zigbee frames. This allowed the two standards to be simulated at
the same time but did not show any signs of interference. More work will be done in the
future to allow coexistence between the two standards although at the time of printing this
report coexistence had not been achieved.
7.1.2 Interference Model
To solve the above problem interference models were created that generates wireless radio
signals modeling that of WLAN. These interference models mimic the WLAN PHY layer
(frequency, bandwidth, data rate, modulation, packet size) but with limited MAC layer
attributes. In this approach the interference nodes constantly transmit at the desired data
rate but as there is limited MAC layer there is no CSMA/CA or any other channel access
protocol. These devices are therefore transmitting ’blind’ and yields a worst case scenario
to the Zigbee transmission. The interference nodes were all created with the same basic
structure which is described below:
• Processor(s): The processor is used to generate packets. This source deﬁnes the
packet size, inter-arrival time, packet type and other data generating features. More
than one of these sources can be used to generate diﬀerent components of an applica-
tion (e.g. two objects of diﬀerent sizes for a web page download).
• Radio Transmitter: This is where the radio pipeline stages are deﬁned. For a
transmitter this means speciﬁcation of the Receiver Group, Transmission Delay, Link
Closure, Channel Match, Tx Antenna Gain and Propagation Delay stages, explained
in more detail in Appendix C. Also modulation, channel capacity, frequency, band-
width, allowed packet type and other physical attributes are deﬁned.
• Antenna: This is an optional feature that was included for possible future work in
directional gain. It currently models an isotropic antenna.
Selection of appropriate speciﬁcations for each of the pipeline stages mentioned above is
critical to ensure the interference is treated as just that and not a valid or invalid packet.
In creating the interference sources the following pipeline stages were used.
• Receiver Group: The dra rxgroup model has been used for the interference nodes.
In this model all receivers are considered potential destinations by default and will
ensure that outside interference sources create receiver groups that contain all Zigbee
• Transmission Delay: The default WLAN transmission delay model won’t be used
for the WLAN interference nodes, instead the dra txdel model will be used. This
is because the default WLAN model gets the channel data rate from the packet it-
self instead of the transmitter channel, this is done because all the diﬀerent WLAN
standards (with diﬀerent data rates) use the same transceiver channel. The created in-
terference nodes will model IEEE 802.11b at a set data rate (11 Mb/s) so the dra txdel
model will be used that will get the transmission delay using the channel data rate
and packet length speciﬁed.
• Channel Match: This is the stage were the interference nodes parameters will diﬀer
from that of Zigbee and hence will be treated as noise from this point on. The
frequency ranges of the interference nodes and Zigbee must at least overlap otherwise
the packets from the interfering node will be ignored. Zigbee and WLAN use QPSK
and CCK respectively and this parameter alone will force WLAN data to be treated
Table 7.1 shows the speciﬁcations of the created WLAN interference nodes along side that
of the IEEE 802.15.4 system.
Attribute WLAN IEEE 802.15.4
Tx Power 25mW 1mW
Modulation CCK QPSK
Bandwidth 22 MHz 2MHz
Data Rate 11 Mb/s 250 kb/s
Frequency 2487 MHz 2480 MHz
(Ch 14) (Ch 26)
Table 7.1: WLAN Interference Node Technical Speciﬁcations