Communication Protocols for aMulti-Hoping Wireless Body Sensor

Network

Garrick Bugler (3017767)

October 28, 2008

Academic Supervisor: Mehmet Yuce

A thesis submitted in partial fulfillment of the requirements

for the degree of Bachelor of Engineering in Telecommunications Engineering at The

University of Newcastle, Australia.

Table of Contents

Table of Contents i

Abstract iv

Contributions v

1 Introduction 11.1 Wireless Sensor Network Evolution . . . . . . . . . . . . . . . . . . . . . . . 11.2 WSN Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 WSNs in Medical Environments . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Technical Background 62.1 MAC Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Medium Access Control Layer . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Non-Beaconed Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.2 Unslotted CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 Interference and Coexistence . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Literature Review and Proposed Work 133.1 Multi-Patient WBSN Design . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Priority For Critical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Interference Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 MICS and WMTS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 OPNET and Theoretical Limits 184.1 Theoretical Delay and Throughput . . . . . . . . . . . . . . . . . . . . . . . 184.2 OPNET Channel Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Transmission Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

i

ii

5 Multi-Patient WBSN Hospital Room 275.1 Design of a Multi-Patient WBSN Hospital Room . . . . . . . . . . . . . . . 275.2 Multi-Patient WBSN Simulation Results . . . . . . . . . . . . . . . . . . . . 32

6 Improvements for Critical Patient Data 376.1 Network Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 CSMA/CA and MAC Parameter Modifications . . . . . . . . . . . . . . . . 38

6.2.1 ACK Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2.2 Minimum Backoff Exponent . . . . . . . . . . . . . . . . . . . . . . . 416.2.3 Maximum Number of Backoffs . . . . . . . . . . . . . . . . . . . . . 44

6.3 Transmission Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.4 Combined Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Interference Analysis 477.1 Modeling Interference in OPNET . . . . . . . . . . . . . . . . . . . . . . . . 47

7.1.1 Modification of Existing Nodes . . . . . . . . . . . . . . . . . . . . . 487.1.2 Interference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.1.3 Limitations of Designed Nodes . . . . . . . . . . . . . . . . . . . . . 50

7.2 Interference Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.2.1 WLAN Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.2.2 Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2.3 Frequency Band Overlap . . . . . . . . . . . . . . . . . . . . . . . . 547.2.4 IEEE 802.15.4 Packet Size . . . . . . . . . . . . . . . . . . . . . . . . 55

7.3 Interference Effects on Multi-Patient WBSN . . . . . . . . . . . . . . . . . . 56

8 Modeling MICS and WMTS Services 598.1 Medical Implant Communication Service (MICS) . . . . . . . . . . . . . . . 598.2 Wireless Medical Telemetry Service (WMTS) . . . . . . . . . . . . . . . . . 608.3 OPNET Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

9 Conclusion and Future Work 639.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A Beacon-Enabled Mode and CSMA/CA Algorithms 65A.1 Beacon-Enabled Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65A.2 Slotted CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.3 Unslotted CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

B Simulation Results 71B.1 Original Design Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71B.2 Improved Design Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

iii

C Wireless Transmission of Data in OPNET 74C.1 Radio Transceiver Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . 74C.2 Graphical Radio Transceiver Pipeline Stages . . . . . . . . . . . . . . . . . . 81C.3 Standard Specific Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . 82

D MICS and WMTS Implementation Code 83D.1 Dual Implementation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 83D.2 WMTS Implementation Code . . . . . . . . . . . . . . . . . . . . . . . . . . 86D.3 MICS Implementation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

E OPNET Limitations, Constraints and Error Messages 93E.1 General Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93E.2 Zigbee Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95E.3 Modeling Custom Scenarios Problems . . . . . . . . . . . . . . . . . . . . . 96E.4 Interference Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Bibliography 99

Abstract

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 effects 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 Backoff Exponent, ACK

Mechanism, and Maximum Number of Backoffs were investigated. It was found that ACKs

should only be enabled on critical data and that the critical data should use the smallest

Minimum Backoff 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 sufficient quality of

service considerations to handle low interference levels. However it is recommended to use

different, 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

defined specifically 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.

iv

Contributions

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 final design wireless body sensor network with recommendations and con-

straints defined.

4. Design and construction of an interference model for various wireless local area net-

work applications.

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

v

Chapter 1

Introduction

1.1 Wireless Sensor Network Evolution

In the past, the most common form of information processing has been done on multi-

purpose computational devices [1], with the most common being the home PC or office

server. These applications are generally controlled by the user and are not directly influ-

enced by their physical environment [1]. There is an opposing system where the physical

environment has a large influence on and is also the focus of the system [1]. In these appli-

cations the computer system exerts control on the physical system, its actions and reactions

are predefined 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 [2]. Embedded micropro-

cessors can be found in many everyday items such as washing machines, mobile phones and

in cars [1]. 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 [1]. 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 [1]. In the last few years a solution to these problems

has emerged [1]. Wireless Sensor Networks (WSN) are made up of individual nodes that

sense and control their physical environment while also communicating wirelessly between

1

2

each other to achieve their goal. WSNs usually have three main functionalities, these are

computation, wireless communication and sensing or control [1].

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 fixed

to machinery in positions that are difficult 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 [1].

• Precision Agriculture: Sensor nodes are placed to detect humidity and soil compo-

sition in paddocks to allow precise irrigation, fertilisation and pest control measures

[1].

• Intelligent Buildings: Sensor nodes monitor real-time values of temperature, hu-

midity, airflow and other physical parameters in a building to efficiently control air

conditioning to optimise power consumption [1].

• Telematics: Sensors embedded along the roadside monitor traffic conditions and can

then update electronic billboards informing drivers of traffic congestion [1].

• Logistics: Sensor nodes can be embedded in product shipments or even in individual

packets to track deliveries and update stock counts [1].

• 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 [1].

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.

3

1.3 WSNs in Medical Environments

Monitoring patients and collecting data for analysis is a major issue for health and disease

management [3]. The use of Wireless Body Sensor Networks (WBSN) for this application

makes the task seamless and easy [3]. 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 [4]. Many current day hospitals collect patient data using RS-

232 port interfaces that are permanently connected to the monitoring device [4]. WSNs

have been earmarked for use in medical applications for a number of reasons, these include:

• Cost Effectiveness: Many hospitals located in old buildings are not suitable for

wired technologies from a cost-effective view point [5].

• Mobility: Doctors can access patient information from anywhere in the hospital or

remotely over the internet whenever needed [5].

• Installation Flexibility and Scalability: Wireless networks can reach places that

are restricted to wires while also being configured to different topologies depending

on the current need [5].

• Integratable: WBSNs eliminate incompatibility issues where each manufacture cre-

ates its own proprietary data link layer [4]. They can operate as an independent

system or in conjunction with an already existing WLAN or LAN [5]. This also helps

offer complete information to an industry where information is often fragmented and

not properly centrally stored [4].

There are a number of different ways in which WSNs can be used in medical applications.

Some include:

• 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

error.

4

• Drug Administration: WBSN can be used to automatically administer drugs to

patients [1] 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 [1]. 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 [7].

• Alarm Notifications: 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 off [7].

• Patient Transfers/ Asset Tracking: WBSN can be used to know where patients

and equipment are at all times, even when being transferred between hospitals [7].

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 [4]. 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 configured and reconfigured [4]. The new standard

will define the physical (PHY) and media access control (MAC) layer to develop a low cost,

ultra low power and highly reliable wireless network [8]. It is likely to be based on the

IEEE 802.15.4 MAC layer with a new PHY layer defined [8]. Two services specifically for

medical data collection have also recently been released [9]. These are the Medical Implant

Communication Service (MICS) and Wireless Medical Telemetry Service (WMTS). WBSN

are currently being used in multiple medical applications [10]. An example of a WBSN in

use today is for detection and prediction of physiological parameters including wakefulness,

5

fatigue and stress [3]. 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 beneficial but also ethically controversial [1]. In practical applications

issues such as the security of the patient’s data must be considered [27], this is not discussed

in the report but is covered in [44].

Chapter 2

Technical Background

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 efficiently shared among devices [29]. Furthermore in a medical

environment the MAC protocol must be reliable, have flexible transmission mechanism

and have a high channel efficiency [6]. The three primary MAC protocols that have been

earmarked for medical applications are Time Division Multiple Access (TDMA), polling,

and contention based protocols [6]. 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 traffic 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 [6]. The performance of a contention

based protocol could degrade when the load increases past this point but this is improbable

in a medical WBSN [6].

6

7

2.2 IEEE 802.15.4

This report specifically deals with the IEEE 802.15.4 protocol. The IEEE finalised this

standard in October of 2003 [1]. IEEE 802.15.4 defines both the PHY and MAC sub-

layer [14] of the data link layer [17]. It was designed as a Wireless Personal Area Network

(WPAN) with low complexity, low cost and low power consumption as it’s key parameters

[14], making it ideal for a WBSN in a medical environment. It was designed for use between

fixed 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 [1] that uses IEEE 802.15.4 for its PHY and

MAC layers, while adding its own network, security, application and other layers [1]. The

upper layers are defined by the Zigbee Alliance [19] as seen in Figure 2.1 adapted from [28].

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

effects of narrow band noise and interference [1]. IEEE 802.15.4 operates at a range of

frequencies, speeds and modulation types for different geographical regions. A summary of

these parameters can be seen in Table 2.1. The three frequency bands listed are part of

the Industrial Scientific Medical (ISM) band [32]. The 2.4 GHz band provides the highest

8

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 Specifications

bandwidth per channel and the greatest number of channels (16 non overlapping) and is

the dominant band for IEEE 802.15.4 chips [15]. 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 [32]. There are a total of 27

different 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 [1].

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 [7]. 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 [29]) 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) [1]. 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 defined 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]:

9

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) [1].

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 [1]

• To allocate addresses to these RFD [1]

• To broadcast beacons in beacon-mode [1]

• To exchange data packets with RFD and with peer coordinators [1].

Coordinators, Routers and End Devices can form a one-hop star topology or a multi-hop

peer-to-peer topology [14] as seen in Figure 2.2 adapted from [28].

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

10

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 [13].

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 [33] . This mode is simpler and

uses much less overhead than the slotted version [31].

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

[1]. The behavior of unslotted CSMA/CA is determined primarily by two parameters, the

Backoff Exponent (BE) and the Maximum Number of Backoffs (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 [11].

• The variables NB and BE are initialised with NB is set to zero and BE is set to

macMinBE [11]. macMinBE is a protocol parameter in the range [0, 3] which is user

defined with a default of 3. BE can have a value in the range macMinBE and aMaxBE

(5). NB has a user defined maximum value in the range [0, 5], with a default of 4.

• The number of delay backoff periods is found randomly from the interval [0, 2BE − 1]

• A CCA is performed after the delay to sense if the channel is busy [11].

• 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 [11].

11

• 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 [11].

2.5 Interference and Coexistence

Wireless systems continue to gain popularity at an increasing rate [15]. 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

[15] 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 [4]. Some applications are resilient to packet loss from

interference but in a medical environment the highest reliability in transmission is needed

[15]. There are currently three wireless standards in the ISM band, not including other EM

sources like microwaves and cordless phones [15]. These standards use different 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

different standards which could result in performance degradation [14]. This Quality of

Service (QoS) issue is not only related to packet loss and transmission delays but also

includes jitter, availability and security [15]. 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 significantly

impacting the performance of any of the other device or system [15]. For each individual

standard, channel access and collision avoidance were designed to work only within that

one system [15]. It is now necessary for each standard to deal with interference form other

standards to be able to function correctly.

IEEE 802.11b

IEEE 802.11b is one protocol out of a group of protocols that define 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

12

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 [14], although the interference effect 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

802.15.4 [15].

Some IEEE 802.11b Wireless Access Points (WAPs) make use of Dynamic Channel Selection

(DCS). In this process the WAP analyse the utilisation of different channels before deciding

on which channel to transmit on [15]. IEEE 802.15.4 has an Energy Detection (ED) function

to determine the activity of another system but lacks a DCS tool [15].

Chapter 3

Literature Review and Proposed

Work

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

Literature Review

In [16] 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 [8]

to examine the performance of a IEEE 802.15.4 MAC based WBAN operating in different

patient monitoring environments.

Proposed Work

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.

13

14

3.2 Priority For Critical Data

Literature Review

In [23] 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 [22]. 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 [23]. This prototype is extended in [24] to allow high priority frames to

perform only one CCA, instead of the usual two [22]. This frame tailoring strategy aims

to avoid collisions between data frames and ACK frames [22]. 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 [22] the CSMA/CA protocol parameter’s are varied and applied alongside some basic

queuing strategies (FIFO and priority queuing) [22]. This paper shows that by adequately

tuning various parameters of slotted CSMA/CA improvements can be made to the QoS

for time critical data [22]. [25] showed that for large scale WSNs the average delay of

broadcast frames increases with the minimum back off exponent, although this does not

affect the BER [22]. It also shows that for small scale WSNs the BER decreases with an

increase of the minimum backoff exponent [22]. [22] uses these results by not having the

same parameter values for the two different types of traffic (data and command traffic).

In addition to changing the parameter values, priority queuing can also be implemented

to reduce the queuing delay of high priority data [22]. [22] 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 [34] has created a simulation model for a optimised

MAC processes. Also [43] has created a Markov chain model to provide insight into the

strengths and weaknesses of varying protocol parameters.

15

Proposed Work

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 [14]. Particular

attention will be given to delay, throughput and BER. The parameters that will be optimised

for critical data include:

• Maximum Number of Backoffs

• Minimum Backoff Exponent

• ACK Mechanism

This report will also consider the effects of using other standards as the backbone of the

network that connects multiple hospital rooms to the data storage and remote access loca-

tion.

3.3 Interference Analysis

Literature Review

[4] investigates the interference between multiple IEEE 802.15.4 systems. This mutual in-

terference can be avoided by choosing different channels for different systems, as there are

16 to choose from. This can be done through manual configuration or by implementing op-

tional dynamic procedures [4]. [4] investigated the effects 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. [4] also investigated the effects of WLANs on IEEE 802.15.4 for

different applications, including file 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

16

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 significant 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 [4] 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 [4]. It can therefore be stated that

in [4] it was shown that WLANs significantly 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 [15] which used hardware instead

of simulations to show a coexistence issue and also by [14] which examined the reduced

interference when systems are moved apart in both the frequency and distance domains.

Proposed Work

All the scenarios in the above research looked at the interference effects 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

Literature Review

The Medical Implant Communication Service (MICS) and Wireless Medical Telemetry Ser-

vice (WMTS) are new services dedicated to data collection in the medical environment. [9]

has reviewed regulatory standards and the characteristics of MICS transceivers. [39, 40, 6]

17

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-

nications.

Proposed Work

This report aims to model IEEE 802.15.4 using the WMTS and MICS services by mod-

ification of existing OPNET source code. This model will be based on the implantation

presented in [39] in relation to specific transceiver parameters. This new model will give a

simulation base for future analysis and improvement to the prototype presented in [6].

Chapter 4

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 [31]. The following calculations are taken from [31] and are presented using values

relevant to our design. The calculations are based on an ideal channel with the following

assumptions:

• The throughput is calculated using one transmitter and one receiver located close to

each other.

• 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 buffer overflow.

• The transmitting device always has adequate packets to send.

To calculate the throughput, the delay first needs to be calculated. This delay includes

the delay from sending the data packet and also the delay caused by elements of the frame

18

19

sequence (backoff schemes, inter-frame spaces, sending of ACKs etc.) The delay to transmit

one packet is related to the throughput by the following equation:

TP =8x

delay(x)(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 + Tframe(x) + TTA + TACK + TIFS(x) (4.2)

Where

• TBO is the backoff period

• Tframe(x) is the transmission time for x payload bytes

• TTA is the turn around time

• TACK is the transmission time for an ACK

• TIFS 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 backoff period. The back off period

is expressed as follows:

TBO = BOslots • TBOslots(4.3)

Where:

• BOslots is the number of unit backoff slots

• TBOslotsis the time for each backoff slot (aUnitBackoffPeriod)

As seen earlier the number of backoff slots is a random number in the interval (0, 2BE − 1)

where BE is the backoff exponent and has a default minimum of 3 [31]. As we are assuming

ideal conditions and only one transmitter, this value can be treated as a constant. Therefore

20

the number of backoff slots can be represented as the average of the interval, which is 3.5.

Also the time for each backoff slot is given by 20 symbol periods or 320µs.

The total duration of the frame is given by:

Tframe(x) = 8SPHY + SMAC HDR + Saddress + x+ SMAC FTR

Rdata

(4.4)

Where:

• SPHY is the size of the PHY overhead in bytes

• SMAC HDR is the size of the MAC header in bytes

• SADDRESS is the size of the MAC address info field

• SMAC 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

21

4.2 OPNET Channel Capacity

OPNET Overhead

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

Length (bytes)

PHY Overhead 6

Preamble 4SFD 1Frame Length and Reserved Bit 1

MAC Overhead 12

Frame Control 2Sequence Number 1FCS 2Address 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 defines 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

1The address fields have a length of 7 bytes but this is not completely accurate of a real system, seeAppendix E for more information.

22

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

[11].

Figure 4.3: MPDU and PPDU ACK Frames used in OPNET

OPNET Calculated Channel Capacity

The specifications stated in the standards can be misleading if you do not have a good

understanding of the protocol. For example the standard specifies that 65 536 nodes are

supported [11] 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 [11]. 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

23

(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 [11]. 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 [11]:

C = CP

Tpayload

Tpayload + Tack + Toverhead + Twait(4.5)

Where:

Tpayload =Spayload

CP

,

Tack =Sack

CP

,

Toverhead =Soverhead

CP

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/s3.52ms

3.52ms+ 0.352ms+ 0.576ms+ 1.152ms

C ≤ 157.14kb/s (4.6)

This equates to 63% of the maximum stated channel capacity.

2The minimum CCA wait time, minimum radio turnaround time and minimum inter-frame spacing areused to get a wait time of 1.152 ms [11]

24

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 difference 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 effectively counts

the MAC overhead twice, further limiting the channel capacity. For more information about

this problem see Appendix E.

25

4.3 Transmission Power

The Zigbee modules have a default receiver sensitivity of -85dBm. This defines 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 defined as:

PL = 20 • log4πd

λ(dB) (4.7)

Where:

• d is the distance between transmitter and receiver

• λ is the wavelength of the signal and is equal to cfwhere 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 figure is an accurate method to determine the transmit powers for the

WBSN design.

26

Figure 4.5: IEEE 802.15.4 Transmitter Power

Chapter 5

Multi-Patient WBSN Hospital

Room

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 [8] as seen in Table 5.1.

Physiological Parameter Inter-Arrival Sample DataSignal 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

27

28

The proposed topology for the design is seen in Figure 5.1 and includes the following

node types:

• 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

29

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

CCU.

Transmitter Powers

The first 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 TransmitType 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 Specific 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 differ as the calculations in Chapter 4 only

take into account path loss and not other real world sources of signal degradation such as

obstructions, reflections, 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

30

from sensors of other PCUs. This could possibly lead to devices sensing the medium as idle

when it actually is not.

Data Aggregation

Aggregation of Multiple Samples

The six parameters from Table 5.1 were first modeled in a network that generated one

packet per sample. This was done to investigate the effect of the specific 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 inefficient 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:

31

• Sensor 1: This group includes ECG, body temperature and blood pH

• Sensor 2: This group includes blood flow, blood pressure and respiratory rate.

The choice for this segregation was made to spread the average inter-arrival time of different

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 traffic 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 traffic 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 traffic 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

each device.

Aggregation Design

With the data aggregation now defined the inter-arrival times and packet sizes can be

defined. Originally a packet size of 200 bits was modeled to agree with [16]. 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 [16] 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 first sample to arrive that has to

32

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 figure.

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

Parameter Value

ACKs Enabled

ACK Retry Limit 5

macMinBE 3

macMaxCSMABackoffs 4

Topology Tree

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 defined here as 2s [4]. This result differs from results

[4] 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 defined in Chapter 4

and the loss of data could be caused from a number of reason including:

1The simulations were run for 5 different seed values for a duration of 600s. The average was then takento get the results presented

33

Figure 5.2: End-to-End Application Data Delay

Figure 5.3: Application Data Throughput

34

• 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 Backoffs Exceeded: There is a finite 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

channel.

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

35

channel. When there is a problem with the communication channel a device can become

an orphan if it loses communication with its coordinator [45], or disassociates. When this

occurs the device stops transmitting data and broadcasts orphan notifications to try and

rejoin the PAN. These orphan notifications 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 PER = 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 five 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 Backoff Exponent used in IEEE 802.15.4. It’s maximum value is defined as 5 which

limits the number of backoff slots to 31 (more details of this are given in Chapter 6). This

36

is much lower than that used in IEEE 802.11 which has 1023 maximum backoff slots [31].

This will degrade performance quicker as more nodes are added because this small backoff

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 Backoff 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 efficiency 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 defined as the total application data received as a percentage of total

application data generated and the goodput is defined 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 different throughput performance for individual

nodes [34]. Therefore in our system, with nodes generating data at different data rates,

network efficiency will be hard to achieve.

Chapter 6

Improvements for Critical Patient

Data

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

sensors.

6.1 Network Backbone

The topology used so far is based on [39] 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 [6] or possibly by a wireless standard that can handle the larger

37

38

load as in [39]. 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 final 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 final link to the DB doubles it again

to 216 packets/sec. This is an approximation and does not include retransmission, which

would affect the results significantly in such a congested network. The network was re-

simulated with the final hop replaced by a theoretical WLAN link to produce the following

results. The end-to-end delay was decreased by 58%, although the final 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 final

WLAN link is not included in the simulation.

6.2 CSMA/CA and MAC Parameter Modifications

As discussed in Chapter 2 and as seen in Figure A.3 there are multiple parameters that affect

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 different

CSMA/CA parameters will be applied to the data of different patients. It is predicted that

by treating critical patient data differently 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 Backoffs: This is the maximum number of backoffs that the

CSMA/CA algorithm will perform while trying to access the medium before declaring

a channel access failure [35].

• Minimum Backoff Exponent: This is the minimum value of the backoff exponent

39

in the CSMA/CA algorithm which is used to randomly find the number of backoff

periods [35].

• 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 [35]. 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 backoffs and minimum

backoff exponent both affect TBO while the ACK mechanism affects TTA 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 TTA, that otherwise could be used for data transfer.

By disabling ACKs both TTA and TACK can be excluded from Equation 4.2. TACK is the

time it takes to transmit the ACK packet and TTA is the turnaround time which is used to

40

Figure 6.1: ACK Timing Diagram

give the device time to change from receive state to transmit state. These parameters have

the values:

TTA = 0.192ms (6.1)

TACK =SACK

C=

88

250000= 0.352ms (6.2)

TTA + 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 find an optimal

value and Figure 6.2 was produced. This shows that almost 80% of failed data attempts are

Figure 6.2: Effect of ACK Retransmission Limit (aMaxFrameRetries)

41

sucessful on the first retransmission and 94% are sucessful after the second retransmission.

This success rate does not reach 100% until seven retransmissions. The effect of increasing

the ACK retransmission limit was found to have no effect on delay and minimum effect on

management data transmission with only 455 bits/sec extra from two to seven retranmsis-

sions.

From the results presented in this section the final 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 sufficiently to ensure complete

critical data delivery, as increasing this limit has acceptably low degradation effects on net-

work performance. The reduction in control data sent could also have a positive effect on

power consumption and battery life, presently there is no function to measure this.

6.2.2 Minimum Backoff Exponent

The number of backoff slots for each delay period is randomly chosen from the range

[0,2BE − 1]. The Backoff Exponent (BE) is initially set to macMinBE. So by reducing

macMinBE (the lower bound of the random interval) the average backoff period can be

reduced. The standard defines aMaxBE to 5 and macMinBE has a default value of 3, but is

user defined 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 first 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 [4], 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 backoff slots, given by BOslots in the equation. The reduction in the delay is

specifically 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 backoff values decreases as well [34]. This will shorten the average waiting

time when the CCA senses the medium busy or when a packet collision occurs. With this

42

Figure 6.3: macMinBE Effect on Delay

higher probability of selecting a shorter backoff time, more CCAs will be attempted per

time interval which increases the chance of a successful transmission [34]. 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 different seed values and also for longer

simulation runs. This effect is though to be due to synchronisation among transmitters with

constant traffic generation parameters coupled with the limited randomness in the backoff

period [4]. This was verified 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 first

iteration of the CSMA/CA protocol. For this scenario the channel access timing is defined

by the minimum inter-frame spacing (aMinLIFSPeriod) [38]. This means that the critical

data does not perform random backoffs before attempting a CCA. This has a dramatic effect

43

Figure 6.4: macMinBE Effect 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

more persistence.

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 findings of [43] which found

that a smaller macMinBE results in lower throughput when there are sufficient 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 backoff and try again with an incremented macMinBE. In our network, because

of the large amount of collisions, the maximum backoff exponent is quickly reached. Con-

sequently most of the transmission will use the maximum backoff exponent and the effect

of decreasing macMinBE will be limited [31].

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

44

Figure 6.5: macMinBE Effect 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 Backoffs

Every time a backoff is performed and the CSMA/CA protocol senses the channel as busy

the number of backoffs 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

macMaxCSMABackoffs parameter and is user defined in the range [0,5] with a default value

of 4. This effectively limits the number of CCAs that can be performed before the data

is dropped. This section deals with the results of varying macMaxCSMABackoffs 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 macMaxCSMABackoffs 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 first attempt and does not require multiple attempts to access the

medium. This is not the case for our design that is operating near capacity. [4] found that

by decreasing the backoff value and thus increasing the transmitters persistence, achieves a

higher goodput. To ensure that the unexpected results are not due to our specific multi-hop

45

topology the simulation from [4] was repeated and it was found the there was still no effect of

varying macMaxCSMABackoffs. From this it can be concluded that the Maximum Number

of Backoffs attribute in OPNET is not functioning correctly, this conclusion was confirmed

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 effect 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 effect 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 Specific 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 final 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

46

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-off 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 final 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.

Chapter 7

Interference Analysis

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 effects of

IEEE 802.11b on IEEE 802.15.4 that might exist in a hospital environment. More specifi-

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 sufficient

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 first of them being the creation

of interference sources at the node level to model WLAN transmissions, and the other being

the modification of existing WLAN modules to allow compatibility with Zigbee.

47

48

7.1.1 Modification of Existing Nodes

The existing WLAN nodes were edited to allow compatibility with Zigbee so that the

interference effects 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 defines the

packet size, inter-arrival time, packet type and other data generating features. More

than one of these sources can be used to generate different components of an applica-

tion (e.g. two objects of different sizes for a web page download).

• Radio Transmitter: This is where the radio pipeline stages are defined. For a

transmitter this means specification 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 defined.

• 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 specifications 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.

49

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

nodes.

• 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 different WLAN

standards (with different 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 specified.

• Channel Match: This is the stage were the interference nodes parameters will differ

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

as noise.

Table 7.1 shows the specifications 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 Specifications

50

7.1.3 Limitations of Designed Nodes

The created WLAN interference nodes are limited to modeling the PHY layer only. As

mentioned this will model things like frequency, modulation type, data rate, packet lengths

etc, but with no MAC layer functions. This limits the investigation in the following ways:

• The lack of a MAC protocol means a absence of IFS. This will not allow us to investi-

gate weather there is transmission of IEEE 802.15.4 in the IFS between transmissions

of IEEE 802.11b frames. This theoretically could allow transmissions of small packets

in highly congested networks.

• As there is no channel access protocol IEEE 802.15.4 packets will not affect WLAN

transmission. This is not a major issue as we are not looking at the effect on WLAN,

although collisions would require retransmissions which would increase the load on

the medium possibly causing a greater interference effect on IEEE 802.15.4.

7.2 Interference Results

To verify the accuracy of the WLAN interference nodes and to investigate the basic effects

of interference the setup seen in Figure 7.1 was used to investigate interference effects in a

number of different scenarios. The distances, DZ and DWLAN , are varied accordingly and

Figure 7.1: Setup for Modeling Interference Effects

represent the distance between Zigbee transmitter, and WLAN transmitter, with the Zigbee

receiver respectively. The different scenarios below varied the type of WLAN application

traffic, the distance between the WLAN and Zigbee devices, the size of Zigbee packets and

also the Zigbee transmission channel. The Zigbee data transmission characteristics are kept

51

constant throughout the simulations unless otherwise mentioned. The data transmission

models the sensor 1 data from Chapter 5 and 6 and has ACKs disabled. A note must be made

about the effect of the interference on the Zigbee PAN formation. If sufficient interference

is present before the PAN is formed it can become impossible for the PAN to form and

data transfer cannot take place. If the interference is configured to start after the PAN has

formed then data transfer can still be possible with this same amount of interference. This

occurs because data transfer can complete with a one way transfer of data, PAN formation

on the other hand requires a multi-step handshake that has more chance of experiencing

packet loss. For this reason the interference sources start emitting interference after the

Zigbee network has formed. The practical implications of this is that in high interference

locations the Zigbee network will not form at all thus raising the interference issue during

network implementation. Although WLAN usually produces burstly traffic and thus is more

likely to have periods of low and high use, allowing PAN formation.

7.2.1 WLAN Applications

This section investigates the interference effect of different types of WLAN data. Different

types of WLAN applications have variations in packet inter-arrival time and also data and

packet distribution types. The WLAN maximum packet size was kept constant for all

applications. The maximum payload was 12000 bits with additional overhead of 224 bits

per packet, making a total maximum packet size of 12224 bits, to agree with the scenario in

[4]. Table 7.2 shows the WLAN parameters for each data application which are also based

on [4] except for the video application which is based on MJPEG (medium compression)

with 20 frames per sec and a frame size of 46 kb/s. Each WLAN application was broadcast

over the Zigbee data transfer to produce the results in Table 7.3. DZ and DWLAN were

both set to a constant value of 5m. As can be seen the email and HTTP applications have

very little effect on the Zigbee system. The email only has a very small effect on the MAC

delay (0.14ms) and causes no collisions. HTTP does cause collisions at the Zigbee receiver

which accounts for a small percentage of data loss. The FTP and video applications have

a great effect on the performance of the Zigbee devices. They are only allowing 7% and

5% respectively of total application data to be delivered due to collisions. There is also a

dramatic increase in MAC delay. Overall as the amount of interference in incresed we are

52

WLAN Inter-arrival Packet File Size PacketApplication Time (s) Generation (Bytes) Distribution

Distribution

Email

Send Group 120 Exponential 1024 ConstantReceive Group 60 Exponential 1024 Constant

HTTP

Object 1 5 Exponential 10000 ConstantObject 2 5 Exponential 200 000 to 600 000 Uniform

FTP 120 Constant 100 M Constant

Video 0.03 Constant 46000 Constant

Table 7.2: WLAN Applications

WLAN Application BER End- EndApplication Data Loss (%) Delay (ms)

No Interference 0 0 0.95

Email 0 0 1.42

HTTP 0.5 0.98E-05 4.82

FTP 93.0 241.04E-05 12.90

Video 95.0 245.94E-05 15.22

Table 7.3: WLAN Applications Results

53

seeing an increase in MAC delay. The increase in MAC delay is caused from the Zigbee

tranmsimmer performing a CCA and determining a busy medium due to the interference.

It must be noted that all data generated is tranmsitted and no packets are dropped due

to channel access problems. All lost data is due to collisions after the medium has been

accessed. This is due to the Maximum Number of Backoffs error identified in Chapter 6

and is explanied in Appendix E.

7.2.2 Distance

This section investigates the effect of varying the distance between WLAN and Zigbee

devices using the different application data sources. DWLAN was varied from xero to ten

meters whileDZ was set to tem meters to produce Figure 7.2. Again throughput is defined as

Figure 7.2: Effect of WLAN Distance on Interference

the application data delivered to the source as a percentage of the total generated application

data. As can be seen, for FTP and video, the degradation in network performance occurs

at a distance of around 8m from the Zigbee device and performance continues to decline

until it is 4m, where and the Zigbee throughput is zero. The email application was not

included in the figure as it did not impact the throughput even at small distances. Also the

HTTP has little effect on the throughput, it did experience a decrease in throughput at a

similar distance as FTP and video but as can be seen this decrease is small and throughput

54

does not drop below 98%. These results agree with that from [14]. It is also important

to consider the effect of varying the distance between Zigbee transmitter and receiver and

Figure 7.3 shows the results of this when DZ is varied between zero and ten meters and

DWLAN is set to five meters. These results show a similar shaped curve as when varying

Figure 7.3: Effect of Zigbee Separation with Interference

the WLAN distance. There is no data loss when the Zigbee devices are less than 3m apart.

With an increase of only 2m the throughput drops to zero. There is a stepping variation

as the throughput drops with distance. This effect was much larger for shorter simulation

runs and was reduced as the simulation length was increased.

7.2.3 Frequency Band Overlap

This section investigated the interference as the Zigbee channel is varied across the band of

a transmitting WLAN station. WLAN channel 11 was used and the Zigbee channels were

varied from 20 to 26. This gives a full range of possible overlap. The results showed no

change between various Zigbee channels inside the WLAN channel. This shows that the

created interference models have a constant power spectral density (PSD) profile throughout

the 22 MHz spectrum. This is not what happens in reality, where the maximum intensity is

at the center frequency and there are side bands present outside the frequency range. After

further investigation it was found that this is not just a limit of the created interference

55

nodes but exists in all OPNET models (including Zigbee). To be able to fully understand

the coexistence issues between these two standards a model must be developed to take into

account an imperfect radio channel.

7.2.4 IEEE 802.15.4 Packet Size

This section explores the effect of changing the IEEE 802.15.4 packet size in regards to

interference. Figure 7.4 shows the change in application data throughput as the packet size

changes. In these simulations the application data rate is kept constant while changing the

packet size. When the packet size is small there is a greater overall data rate due to the

increase in overhead. Initially, looking from right to left, the throughput increases as the

Figure 7.4: Packet Size Effect on Throughput

packet size decreases. This happens until a critical point, where the throughput quickly

decreases. As the data rate of Zigbee is increased the critical point occurs at larger packet

sizes. The 12 kb/s scenario only just peaks at a packet size of 880 bits while the 18 kb/s

application has a peak greater that 880 bits, which is not supported by Zigbee and is not

shown. The reason for the increases in performance for smaller packet size is that a smaller

packet has less chance of a bit error than a large packet. This is seen in Figure 7.5 which

shows a comparison of BER and bit errors per packer (BE/P). As can be seen the BE/P

decreases as packet size decreases as explained above. The BER on the other hand increases,

56

Figure 7.5: Packet Size Effect on BER and Bit Errors Per Packet

due to the overall increased data rate. It has been concluded that the changing BER and

BE/P has a positive effect up until a critical point where the BER increase becomes to great

and the system performance declines. The final decline would also be seen when interference

is not present due to the data rate increasing too high but it must be noted that the decline

happens at a larger packet size when interference is present.

7.3 Interference Effects on Multi-Patient WBSN

Now that the interference model has been created and it’s results verified it can be modeled

in the WBSN presented in Chapter 6. To do this a trajectory was created to model a doctor

walking around the hospital room. The trajectories created were random in nature but

were saved and reused for comparability. This was done to model the effects of a personal

digital assistant (PDA) or laptop that the doctor might be carrying. The application data

throughput for the HTTP application is seen in Figure 7.6. The simulations were limited to

24 interference nodes as this is in excess of what would be present in reality and still allows

us to investigate the effect of increased interference nodes. The effect on the interference

is much more dramatic for the non-critical data when looking at the overall application

data throughput. The critical application data only drops to 99.6% when there is 24 HTTP

57

Figure 7.6: Throughput with HTTP Interference

interference nodes whereas the non-critical data only has a throughput of 13.9%. The

interference nodes are causing collisions for both types of data although the restrnamissions

are still allowing successful data delivery of critical data. This has an effect on the end-to-

end delay, seen in Figure 7.7. The increasing retransmissions are leading to an increase in

delay for the critical data as the number of interference nodes increases. The non-critical

data only has an increase in 2.7ms which is due to an increase in MAC delay. It must be

noted that while the critical data delay does increase it does not reach an unacceptable

level. The interference has a greater effect on the non-critical data throughput. The results

for the email application have the same curve shape as for HTTP although it’s overall effect

on the network is less with non-critical data throughput dropping to 55.6% and delay of

critical data rising to 87.9ms for 24 email interference nodes. The critical data throughput

and non-critical data remain unchanged as for the HTTP application. When the FTP and

video application were introduced the network fails to function at all. The interference effect

of these nodes anywhere in the room is enough to stop all data transfer. The introduction

of these interference nodes degrades the channel to an extent where the majority of data is

dropped due to PAN formation errors. Because of this the critical and non-critical sensors

only transmit on average 23 and 2 b/s respectively for the FTP application and all of this

data experiences collisions. When the video application is present the WBSN only gets half

58

Figure 7.7: End-To-End with HTTP Interference

that amount of data onto the medium and it too experience 100% collisions.

As can be seen WLAN applications that mt be present in a hospital environment have the

ability to have a degrading effect on an IEEE 802.15.4 WBSN. The WBSN design has been

proved to provides higher QoS for critical data in low interference environments. However

for high interference environments the WBSN design completely fails. It is therefore advised

that IEEE 802.15.4 and IEEE 802.11b be operated at different non-overlapping channels

although more research is needed to investigate non-perfect PSD of WLAN and Zigbee

devices. Overall the WBSN designed in this report can handle a low level of interference

but not for a prolonged period of time as the non-critical data is still affected.

Chapter 8

Modeling MICS and WMTS

Services

Using Zigbee and WLAN for medical data collection is not an ideal solution as they do not

comply with the medical standards due to their size, power consumption and interference

from other sources [46]. It is for this reason the Medical Implant Communication Service

(MICS) and Wireless Medical Telemetry Service (WMTS) were defined. The Zigbee mod-

ules have been edited to allow IEEE 802.15.4 to operate using these two services. [16] stated

that this was not possible as the source code of the network layer is withheld, this is incor-

rect as the PHY layer defines the frequency range and the MAC defines channel indexing

processes. The network layer does decide what specific channel to transmit on out of the

available channels defined by the lower layers. A brief introduction to the two services is

given below.

8.1 Medical Implant Communication Service (MICS)

MICS is an ultra low power, unlicensed radio service that uses miniaturised electronics

that can operate as an implanted device or externally. Examples of applications include

cardiac pacemakers, defibrillators and hearing aids [46]. In addition to interference from

other sources being less of an issue, the frequency band of operation has propagation char-

acteristics conductive to the transmission of radio signals within the human body [9]. The

59

60

characteristics of MICS are seen in Table 8.1. This frequency range and bandwidth allows

Frequency Bandwidth Transmit Range(MHz) (MHz) Power (dBm) (m)

MICS 402-405 0.3 -16 10

Table 8.1: MICS Technical Specifications

for 10 non overlapping channels.

8.2 Wireless Medical Telemetry Service (WMTS)

WMTS is another service for data collection in medical applications but is used for non-

implantable devices and has a longer distance range [9]. Table 8.2 presents some technical

specifications regarding the channel. The channel spacing within these bands is 25kHz

Frequency Bandwidth Transmit Range(MHz) (kHz) Power (dBm) (m)

Band 1 608-614 25 or 50Band 2 1395-1400 25 > 1.8 and ≤ 10 100Band 3 1427-1432 25

Table 8.2: WMTS Technical Specifications

but can support 50 kHz channels which are implemented in the larger band with 6 MHz

bandwidth. In [39] MICS was used for the short range communication and WMTS was then

used for the longer range communication, for this reason both services were implemented

in OPNET.

8.3 OPNET Implementation

Parameters Used

The MICS and WMTS implementations are based on the prototype developed in [39] and

uses the values from Tables 8.2, 8.1 and 8.3. It must be noted that both MICS and WMTS

can transmit in excess of the data rates presented in Table 8.3 but the OPNET implemen-

tation has been designed to model the specific transceiver type used in [39]. This is also

61

MICS WMTS

Data rate (kb/s) 16 76

Modulation BPSK FSK

Transceiver AMIS 52100 Chipcon CC1010

Table 8.3: MICS and WMTS Implementation Specifications

true for the modulation used. The AMIS 52100 actually uses ASK modulation but this is

currently not available in OPNET so BPSK was used as a substitute.

Procedure

To implement IEEE 802.15.4 using the MICS and WMTS services the existing Zigbee

modules in OPNET were edited. This included changes to both IEEE 802.15.4 header

file and MAC process model code. Both services were implemented separately, so that

all three transmission bands could be implemented for WMTS, and they were also both

implemented on the same node along with Zigbee (so that either MICS, WMTS or Zigbee

can be implemented on the one device by enabling that channel). All the edited code is

presented in Appendix D while Table 8.4 shows the breakdown of which files implement

which services.

MICS.h WMTS.h Dual.h (WMTS,MICS and Zigbee)

WMTS608 - 614 MHz No Yes Yes1395 - 1400 MHz No Yes No1427 -1432 MHz No Yes No

MICS402 - 405 MHz Yes No Yes

Zigbee2.4 GHz No No Yes

Table 8.4: WMTS, MICS and Zigbee Implementations in OPNET

Header File

The IEEE 802.15.4 header file was changed to allow transmission over the desired frequency

bands, with the relevant data rate and bandwidths. Since different WMTS channels were

62

implemented with different bandwidths extra bandwidth definitions had to be declared.

These steps are summarised as:

• Edit data rate definitions

• Edit frequency definitions

• Edit bandwidth definition

• Create extra bandwidth definitions

• Rename definitions

Process Model

The process model was then changed to support our new services, these changes are

• Rename constants changed in header file

• Edit channel indexing code to support desired channel spacing and channel numbers

• Change modulation specification

• Change symbol rate calculation

• Insert code to print channel centre frequency

The channel indexing code specifies the channel separation within a frequency band. Each

channel is scanned for beacons and then this information is passed to the network layer

which makes a decision on which channel to use. Since the network layer source code is

withheld it is not possible to specify which channel will be used. The default in OPNET

seems to be to use the last available channel in each frequency band. The last step in the

list above is optional and is used to easily verify correct frequency specifications.

Chapter 9

Conclusion and Future Work

9.1 Conclusion

This report has successfully designed and simulated a multi-hop, multi-patient WBSN that

can support a maximum of six patients. Due to topological and power requirements the

design has an excessive BER largely due to the hidden terminal problem. For this reason

the report finds the non-beaconed version of IEEE 802.15.4 unsuitable for a WBSN in a

medical environment. It is recommended to use a RTS/CTS handshake or possibly the

beaconed version of the protocol to reduce these collisions. It was found that using a

different standard with a greater data rate as the network backbone freed up resources

significantly. The effects of reducing the Minimum Backoff Exponent were found to produce

an improvement in the throughput and delay of critical data. This improvement was found

to be limited due to the high BER that caused the backoff exponent to quickly increase

to it’s maximum value. When collision avoidance was disabled there was an increase in

collisions that degraded network performance. It was found that enabling ACKs only on

critical data reduced to total overhead on the system while maintaining reliable critical

data transfer. This project was successful in the design and construction of an interference

model that accurately models various WLAN application data. This was used to model

WLAN interference on the WBSN design. It was found that the design has sufficient QoS

considerations to handle low interference levels. However this report recommends using

different, non overlapping channels as some WLAN applications were found to completely

63

64

prevent IEEE 802.15.4 transmissions. It was also found that in an interference effected

environment reducing packet length increases throughput, although this effect was limited

as the data rate increased. This project edited the existing IEEE 802.15.4 source code to

successfully implement IEEE 802.15.4 using the WMTS and MICS services. The changes

included modification of data rate, frequency, bandwidth, modulation, symbol rate and

channel indexing and separation code.

9.2 Future Work

This report has continued on from the work presented in [16] and has provided the contri-

bution outlined above. However there is still a lot of research and design to be done before

a final simulation model is complete. What follows is a discussion of possible future work

in the field.

To reduce the BER it might be an advantage to implement a RTS/CTS handshake. This

will completely eliminate collisions caused from the hidden terminal problem. This could

also be achieved using the GST mechanism in the beaconed enabled version of the protocol.

Re-simulation of the results presented here using one of these two methods is predicted to

reduce collisions.

The interference results presented here offer a solid base for understanding interference ef-

fects although some improvements are necessary. A model is needed that accurately models

a real (imperfect) PSD. This is one that has the highest power at the centre frequency and

also with power leakage outside of the defined frequency range. This would show the real

effects of adjacent channel operation, which in this report was found to have no effect.

Battery consumption is a critical factor to a WBSN. It is for that reason that a model for

power consumption and battery life would be useful. This will give a understanding of how

different network parameters and protocols will affect a hardware prototype.

The implementation of the MICS and WMTS services is a step forward in the simulation of

a WBSN that fully adheres to the medical standards. The next step is to be able to connect

a MICS device to a WMTS device. This would enable the short distance MICS (embedded

data collection) to be connected to a WMTS backbone (data transfer and storage). To do

this a hybrid device would need to be created that can receive MICS and transmit using

WMTS, and vice versa depending on the specific application.

Appendix A

Beacon-Enabled Mode and

CSMA/CA Algorithms

This project relates to the non-beaconed mode of IEEE 802.15.4, which uses the unslotted

version of CSMA/CA. This is what the current version of OPNET supports. In reality a

WBSN is more suited to the beacon-enabled version and for this reason a brief summary

the the beacon-enabled mode is given below. Future versions of OPNET will support this

version and [12] has designed and implemented their own model using OPNET.

A.1 Beacon-Enabled Mode

In beacon-enabled mode the coordinator node broadcasts beacons periodically to synchro-

nise all associated devices [14]. Below is a discussion on the beacon-enabled mode of IEEE

802.15.4, including the superframe structure, Guaranteed Time Slot (GTS), data transfer

and slotted CSMA/CA.

Superframe Structure

The coordinator node of each star network using beaconed-mode uses the frame in Figure

A.1 to control channel access and data transmission [1]. The following points are true about

the superframe structure in Figure A.1:

• Every superframe is the same length [1].

65

66

Figure A.1: Superframe Structure of IEEE 802.15.4

• The start of the superframe is a beacon packet [1].

• The beacon packet includes the superframe specification, which identifies the lengths

of each component of the superframe [1].

• The superframe is divided into an active and an inactive period. In the optional

inactive period the devices can ’sleep’ to conserve power [22]. They must ’wake’

before the beacon that starts the next active period.

• The active period is subdivided into 16 time slots, the first of which is occupied by

the beacon [1].

• The remainder of the active period is partitioned into a Contention Access Period

(CAP) and Guaranteed Time Slots (GTS) [1].

• The lengths of the active and inactive periods, individual time slots, CAP and GTS

are all configurable [1].

• The coordinator node is active in the entire active period [1].

• The devices are active in the GTSs allocated to them and are inactive or ’sleeping’

for the GTSs not allocated to them [1].

It can be seen that the devices do little work when compared to the coordinator node.

This shows that the beacon-enabled version is optimised for applications where the sensor

devices are energy-constrained [1].

67

Data Transfer Procedure

GTS Management

During the CAP devices send request packets to the coordinator node if they have data to

send or receive. The coordinator node then responds by allocating a GTS to that device.

The device’s request packet identifies whether it’s a read or receive request and the number

of contiguous GTS needed. The coordinator node replies with an immediate ACK packet

and later when enough resources are available to be allocated it sends a GTS descriptor in

the next beacon frame [1]. The device will continue to use this GTS until it is specifically

de-allocated by either the coordinator node or by itself. [1].

Data Transfer

When a device wants to transmit to it’s coordinator node, assuming it has already been

allocated a GTS, it ’wakes’ just before its GTS starts. It immediately sends the packet

without running any CSMA/CA. A similar procedure happens when the coordinator node

needs to send data to the device. This scenario of the handshake between coordinator and

device when the node receives a packet is outlined below:

• The coordinator adds the devices address to the pending address field of the beacon

[1].

• The devices sees it address in the beacon and sends a data request to the coordinator

node during the CAP [1].

• The coordinator acknowledges the device’s data request with an ACK [1].

• The device receives the ACK and prepares to receive data

• The coordinator node sends the data

• The device receives the data, sends an ACK and then ’sleeps’ until the next beacon

[1].

68

Slotted CSMA/CA

When nodes need to send control packets in the CAP they use slotted CSMA/CA. This is

a contention based protocol where a possible opportunity to transmit can be acted upon by

multiple devices [1]. The behaviour of slotted CSMA/CA is determined by three parameters.

These are, Backoff Exponent (BE), Initial value of the Congestion Window (CW) and

the Maximum number of Backoffs (NB). The actual process of slotted CSMA/CA and its

relation to the previous parameter are listed below and can be seen in Figure A.2 adapted

from [11].

• The variables NB, BE and CW are initiated with NB is set to zero, BE is set to

macMinBE and CW is set to 2 [11]. macMinBE is a protocol parameter in the range

[0, 3] which is user defined with a default of 3. BE can have a value between macMinBE

and aMaxBE (5). NB is user defined in the range [0, 5] with a default of 4.

• The number of delay backoff periods is found randomly from the interval [0, 2BE − 1].

• A CCA is performed at defined backoff period boundaries after the delay to sense if

the channel is busy [11].

• If the channel is sensed as idle CW is decremented. If CW is zero a packed is trans-

mitted, if it is not zero another CCA is performed at the next backoff boundary.

• If the channel is sensed to be busy, NB and BE are both incremented with CW set

back to it’s initial value [11].

• 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 [11].

The effect of CWmeans that devices have to sense an idle medium twice before transmission,

this parameter is not used in the unslotted version.

69

A.2 Slotted CSMA/CA

Figure A.2: Slotted CSMA/CA Algorithm

70

A.3 Unslotted CSMA/CA

Figure A.3: Unslotted CSMA/CA Algorithm

Appendix B

Simulation Results

B.1 Original Design Results

Parameter Value Parameter Value

Sensor MAC Delay 67.4 ms PCU BER 0.00181

PCU MAC Delay 37.9 ms CCU BER 0.00097

CCU MAC Delay 74.1 ms DB BER 0.00186

Sensor 1 Queuing Delay 40.6 ms PAN Formation Data Lost 20.7 kb/s

PCU Queuing Delay 24.4 ms ACK Threshold Data Lost 1.2 kb/s

CCU Queuing Delay 74.1 ms Application Data Throughput 53.3%

End-To-End Delay 168.4 ms Goodput 33.1%

Table B.1: Six Patient WBSN Design Simulation Results

71

72

B.2 Improved Design Results

WLAN/Wired Backbone Results

Measurement WLAN/Wired ImprovementBackbone

End-to end Delay (ms) 71.2 57.7%

PCU MAC Delay (ms) 20.6 45.6%

PCU Queuing Delay (ms) 13.0 46.7%

PAN Formation Data Lost (kb/s) 10.9 47.1%

Throughput 75.0% 21.7%

Goodput 65.0% 33.9%

ACK Threshold 0.6 50%Data Lost (kb/s)

Table B.2: WLAN Backbone Simulation Results

ACK Mechanism Results

Measurement ACKs Only Critical ACKsEnabled Data ACKs Enabled Disabled

Critical Patient Data

End-to end Delay (ms) 69.5 52.5 24.3Throughput (%) 99.2 100.0 72.1

Non-Critical Patient Data

End-to end Delay (ms) 60.5 24.5 23.6Throughput (%) 99.0 73.9 77.7

Table B.3: ACK Mechanism Simulation Results

73

Combined Results

Parameter Critical Data Non-Critical DataValue Improvement Value Improvement

Sensor MAC 35.1 48.1% 6.1 91.0%Delay (ms)

PCU MAC 11.6 69.4% 5.8 84.7%Delay (ms)

Sensor 1 Queuing 5.4 86.7% 0 100%Delay (ms)

PCU Queuing 5.6 77.0% 0.6 97.5%Delay (ms)

End-To-End 59.9 64.4% 21.4 87.3%Delay (ms)

PCU BER 0.00104 42.5% 0.00082 54.7%

Application Data 100 36.7% 61.3 8%Throughput (%)

Table B.4: Improved WBSN Critical and Non-Critical Data Simulation Results

Global Final ImprovementParameter Design

CCU BER 0.00022 77.3%

Goodput (%) 69.8 36.7%

PAN Formation 0 100%Data Lost (kb/s)

ACK Threshold 0 100%Data Lost (kb/s)

Table B.5: Improved WBSN Global Results

Appendix C

Wireless Transmission of Data in

OPNET

C.1 Radio Transceiver Pipeline

To model wireless transmission of data OPNET uses the Radio Transceiver Pipeline, which

is a set of sequential stages that determine how to process received radio data. A separate

pipeline is needed for each receiver in a wireless network. This is because radio waves

access the medium with broadcasts and every transmission can have an effect at multiple

receivers. The Radio Transceiver Pipeline has 14 stages, seen in Figure C.2. It is important

to have a good understanding of this pipeline to be ale to understand how Zigbee will

handle interference from outside sources. Figure C.2 is the pipeline process as a whole but

it must be noted that stages 0-5 are implemented at the radio transmitter and stages 6-13

implemented at the receiver. Stages 9, 10 , 11 and 12 can be executed multiple times for

each receiver, this might need to be done because of the possibility of interactions with

multiple concurrent transmissions from other sources [41]. Basically the pipeline is used to

classify arriving packets, as valid, invalid or noise, and process them accordingly.

Stage 0: Receiver Group

This stage determines each transmitter channel’s initial receiver group and is specified by

the rxgroup model attribute in the transmitter node model. The receiver group lists

74

75

the possible receivers for each transmitter. Due to the dynamic nature of simulations the

receiver group stage includes a receiver channel unless it can be determined in advance that

a receiver channel will never be a match for that transmitter. If a receiver is in a transmit-

ter’s receiver group is can be disqualified during a simulation due to frequency/bandwidth

mismatch, physical separation or directional antenna issues.

Stage 1: Transmission Delay

This stage calculates the amount of time taken for the packet to complete transmission and

is specified by the txdel model attribute in the transmitter node model. This result is

the simulation time difference between the beginning of transmission of the first bit and

the end of transmission of the last bit of each packet [41]. This stage is the first stage to

get run for every new transmission and this result is used to create an ’end of transmission’

trigger where the transmitter can transmit the next packet or if no packets are available

the medium becomes idle.

Stage 2: Link Closure

This stage determines if a receiver can be affected by the transmission and is specified by

the closure model attribute in the transmitter node model. This stage is run once for each

receiver in the transmitter’s receiver group and if the transmission is capable of reaching

the receiver it is called a link closure. A link closure is based on physical conditions and

signal levels and does not take into account whether the signal is valid for the receiver.

This means that interference signals can and will cause a link closure. When considering

link closures a propagation model is used that considers things like path-loss and terrain

modeling.

Stage 3: Channel Match

This stage labels the transmission in regards to validity to the receiver and is specified by

the chanmatch model attribute in the transmitter node model. This stage is run once

for each successful link closure and can apply one of three possible labels to each packet:

• Valid: These packets are compatible with the receiver. This decision is based on

frequency, bandwidth, data rate, spreading code and modulation.

76

• Noise: These packets are not compatible with the receiver but can have an impact

on the receiver’s performance (i.e. interference). This decision is based on incompat-

ibilities of the parameters listed in the previous point.

• Ignored: These packets have no effect on a receiver’s performance. The pipeline will

be discontinued.

Stage 4: Tx Antenna Gain

This stage calculates the gain provided by the transmitters antenna and is specified by the

tagain model attribute in the transmitter node model. This stage is run separately for

each channel that is labeled as either ’valid’ or ’noise’ from the previous stage and the result

is commonly used at Stage 7 for the received power calculation.

Stage 5: Propagation Delay

This stage calculates the time needed for the packet to travel from the transmitter to the

receiver and is specified by the propdel model attribute in the transmitter node model.

This is used to create a ’beginning of reception’ trigger for the receiver and also used in

conjunction with the result from Stage 1 to calculate the time that the packet completes

reception [41].

Stage 6: Rx Antenna Gain

This stage calculates the the gain provided by the receivers antenna and is specified by the

ragain model attribute in the receiver node model. This stage is comparable to the Tx

Antenna Gain stage and the result is also used at Stage 7 to calculate received power.

Stage 7: Received Power

This stage calculates the received power of the arriving packets signal and is specified by the

power model attribute in the receiver node model. For ’valid’ packets this is an important

factor for the receiver to be able to decode information in the packet. For ’noise’ packets

the received power is used for SNR calculations. The received power calculations are based

on transmitter power, distance, frequency and antenna gains.

77

Stage 8: Background Noise

This stage represents all noise sources except for concurrent arriving interference noise and

is specified by the bkgnoise model attribute in the receiver node model. The result is a

sum of powers from all other noise sources. These source could be things such as ambient

noise level, constant source of background noise, and constant thermal noise at the receiver.

Since we are concerned with the interference effect on Zigbee the following values relate to

Zigbee. This model, used by Zigbee, defines the background noise and in-band ambient

noise as:

Nbkg = (TRx + Tbkg) ∗B ∗BWrx (C.1)

Nambient = Nlevel ∗BWrx (C.2)

Where:

• TRx is the Receiver Temperature

• Tbkg is the Background Temperature (290 K)

• BWrx is Receiver Bandwidth (2 MHz)

• B is Boltzmann Constant (1.379e−23 J/K)

• Nlevel is the Ambient Noise Level (1e−26 W)

The effective receiver temperature is given by:

TRx = (NF − 1) ∗ Tbkg (C.3)

Where:

• NF is the Noise Figure (1)

For the Zigbee modules the the following results are used by default:

Nbkg = 7.9982e−15W (C.4)

Nambient = 2e−20W (C.5)

Therefore:

Nbkg +Nambient = 7.99822e−15W (C.6)

78

Stage 9: Interference Noise

This stage accounts for the interactions between concurrently arriving transmissions at the

same receiver and is specified by the inoise model attribute in the receiver node model.

This stage will be run when a ’valid’ packet arrives at its destination while a second packet

is already being received or when a ’valid’ packet is being received when a second packet,

’valid’ or ’invalid’ arrives. The level of all noise from interference sources is recorded with

the power of successfully received ’valid’ or ’invalid’ packets subtracted from this. The

power of successfully received ’invalid’ packets is dealt with in the next section.

Stage 10: Signal-To-Noise Ratio

This stage calculates the current SNR for the arriving packet and is specified by the snr

model attribute in the receiver node model. SNR is a network performance measure that

measures the receivers ability to correctly decode the packets content. This stage is run

when a ’valid’ packet arrives at its destination channel, when a second packet arrives while

the ’valid’ packet is being received or when a second packet completes reception while the

’valid’ packet is being received. The SNR calculation is based on received power, background

noise and interference noise:

SNR =Psignal

Pnoise(C.7)

=Psignal

Pbkg noise + Pintf noise

(C.8)

SNR(dB) = 10log10

Psignal

Pbkg noise + Pintf noise

(C.9)

Where:

Psignal is the signal power calculated in Stage 7

Pbkg noise is the background noise calculated in Stage 8

Pintf noise is the interference noise calculated in Stage 9

Stage 11: Bit Error Rate

This stage derives the probability of bit errors using the SNR and modulation type used for

transmission and is specified by the ber model attribute in the receiver node model. This

stage is run when a ’valid’ packet completes reception at it’s destination channel, when a

79

’valid’ packet is already being received and another packet (valid or invalid) arrives or when

a ’valid’ packet is already being received and another packet (valid or invalid) completes

reception. This stage uses the SNR calculation from Stage 10 and the modulation type

to calculate the BER. The modulation used in Zigbee is Quadrature Phase Shift Keying

(QPSK) whose BER curve is seen in Figure C.1.

Figure C.1: QPSK BER Curve [35]

Stage 12: Error Allocation

This stage estimates the number of bit errors in a packet segment based on the bit error

probability from the previous section and is specified by the error model attribute of the

receiver node model. It also records the empirical bit error rate.

80

Stage 13: Error Correction

This stage determines whether the arriving packet can be accepted and forwarded to higher

layers and is specified by the ecc model attribute of the receiver node model. Weather

the packet can be forwarded or not depends on if the packet has experienced collisions, the

result calculated in the error allocation stage, and the effect of error correction. This stage

is run when a ’valid’ packet completes reception. Based on these results of this stage the

packet is either forwarded or destroyed.

81

C.2 Graphical Radio Transceiver Pipeline Stages

Figure C.2: Radio Transceiver Pipeline Stages

82

C.3 Standard Specific Pipeline Stages

Stage Number Stage Name WLAN Model Zigbee Model

Transmitter Stages

0 Receiver Group wlan rxgroup dra rxgroup

1 Transmission Delay wlan txdel dra txdel

2 Link Closure dra closure dra closure

3 Channel Match wlan chanmatch dra chanmatch

4 Tx Antenna Gain none dra tagain

5 Propagation Delay wlan propdel dra propdel

Receiver Stages

6 Rx Antenna Gain none dra ragain

7 Received Power wlan power Zigbee dra power

8 Background Noise dra bkgnoise dra bkgnoise

9 Interference Noise wlan inoise dra inoise

10 Signal-To-Noise Ratio dra snr dra snr

11 Bit Error Rate wlan ber dra ber

12 Error Allocation wlan error dra error

13 Error Correction wlan ecc dra ecc

Table C.1: WLAN and Zigbee Default Pipeline Stages

Appendix D

MICS and WMTS Implementation

Code

D.1 Dual Implementation Code

This code implements WMTS, MICS and Zigbee all on the one device. The desired standard

is specified in the node attributes.

Header File Modifications

This code replace lines 13-24 of the 802.15.4 Header File (802 15 4.h)

/* ZigBee, WMTS and MICS physical layer constants. */

/* WMTS and MICS can have a data rate in excess of 250 kb/s */

/* It is limited here due to chip data rate */

#define WPANC_MICS_BAND_DRATE 16000

#define WPANC_WMTS_BAND_DRATE 76000

#define WPANC_Zigbee_BAND_DRATE 250000

#define WPANC_MICS_BAND_FREQ 402.15

#define WPANC_WMTS_BAND_FREQ 608.0375

#define WPANC_Zigbee_BAND_FREQ 2405

#define WPANC_Zigbee_BANDWIDTH 2

#define WPANC_MICS_BANDWIDTH 0.3

83

84

#define WPANC_WMTS_BANDWIDTH 0.05

#define WPANC_Zigbee_BAND 1

#define WPANC_WMTS_BAND 2

#define WPANC_MICS_BAND 3

Process Model Modifications

This code replaces lines 1135-1183 of the Function Block for the 802.15.4 MAC layer

(802 15 4 mac.pr.m).

/*MICS*/

for (index = 1; index < 11; index++){

channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle,

sizeof (WPAN_Channel_Info));

channel_center_frequency = WPANC_MICS_BAND_FREQ + 0.3*(index-1);

channel_info_ptr->min_frequency =

channel_center_frequency - WPANC_MICS_BANDWIDTH/2.0 ;

if (data_rate == -1)

channel_info_ptr->drate = WPANC_MICS_BAND_DRATE;

else

channel_info_ptr->drate = data_rate;

channel_info_ptr->tx_band = WPANC_WMTS_BAND;

op_prg_list_insert (channel_info_lptr, channel_info_ptr,

OPC_LISTPOS_TAIL);

}

printf("\n The MICS center frequency is:

%5.4f\n", channel_center_frequency);

/*WMTS*/

for (index = 2242; index < 2479; index = index + 2){

channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle,

sizeof (WPAN_Channel_Info));

channel_center_frequency = WPANC_WMTS_BAND_FREQ + 0.05*(index-2242);

channel_info_ptr->min_frequency =

85

channel_center_frequency - WPANC_WMTS_BANDWIDTH/2.0 ;

if (data_rate == -1)

channel_info_ptr->drate = WPANC_WMTS_BAND_DRATE;

else

channel_info_ptr->drate = data_rate;

channel_info_ptr->tx_band = WPANC_WMTS_BAND;

op_prg_list_insert (channel_info_lptr, channel_info_ptr,

OPC_LISTPOS_TAIL);}

printf("\n The WMTS center frequency is:

%5.4f\n", channel_center_frequency);

/*Zigbee*/

for (index = 11; index < 27; index++){

channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle,

sizeof (WPAN_Channel_Info));

channel_center_frequency = WPANC_Zigbee_BAND_FREQ + 5*(index-11);

channel_info_ptr->min_frequency =

channel_center_frequency - WPANC_Zigbee_BANDWIDTH/2.0 ;

if (data_rate == -1)

channel_info_ptr->drate = WPANC_Zigbee_BAND_DRATE;

else

channel_info_ptr->drate = data_rate;

channel_info_ptr->tx_band = WPANC_Zigbee_BAND;

op_prg_list_insert (channel_info_lptr, channel_info_ptr,

OPC_LISTPOS_TAIL);}

printf("\n The Zigbee center frequency is:

%5.4f\n", channel_center_frequency);

This code replaces lines 1218-1227 of the Function Block for the 802.15.4 MAC layer

(802 15 4 mac.pr.m).

/* Also update the module wide memory with appropriate symbol rate. */

if (channel_info_ptr->tx_band == WPANC_WMTS_BAND ||

channel_info_ptr->tx_band == WPANC_MICS_BAND)

86

modmem_ptr->symbol_rate = channel_info_ptr->drate;

else

modmem_ptr->symbol_rate = 0.25* (channel_info_ptr->drate);

drate_sv = channel_info_ptr->drate;

This code replaces lines 1231-1242 of the Function Block for the 802.15.4 MAC layer

(802 15 4 mac.pr.m).

/* Set the modulation scheme appropriately */

if (channel_info_ptr->tx_band == WPANC_Zigbee_BAND){

op_ima_obj_attr_set (tx_objid, "modulation", "qpsk");

op_ima_obj_attr_set (rcvr_objid, "modulation", "qpsk");}

else if(channel_info_ptr->tx_band == WPANC_MICS_BAND){

/* Set modulation to BPSK when using MICS */

op_ima_obj_attr_set (tx_objid, "modulation", "bpsk");

op_ima_obj_attr_set (rcvr_objid, "modulation", "bpsk");}

else {

/* Set modulation to FSK whenusing WMTS*/

op_ima_obj_attr_set (tx_objid, "modulation", "fsk2");

op_ima_obj_attr_set (rcvr_objid, "modulation", "fsk2");}

D.2 WMTS Implementation Code

This code implements all three available bands of WMTS.

WMTS Header File Modifications

This code replace lines 13-24 of the 802.15.4 Header File (802 15 4.h)

/* WMTS physical layer constants. */

/* WMTS can use a bandwidth greater than 250 kb/s. */

/* Data rate given here are specific of chips used */

#define WPANC_WMTS1_BAND_DRATE 76000

#define WPANC_WMTS2_BAND_DRATE 76000

87

#define WPANC_WMTS3_BAND_DRATE 76000

/* 608-614 Mhz, BW = 6 MHz */

#define WPANC_WMTS1_BAND_FREQ 608.0375

/* 1395-1400 MHz, BW = 5 MHz */

#define WPANC_WMTS3_BAND_FREQ 1395.0125

/* 1427-1432 MHz, BW = 5 MHz */

#define WPANC_WMTS2_BAND_FREQ 1427.0125

/*Band 1 BW 50 kHz */

#define WPANC_WMTS1_BANDWIDTH 0.05

/*Band 2 BW 25kHz */

#define WPANC_WMTS3_BANDWIDTH 0.025

/*Band 3 BW 25kHz */

#define WPANC_WMTS2_BANDWIDTH 0.025

#define WPANC_WMTS1_BAND 1

#define WPANC_WMTS2_BAND 2

#define WPANC_WMTS3_BAND 3

WMTS Process Model Modifications

This code replaces lines 1135-1183 of the Function Block for the 802.15.4 MAC layer

(802 15 4 mac.pr.m).

/* For each enabled band allocate the memory associated with its

channel and populate the channels. */

/* WMTS 3 (1395-1400 MHz) */

for (index = 33721; index < 33921; index++){

channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc

(wpan_cmo_handle, sizeof (WPAN_Channel_Info));

channel_center_frequency = WPANC_WMTS3_BAND_FREQ + 0.025*(index-33721);

channel_info_ptr->min_frequency =

channel_center_frequency - WPANC_WMTS3_BANDWIDTH/2.0 ;

if (data_rate == -1)

channel_info_ptr->drate = WPANC_WMTS3_BAND_DRATE;

88

else

channel_info_ptr->drate = data_rate;

channel_info_ptr->tx_band = WPANC_WMTS3_BAND;

op_prg_list_insert (channel_info_lptr, channel_info_ptr,

OPC_LISTPOS_TAIL);}

printf("\n The centre frequency is: %5.4f\n", channel_center_frequency);

/* WMTS 2 (1427-1432 MHz) */

for (index = 35005; index < 35205; index++){

channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle,

sizeof (WPAN_Channel_Info));

channel_center_frequency = WPANC_WMTS2_BAND_FREQ + 0.025*(index-35005);

channel_info_ptr->min_frequency =

channel_center_frequency - WPANC_WMTS2_BANDWIDTH/2.0 ;

if (data_rate == -1)

channel_info_ptr->drate = WPANC_WMTS2_BAND_DRATE;

else

channel_info_ptr->drate = data_rate;

channel_info_ptr->tx_band = WPANC_WMTS2_BAND;

op_prg_list_insert (channel_info_lptr, channel_info_ptr,

OPC_LISTPOS_TAIL);}

printf("\n The centre frequency is: %5.4f\n", channel_center_frequency);

/* WMTS 1 (608-614 MHz) */

for (index = 2242; index < 2479; index = index + 2)

/*Double indexing due to the increased channel BW*/{

channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc

(wpan_cmo_handle, sizeof (WPAN_Channel_Info));

channel_center_frequency = WPANC_WMTS1_BAND_FREQ + 0.025*(index-2242);

channel_info_ptr->min_frequency =

channel_center_frequency - WPANC_WMTS1_BANDWIDTH/2.0 ;

if (data_rate == -1)

channel_info_ptr->drate = WPANC_WMTS1_BAND_DRATE;

89

else

channel_info_ptr->drate = data_rate;

channel_info_ptr->tx_band = WPANC_WMTS1_BAND;

op_prg_list_insert (channel_info_lptr, channel_info_ptr,

OPC_LISTPOS_TAIL);}

printf("\n The centre frequency is: %5.4f\n", channel_center_frequency);

This code replaces lines 1218-1227 of the Function Block for the 802.15.4 MAC layer

(802 15 4 mac.pr.m).

/* Also update the module wide memory with appropriate symbol rate. */

/* For FSK the symbol rate is equal to the data rate */

modmem_ptr->symbol_rate = channel_info_ptr->drate;

drate_sv = channel_info_ptr->drate;

This code replaces lines 1231-1242 of the Function Block for the 802.15.4 MAC layer

(802 15 4 mac.pr.m).

/* Set the modulation scheme to FSK independent of what band is

transmitting */

op_ima_obj_attr_set (tx_objid, "modulation", "fsk2");

op_ima_obj_attr_set (rcvr_objid, "modulation", "fsk2");

D.3 MICS Implementation Code

This code implements the one MICS band.

MICS Header File Modifications

This code replace lines 13-24 of the 802.15.4 Header File (802 15 4.h)

/* WMTS physical layer constants. */

/* MICS data rate can exceed 250 kb/s */

/* It is limited here due to the AMIS 52100 IC */

#define WPANC_MICS1_BAND_DRATE 16000

90

#define WPANC_MICS2_BAND_DRATE 16000

#define WPANC_MICS3_BAND_DRATE 16000

/* MCIS (402-405 MHz) */

#define WPANC_MICS1_BAND_FREQ 402.15

#define WPANC_MICS2_BAND_FREQ 403.95

#define WPANC_MICS3_BAND_FREQ 403.05

/* MCIS BW 300 Hz */

#define WPANC_BANDWIDTH 0.3

#define WPANC_MICS1_BAND 1

#define WPANC_MICS2_BAND 2

#define WPANC_MICS3_BAND 3

MICS Process Model Modifications

This code replaces lines 1135-1183 of the Function Block for the 802.15.4 MAC layer

(802 15 4 mac.pr.m).

/* For each enabled band allocate the memory associated with its

channel and populate the channels. */

/*MICS Band 1 */

for (index = 1; index < 4; index++){

channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc

(wpan_cmo_handle, sizeof (WPAN_Channel_Info));

channel_center_frequency = WPANC_MICS1_BAND_FREQ + 0.3*(index-1);

channel_info_ptr->min_frequency =

channel_center_frequency - WPANC_BANDWIDTH/2.0 ;

if (data_rate == -1)

channel_info_ptr->drate = WPANC_MICS1_BAND_DRATE;

else

channel_info_ptr->drate = data_rate;

channel_info_ptr->tx_band = WPANC_MICS1_BAND;

op_prg_list_insert (channel_info_lptr, channel_info_ptr,

OPC_LISTPOS_TAIL);}

91

printf("\n The centre frequency is: %5.4f\n", channel_center_frequency);

/*MICS Band 2 */

for (index = 4; index < 7; index++){

channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc

(wpan_cmo_handle, sizeof (WPAN_Channel_Info));

channel_center_frequency = WPANC_MICS3_BAND_FREQ + 0.3*(index - 4);

channel_info_ptr->min_frequency =

channel_center_frequency - WPANC_BANDWIDTH/2.0 ;

if (data_rate == -1)

channel_info_ptr->drate = WPANC_MICS3_BAND_DRATE;

else

channel_info_ptr->drate = data_rate;

channel_info_ptr->tx_band = WPANC_MICS3_BAND;

op_prg_list_insert (channel_info_lptr, channel_info_ptr,

OPC_LISTPOS_TAIL);}

printf("\n The centre frequency is: %5.4f\n", channel_center_frequency);

/*MICS Band 3*/

for (index = 7; index < 11; index++){

channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc

(wpan_cmo_handle, sizeof (WPAN_Channel_Info));

channel_center_frequency = WPANC_MICS2_BAND_FREQ + 0.3*(index-7);

channel_info_ptr->min_frequency =

channel_center_frequency - WPANC_BANDWIDTH/2.0 ;

if (data_rate == -1)

channel_info_ptr->drate = WPANC_MICS2_BAND_DRATE;

else

channel_info_ptr->drate = data_rate;

channel_info_ptr->tx_band = WPANC_MICS2_BAND;

op_prg_list_insert (channel_info_lptr, channel_info_ptr,

OPC_LISTPOS_TAIL);}

printf("\n The centre frequency is: %5.4f\n", channel_center_frequency);

92

This code replaces lines 1218-1227 of the Function Block for the 802.15.4 MAC layer

(802 15 4 mac.pr.m).

/* Also update the module wide memory with appropriate symbol rate. */

/* For our case the symbol is equal to data rate */

modmem_ptr->symbol_rate = channel_info_ptr->drate;

drate_sv = channel_info_ptr->drate;

This code replaces lines 1231-1242 of the Function Block for the 802.15.4 MAC layer

(802 15 4 mac.pr.m).

/* Set the modulation to BPSK until ASK becomes available */

op_ima_obj_attr_set (tx_objid, "modulation", "bpsk");

op_ima_obj_attr_set (rcvr_objid, "modulation", "bpsk");

Appendix E

OPNET Limitations, Constraints

and Error Messages

This section is provided to assist troubleshooting of similar projects and to to assist in

reproducing the results presented in this report.

E.1 General Problems

Memory

<<< Program Fault >>>

program abort -- Invalid Memory Access

This error is due to the lack of available RAM on the PC running OPNET. Three things can

be done to solve problem. The first approach is to edit simulation parameters to reduce the

memory needed by the simulation. This isn’t a real option in most applications. Another

solution is to increase the RAM on the PC. It may also help to close all other applications

running on the PC to free up as much RAM as possible. The most viable solution is to

change the random seed number used in the simulation. It was found as a general rule that

reducing the seed number allowed memory greedy simulations to run successfully.

License Issues

To execute a simulation, you must contact a license server

93

94

with a valid "Simulation Site License" or "Simulation Runtime" license

Terminating Simulation.

This error is due to the OPNET software not being able to access the license file. This could

be due to another instance on OPNET already open on the PC, another PC has used the

license while it was not in use or OPNET might not of released the license last time it was

used if it terminated abruptly. From the OPNET start window go to ’License’ and then

’License Management’ to view the status of the license. Restarting OPNET can sometimes

solve this problem or restarting the PC if necessary.

Simulation Sample Rate

It was found that some measurements required a higher sampling rate then other measure-

ments to obtain correct results. This is true of BER and SNR. For example Figure E.1

which shows BER and SNR for a sample rate of 10 and 10M. The 10M samples does not

Figure E.1: SNR and BER Measurements for Different Sampling Rates

even seem to be enough and the maximum number of samples that can be exported into

Excel is approximately 64 000. This must be considered when taking these statistics. Using

the bucket function to collect sample mean results is suggested and not using ’values’ or

’seconds’ bucket functions.

95

E.2 Zigbee Problems

Maximum Number of Backoffs (SPR-119661)

The Maximum Number of Backoffs attribute for the Zigbee Modules is not functioning

correctly. By reducing this value it has no effect on the simulation results. This problem

is caused from the CSMA/CA process model allowing the number of backoffs to increment

beyond the maximum value set in the attributes, before being checked weather the backoff

limit has been reached. Nothing can be done to solve this problem until it is fixed in the

next release. Based on this a request has been entered into OPNET’s product enhancement

suggestions database and will be considered for inclusion in future releases of the OPNET

standard model library.

• SPR-119661: The Maximum Number of Backoffs is not taking effect in Zigbee’s

CSMA/CA logic.

The effect of this is that packets are never dropped and the device continues to attempt

transmission until the packet has accessed the medium.

Incorrect Overhead (SPR-119364)

The Zigbee modules assume a constant address field sizes of 7 bytes for all MPDUs. This

value is actually not correct for any combination of address sizes used in IEEE 802.15.4.

In addition to this the MAC overhead is 15 bytes and the PHY overhead an extra 3 bytes,

making a total of 18 byte. The actual data overhead used seems to count the MAC overhead

twice, using a total overhead value of 33 bytes. As seen in Chapter 4 that leads to a reduced

channel capacity and leads to incorrect simulation results. Based on this a request has been

entered into OPNET’s product enhancement suggestions database and will be considered

for inclusion in future releases of the OPNET standard model library.

• SPR-119364: 802.14.5 MAC should model the overhead of data MPDUs accurately.

A temporary fix to this problem that will more closely model reality is to replace line 26 of

the 802.15.4 Header Block with:

#define WPAN_MAC_DATA_OVERHEAD 24

96

Packet Fragmentation (SPR-119368)

The IEEE 802.15.4 specification does not support fragmentation. If it receives a packet

from an upper layer that is larger than the maximum payload size of the MPDU it rejects

the higher layer packet. This is not what happens in the OPNET implementation, as it

accepts a higher layer packet regardless of size and sends it in a single MPDU. Based on this

a request has been entered into OPNETs product enhancement suggestions database and

will be considered for inclusion in future releases of the OPNET standard model library.

• SPR-119368: 802.14.5 MAC should not send packets to PHY that are bigger than

the limit allowed in the specifications.

Hidden Source Code

The network and application layer source code of the Zigbee modules is intentionally hidden.

Access to the Zigbee source code requires membership in the Zigbee Alliance. As The

University of Newcastle is not a member this source code remained unavailable throughout

the project. This limited the projects scope as data aggregation sources could not be

implemented. Also it created problems when editing the 802.15.4 MAC layer process model.

It was not possible to create a new process model as it is referenced by name by the upper

layers that there is no access to. Because of this the process model could only be edited.

E.3 Modeling Custom Scenarios Problems

Step 1: Network Repositories

OPNET compile

string.H header files not there

To run customised modules OPNET has to be configured to not use the standard modules.

If this is not done the process modules will not compile and customised simulations will

not run. To allow this to be done ’stdmod’ has to be removed from the network simula-

tion repositories list. To do this go to ’Edit’ and then ’Preferences’ and then search for

repositories, delete ’stdmod’ from the list. This is explained in OPNET FAQ ID: 478.

97

Step 2: Environment Settings

<<< Recoverable Error >>>

Object repository construction failed

<<< Program Abort >>>

Error encountered rebuilding repository -- unable to proceed

At this stage it is important to check that proper system environment settings for Microsoft

Visual Studio are used. This is explained in OPNET FAQ ID: 1685. It must be noted that

the default settings listed in this FAQ are different to the installation path in the EE104

lab.

Step 2: Manifest Files

R6034: An application has made an attempt to load the C runtime library

incorrectly

After these steps have been taken the above error is received while trying to compile a

customised model. The solution is explained in OPNET FAQ ID: 2107 and 1685. Basically

it is caused because we are using Visual Studio 2005 on Windows XP and the solution

involves copying manifest files to a different directory.

E.4 Interference Problems

State Transition Error

<<< Program Abort >>>

No true transitions from state (scanning)

This error is received when modeling interference effects between Zigbee and the created

WLAN interference model. It is due to the Zigbee transmitter getting stuck in the ’scanning’

state in it’s MAC layer. This is due to a bug in the OPNET code where the interference

affects the node and it cannot satisfy any of the transition requirements of this state. It was

found that this is the borderline level between the interference level allowing transmissions

and not allowing any transmissions. Changing node attributes (power or interference packet

generation) a little either way will allow the simulation to run.

98

WLAN and Zigbee Incompatible (SPR-119094)

Simulation terminated by process (wlan_mac) at module (wireless\_lan\_mac),

Error reported by Wireless LAN MAC process:

Unexpected frame type received.

This error is produced when attempting to model Zigbee and WLAN devices in the same

simulation environment and is due to the Zigbee packet not being supported by the WLAN

link or transceiver channel. This is because the WLAN and Zigbee models are not com-

patible to co-exist. The errors are due to limitations in the wireless pipeline stages used by

the WLAN model. Those pipeline stages can handle only WLAN packets and unformatted

packets, thus the errors when they receive Zigbee packets. Based on this a request has been

entered into OPNET’s product enhancement suggestions database and will be considered

for inclusion in future releases of the OPNET standard model library.

• SPR-119094: WLAN models need to be made compatible with Zigbee/802.15.4

models to be able to study their coexistence.

Flat Power Spectral Density (PSD)

During the simulation of WLAN interference on Zigbee it was found that the PSD of all

devices in OPNET are flat. This is a large limitation when trying to model real interference

effects. In reality the actual power is more concentrated at the centre frequency and also

extends outside of the desired channel. This point must be noted when modeling interference

effects.

Bibliography

[1] H. Karl and A. Willig, Protocols and Architectures for Wireless Sensor Networks. John

Wiley and Sons, 2005.

[2] G. Boriello and R. Want, Embedded Computation Meets the World Wide Web. ACM

Publications, 2000.

[3] E. Monton, J. Hernandez, and J. Blasco, “Body Area Network for Wireless Patient

Monitoring,” IET, Communications, vol. 2, pp. 215–222, February 2008.

[4] N. Golmie, D. Cypher, and O. Rebala, “Performance Analysis of Low Rate Wireless

Technologies for Medical Applications,” Computer Communications, vol. 28, pp. 1266–

1275, June 2005.

[5] K. Banitsas, R. Istepanian, and S. Tachakra, “Applications of Medical Wireless LAN

Systems (MedLAN),” Journal of Medical Marketing, vol. 2, pp. 136–142, January 2002.

[6] M. Yuce, P. Ng, and J. Kahn, “Monitoring of Physiological Parameters from Multi-

ple Patients Using Wireless Sensor Networks,” Journal of Medical Systems, Springer

Science, vol. 32, pp. 433–441, March 2008.

[7] N. Chevrollier and N. Golmie, “On the Use of Wireless Network Technologies in Health-

care Environments,” Proceedings of the Fifth IEEE workshop on Applications and Ser-

vices in Wireless Networks (ASWN 2005). Paris, France, pp. 147–152, June 2005.

[8] J. Khan and M. Yuce, “Performance Evaluation of a Wireless Body Area Sensor Net-

work for Remote Patient Monitoring,” To appear in the IEEE Engineering in Medicine

and Biology Society (IEEE EMBC08), August 2008.

99

100

[9] H. Savci, A. Sula, Z. Wang, N. Dogan, and E. Arvas, “MICS Transceivers: Regulatory

Standards and Applications [Medical Implant Communications Service],” Southeast-

Con, 2005. Proceedings. IEEE, pp. 179–182, April 2005.

[10] N. Chevrollier, N. Montavont, and N. Golmie, “Handovers and Interference Mitiga-

tion in Healthcare Environments,” Proceedings of the IEEE Military Communications

Conference (MILCOM 2005), pp. 17–20, October 2005.

[11] M. Hansen and S. Stoa, “Practical Evaluation of IEEE 802.15.4/Zigbee Medical Sensor

Networks.” Masters Thesis, Norwegian University of Science and Technology, Depart-

ment of Electronics and Telecommunications, June 2006.

[12] P. Jurcik, A. Koubaa, M. Alves, E. Tovar, and Z. Hanzalek, “A Simulation Model for

the IEEE 802.15.4 Protocol: Delay/Throughput Evaluation of the GTS Mechanism,”

15th IEEE International Symposium on Modeling, Analysis, and Simulation of Com-

puter and Telecommunication Systems (MASCOTS07), Istanbul, Turkey, pp. 109–116,

October 2007.

[13] A. Cunha, “Technical Report, On the use of IEEE 802.15.4/Zigbee as Federating Com-

munication Protocols for Wireless Sensor Networks.” IPP Hurray, Technical Report-

070902, MSc Thesis, September 2007.

[14] S. Shin, H. Park, and W. Kwon, “Mutual Interference Analysis of IEEE 802.15.4 and

IEEE 802.11b,” Elsevier, Computer Networks, vol. 51, pp. 3338–3353, August 2007.

[15] A. Sikora and V. Groza, “Coexistence of IEEE 802.15.4 with other Systems in the

2.4 GHz-ISM-Band,” Instrumentation and Measurement Technology Conference, 2005.

IMTC 2005. Proceedings of the IEEE, vol. 3, pp. 1786–1791, May 2005.

[16] F. Karami, “An OPNET Simulation Model to Study a Body Area Sensor Network.”

School of Electrical Engineering and Computer Science, The University of Newcastle,

Final Year Thesis, October 2007.

[17] W. Odom, CCENT/CCNA INCD1, Official Exam Certification Guide. Cisco Press,

2007.

101

[18] “IEEE Standard for Wireless Medium Access Control (MAC) and Physical Layer

(PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs.”

IEEE Std.802.15.4, Official IEEE Standard, August 2003.

[19] Zigbee Alliance, “Zigbee Specification,” Zigbee Standards Organisation, Document

053474r17, January 2008.

[20] A. Ananda, M. Chan, and W. Ooi, Mobile, Wireless, Sensor Networks. Technology,

Applications, and Future Directions. IEEE Press, 2006.

[21] X. Liang and I. Balasingham, “Performance Analysis of the IEEE 802.15.4 Based ECG

Monitoring Network,” Proceedings of the Seventh ISATED International Conferences.

Wireless and Optical Communications, pp. 99–104, May-June 2007.

[22] A. Koubaa, M. Alves, and B. Nefzi, “Improving the IEEE 802.15.4 Slotted CSMA/CA

MAC for Time-Critical Events in Wireless Sensor Networks,” Fifth International Work-

shop of Real-Time Networks (RTN 2006). Dresden, Germany, June 2006.

[23] T. Kim, “Priority Toning Strategy for Fast Emergency Notification in IEEE 802.15.4

LR-WPAN,” In proceedings of the 15th Joint Conference on Communications and In-

formation (JCCI), April 2005.

[24] T. Kim and S. Choi, “Priority-Based delay Mitigation for Event-Monitoring IEEE

802.15.4 LR-PANS,” IEEE Communications Letters, vol. 10, pp. 213– 215, November

2005.

[25] A. Koubaa, M. Alves, and E. Tovar, “A Comprehensive Simulation Study of Slot-

ted CSMA/CA for IEEE 802.15.4 Wireless Sensor Networks,” in proceedings of the

6th IEEE International Workshop on Factory Communication Systems (WFCS 2006).

Torino, Italy, June 2006.

[26] P. Roshan and J. Leary, IEEE 802.11 Wireless LAN Fundamentals. Cisco Press, 2004.

[27] Y. Zhang, Wireless Mesh Networking. Architectures, Protocols and Standards. Auer-

bach Publications, 2007.

102

[28] M. Kohvakka, “Network Signaling Channel for Improving Zigbee Performance in Dy-

namic Cluster-Tree Networks,” EURASIP Journal on Wireless Communications and

Networking, p. 15, January 2008.

[29] I. Mahgoub and M. Ilyas, Smart Dust: Sensor Network Applications, Architecture, and

Design. Taylor and Francis, 2005.

[30] I. Mahgoub and M. Ilyas, Sensor Network Protocols. Taylor and Francis, 2006.

[31] A. Cunha, “Throughput and Delay Analysis of Unslotted IEEE 802.15.4,” Journal of

Networks, vol. 1, pp. 20–28, May 2008.

[32] D. Gratton, Developing Practical Wireless Applications. Digital Press, 2007.

[33] I. Stojmenovic, Handbook of Sensor Networks Algorithms and Architecture. John Wiley

and Sons, 2005.

[34] J. Ko, Y. Cho, and H. Kim, “Performance Evaluation of IEEE 802.15.4 MAC with

Different Backoff Ranges in Wireless Networks,” 10th IEEE Singapore International

Conference on Communication systems, pp. 1–5, October 2006.

[35] “OPNET User Manual.” OPNET Technologies, Online User Documentation, 2008.

[36] N. Steven, M. Yuce, and J. Khan, “Wireless Body Sensor Network Using Medical

Implant Band,” Journal of Medical Systems, vol. 31, pp. 467 – 474, april 2007.

[37] M. Yuce, P. C. Ng, C. Lee, J. Khan, and W. Liu, “A Wireless Medical Monitoring

Over a Heterogeneous Sensor Network,” Engineering in Medicine and Biology Society,

2007. EMBS 2007. 29th Annual International Conference of the IEEE, pp. 5894–5898,

Aug. 2007.

[38] “Calculating 802.15.4 Data Rates.” Jennic Technologies, Application Note: JA-AN-

1035, August 2006.

[39] M. Yuce and C. Ho, “Implementation of Body Area Networks Based on MICS/WMTS

Medical Bands for Healthcare Systems,” To appear in the IEEE Engineering in

Medicine and Biology Society (IEEE EMBC08), August 2008.

103

[40] M. Yuce, “Wireless Body Sensor Network Using Medical Implant Band,” Journal of

Medical Systems (Springer Science), vol. 31, pp. 467–474, December 2007.

[41] “Wireless Module User Guide for Modeler.” Wireless Module Documentation. OPNET

Technologies, Inc. Product Release 11.0, 2005.

[42] S. Y. Shin, H. S. Park, S. Choi, and W. H. Kwon, “Packet Error Rate Analysis of

Zigbee Under WLAN and Bluetooth Interferences,” Wireless Communications, IEEE

Transactions, vol. 6, pp. 2825–2830, August 2007.

[43] Z. Tao, S. Panwa, D. Gu, and J. Zhang, “Performance Analysis and a Proposed Im-

provement for the IEEE 802.15.4 Contention Access Period,” IEEE Wireless Commu-

nications and Networking Conference (WCNC), April 2006.

[44] J. Misic and V. Misic, Wireless Personal Area Networks. Performance, Interconnec-

tions and Security with IEEE 802.15.4. John Wiley & Sons, Ltd, 2008.

[45] “IEEE 802.15.4 Wireless Networks User Guide.” Jennic Technologies, Application

Note: JN-UG-1034, October 2006.

[46] M. Yuce, S. Ng, N. Myo, C. Lee, J. Khan, , and W. Liu, “A MICS Band Wireless

Body Sensor Network,” This full text paper was peer reviewed at the direction of IEEE

Communications Society subject matter experts for publication in the WCNC 2007

proceedings., October 2007.