Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Communication Protocols for a
   Multi-Hoping Wireless Body Sensor
               Network


                         Garri...
Table of Contents

Table of Contents                                                                                      ...
ii



5 Multi-Patient WBSN Hospital Room                                                                                  ...
iii



C Wireless Transmission of Data in OPNET                                                                         74...
Abstract

A wireless body sensor network (WBSN) is a wireless network that incorporates embed-
ded sensors on the human bo...
Contributions

The author has made the following contributions toward the completion of this project.

  1. Design, simula...
Chapter 1

Introduction

1.1    Wireless Sensor Network Evolution

In the past, the most common form of information proces...
2



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



1.3     WSNs in Medical Environments

Monitoring patients and collecting data for analysis is a major issue for healt...
4



   • Drug Administration: WBSN can be used to automatically administer drugs to
     patients [1] based on a time sch...
5



fatigue and stress [3]. In this application the patients have unobtrusive sensors connected to
a wireless device that...
Chapter 2

Technical Background

2.1    MAC Protocol Overview

The MAC protocol in a WBSN must achieve the following tasks...
7



2.2     IEEE 802.15.4

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



  Frequency      Bandwidth (kb/s)        Modulation      Location      No. Of Channels
  2.4 GHz              250    ...
9



        1. Personal Area Network (PAN) Coordinator (Coordinator)
        2. Simple Coordinator (Router)
        3. Si...
10



has a standard library that supports the non-beaconed mode. For this reason this report
focuses on this version, but...
11



   • If NB is below it’s maximum value it recalculates a new delay period. When NB
      reaches it’s maximum value ...
12



achieved by choosing non-overlapping channels [7, 15] as seen in Figure 2.3. Because the




         Figure 2.3: Ch...
Chapter 3

Literature Review and Proposed
Work

This report has three main objectives as highlighted by the sections below...
14



3.2     Priority For Critical Data

Literature Review

In [23] slotted CSMA/CA was enhanced to allow higher QoS for ...
15



Proposed Work

Once a multi-patient WBSN has been designed, simulated and evaluated QoS considerations
will be made ...
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 si...
17



has developed a multi-hop sensor network system to monitor physiological parameters from
patient bodies that utilise...
Chapter 4

OPNET and Theoretical Limits

4.1    Theoretical Delay and Throughput

To be able to understand the results fro...
19



sequence (backoff schemes, inter-frame spaces, sending of ACKs etc.) The delay to transmit
one packet is related to t...
20



the number of backoff slots can be represented as the average of the interval, which is 3.5.
Also the time for each b...
21



4.2     OPNET Channel Capacity

OPNET Overhead

All simulations are done using OPNET (Optimized Network Evaluation T...
22




              Figure 4.2: MPDU and PPDU Data Frames used in OPNET


Frame at the PHY and MAC layer. This value corr...
23



(2.4 GHz) the maximum channel capacity is 250kbps. But this is not all pure data and has
to include header bytes, CS...
24



OPNET Performance Evaluation

It was shown that the actual pure channel capacity is less than 157.0 kb/s. The maximu...
25



4.3      Transmission Power

The Zigbee modules have a default receiver sensitivity of -85dBm. This defines the recei...
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 ...
28



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

   • Sensors: ...
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, C...
30



from sensors of other PCUs. This could possibly lead to devices sensing the medium as idle
when it actually is not.
...
31



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

   • Sensor 2: This group includes blood flow,...
32



wait until the 73rd sample has arrived. So the aggregation delay is 145 ms and 485 ms for
sensor 1 and sensor 2 resp...
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 rece...
35



channel. When there is a problem with the communication channel a device can become
an orphan if it loses communicat...
36



is much lower than that used in IEEE 802.11 which has 1023 maximum backoff slots [31].
This will degrade performance ...
Chapter 6

Improvements for Critical Patient
Data

Now that a WBSN has been designed, simulated and evaluated it is now ti...
38



load as in [39]. The latter raises interference concerns that are investigated in Chapter 7.
For the remainder of th...
39



     in the CSMA/CA algorithm which is used to randomly find the number of backoff
     periods [35].

   • ACK Mechan...
40




                            Figure 6.1: ACK Timing Diagram


give the device time to change from receive state to t...
41



sucessful on the first retransmission and 94% are sucessful after the second retransmission.
This success rate does n...
42




                          Figure 6.3: macMinBE Effect on Delay


higher probability of selecting a shorter backoff ti...
43




                      Figure 6.4: macMinBE Effect on Throughput


on the BER of the network as seen in Figure 6.5 wh...
44




                          Figure 6.5: macMinBE Effect on BER


data. This gives improvements in delay and throughput...
45



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



overhead introduced to ensure reliable data delivery. The application data throughput for
critical data has improved...
Chapter 7

Interference Analysis

As introduced in Chapter 2 both IEEE 802.15.4 and IEEE 802.11b use the unlicensed ISM
fr...
48



7.1.1   Modification of Existing Nodes

The existing WLAN nodes were edited to allow compatibility with Zigbee so tha...
49



In creating the interference sources the following pipeline stages were used.

   • Receiver Group: The dra rxgroup ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Communication Protocols for a Multi-Hoping Wireless Body ...
Upcoming SlideShare
Loading in …5
×

Communication Protocols for a Multi-Hoping Wireless Body ...

2,230 views

Published on

  • Be the first to comment

  • Be the first to like this

Communication Protocols for a Multi-Hoping Wireless Body ...

  1. 1. Communication Protocols for a Multi-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.
  2. 2. Table of Contents Table of Contents i Abstract iv Contributions v 1 Introduction 1 1.1 Wireless Sensor Network Evolution . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 WSN Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 WSNs in Medical Environments . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Technical Background 6 2.1 MAC Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2 Medium Access Control Layer . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Non-Beaconed Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 Unslotted CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Interference and Coexistence . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Literature Review and Proposed Work 13 3.1 Multi-Patient WBSN Design . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Priority For Critical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 Interference Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4 MICS and WMTS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4 OPNET and Theoretical Limits 18 4.1 Theoretical Delay and Throughput . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 OPNET Channel Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 Transmission Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 i
  3. 3. ii 5 Multi-Patient WBSN Hospital Room 27 5.1 Design of a Multi-Patient WBSN Hospital Room . . . . . . . . . . . . . . . 27 5.2 Multi-Patient WBSN Simulation Results . . . . . . . . . . . . . . . . . . . . 32 6 Improvements for Critical Patient Data 37 6.1 Network Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.2 CSMA/CA and MAC Parameter Modifications . . . . . . . . . . . . . . . . 38 6.2.1 ACK Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.2.2 Minimum Backoff Exponent . . . . . . . . . . . . . . . . . . . . . . . 41 6.2.3 Maximum Number of Backoffs . . . . . . . . . . . . . . . . . . . . . 44 6.3 Transmission Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.4 Combined Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7 Interference Analysis 47 7.1 Modeling Interference in OPNET . . . . . . . . . . . . . . . . . . . . . . . . 47 7.1.1 Modification of Existing Nodes . . . . . . . . . . . . . . . . . . . . . 48 7.1.2 Interference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.1.3 Limitations of Designed Nodes . . . . . . . . . . . . . . . . . . . . . 50 7.2 Interference Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7.2.1 WLAN Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.2.2 Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.2.3 Frequency Band Overlap . . . . . . . . . . . . . . . . . . . . . . . . 54 7.2.4 IEEE 802.15.4 Packet Size . . . . . . . . . . . . . . . . . . . . . . . . 55 7.3 Interference Effects on Multi-Patient WBSN . . . . . . . . . . . . . . . . . . 56 8 Modeling MICS and WMTS Services 59 8.1 Medical Implant Communication Service (MICS) . . . . . . . . . . . . . . . 59 8.2 Wireless Medical Telemetry Service (WMTS) . . . . . . . . . . . . . . . . . 60 8.3 OPNET Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9 Conclusion and Future Work 63 9.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 A Beacon-Enabled Mode and CSMA/CA Algorithms 65 A.1 Beacon-Enabled Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 A.2 Slotted CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 A.3 Unslotted CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 B Simulation Results 71 B.1 Original Design Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 B.2 Improved Design Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
  4. 4. iii C Wireless Transmission of Data in OPNET 74 C.1 Radio Transceiver Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 C.2 Graphical Radio Transceiver Pipeline Stages . . . . . . . . . . . . . . . . . . 81 C.3 Standard Specific Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . 82 D MICS and WMTS Implementation Code 83 D.1 Dual Implementation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 D.2 WMTS Implementation Code . . . . . . . . . . . . . . . . . . . . . . . . . . 86 D.3 MICS Implementation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 E OPNET Limitations, Constraints and Error Messages 93 E.1 General Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 E.2 Zigbee Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 E.3 Modeling Custom Scenarios Problems . . . . . . . . . . . . . . . . . . . . . 96 E.4 Interference Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Bibliography 99
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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.
  9. 9. 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.
  10. 10. 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,
  11. 11. 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].
  12. 12. 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
  13. 13. 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
  14. 14. 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]:
  15. 15. 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
  16. 16. 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].
  17. 17. 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
  18. 18. 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].
  19. 19. 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
  20. 20. 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.
  21. 21. 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
  22. 22. 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]
  23. 23. 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].
  24. 24. 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
  25. 25. 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: 8x TP = (4.1) delay(x) Where x is the payload in bytes that has been received from the network layer and the delay on each packet is given by: delay(x) = TBO + Tf rame (x) + TT A + TACK + TIF S (x) (4.2) Where • TBO is the backoff period • Tf rame (x) is the transmission time for x payload bytes • TT A is the turn around time • TACK is the transmission time for an ACK • TIF S is the inter-frame spacing (IFS) time In regards to the IFS a Short Inter-Frame Spacing (SIFS) is used when the MAC Protocol Data Unit (MPDU) is smaller than or equal to 18 bytes. If the MPDU is greater than this a Long Inter-Frame Spacing (LIFS) is used and this is the case that we will be considering. Now we need to consider the time associated with the backoff period. The back off period is expressed as follows: TBO = BOslots • TBOslots (4.3) Where: • BOslots is the number of unit backoff slots • TBOslots is the time for each backoff slot (aUnitBackoffPeriod) As seen earlier the number of backoff slots is a random number in the interval (0, 2 BE − 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
  26. 26. 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: SP HY + SM AC HDR + Saddress + x + SM AC FTR Tf rame (x) = 8 (4.4) Rdata Where: • SP HY is the size of the PHY overhead in bytes • SM AC HDR is the size of the MAC header in bytes • SADDRESS is the size of the MAC address info field • SM AC FTR is the size of the MAC footer in bytes • Rdata is the raw data rate Equation 4.1 can now be graphed for both throughput and delay. Figure 4.1 shows this graph for ACKs enabled and using 16 bit addressing. Figure 4.1: Theoretical Limits of Throughput and Delay
  27. 27. 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 4 SFD 1 Frame Length and Reserved Bit 1 MAC Overhead 12 Frame Control 2 Sequence Number 1 FCS 2 Address Fields 7 Table 4.1: MAC and PHY OPNET Overhead packet size attribute in OPNET refers to application data payload. It is this payload with the addition of the MAC overhead from Table 4.1 that makes up the MAC Protocol Data Unit (MPDU). The Physical Protocol Data Unit (PPDU) is a combination of the MPDU and the PHY overhead from Table 4.1. The frame structure used in OPNET is seen in Figure 4.21 . The standard 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 1 The address fields have a length of 7 bytes but this is not completely accurate of a real system, see Appendix E for more information.
  28. 28. 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
  29. 29. 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]: Tpayload C = CP (4.5) Tpayload + Tack + Toverhead + Twait Where: Spayload Tpayload = , CP Sack Tack = , CP Soverhead Toverhead = 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: 3.52ms C ≤ 250kb/s 3.52ms + 0.352ms + 0.576ms + 1.152ms C ≤ 157.14kb/s (4.6) This equates to 63% of the maximum stated channel capacity. 2 The minimum CCA wait time, minimum radio turnaround time and minimum inter-frame spacing are used to get a wait time of 1.152 ms [11]
  30. 30. 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.
  31. 31. 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: 4πd P L = 20 • log (dB) (4.7) λ Where: • d is the distance between transmitter and receiver c • λ is the wavelength of the signal and is equal to f where c is the speed of light and f is the frequency By using Equation 4.7 and the receiver threshold the maximum transmission distance be- tween two nodes was determined for a range of transmit powers and these values were then compared to the OPNET simulated values. The results are presented in Figure 4.5 and as can be seen the simulated results in OPNET agree with that of the theory. It is therefore assumed that this figure is an accurate method to determine the transmit powers for the WBSN design.
  32. 32. 26 Figure 4.5: IEEE 802.15.4 Transmitter Power
  33. 33. 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 Data Signal Range Time Size Rate (sec) (bits) (kb/s) Blood Flow 1-300 ml/s 0.025 12 0.48 ECG 0.5-4 mV 0.002 12 6.0 Respiratory Rate 2-50 breaths/min 0.05 12 0.24 Blood Pressure 10-400 mm Hg 0.01 12 1.2 Blood pH 6.8-7.8 pH units 0.25 12 0.048 Body Temperature 32-40 deg C 0.025 12 0.0024 Table 5.1: Physiological Parameters 27
  34. 34. 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
  35. 35. 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 Transmit Type Distance (m) Constraint Power Sensor 0.5 High -50 dBm PCU 8 High -26.6 dBm CCU 8 Low 0 dBm DB 10 Low 0 dBm Table 5.2: Preliminary Device 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
  36. 36. 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:
  37. 37. 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
  38. 38. 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: 1 The simulations were run for 5 different seed values for a duration of 600s. The average was then taken to get the results presented
  39. 39. 33 Figure 5.2: End-to-End Application Data Delay Figure 5.3: Application Data Throughput
  40. 40. 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
  41. 41. 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 P ER = 1 − (1 − BER)L , where L is packet length, gives a much larger PER than there actually is. As can be seen all devices experience a large jump in BER from Figure 5.5: PCU, CCU and DB BER three to 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
  42. 42. 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.
  43. 43. 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
  44. 44. 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
  45. 45. 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 TT A and TACK . 6.2.1 ACK Mechanism When the ACK mechanism is enabled the receiver must send an ACK packet to the trans- mitter when it successfully receives data packets. The following results compare the network performance when ACKs are enabled on all data, no data and on only critical patient data. When ACKs are completely disabled the critical data has an unacceptable loss of 28%. For this reason alone this scenario cannot be used, independent of the 46.8% reduction in end to end delay. The scenario where only critical data is acknowoledged is ideal for our appli- cation. By partialy disabling ACKs the end-to-end delay of both critical and non-critical data has been reduced by 24.5% and 59.5% respectively. In addition to this the critical data has negligible data loss while the non-critical data is losing 26.1% of data genarated, which is acceptable for this type of data. In addition to the results presented here the full results are presented in Table B.3. This improvement in delay requires an understanding of the ACK mechanism process. When ACKs are disabled on all or some devices less control data needs to be transmitted. These ACK packets do not use CSMA/CA to access the medium, instead they uses timing to ensure that nodes don’t transmit until after the ACK frame has been received. The timing for ACK frames is seen in Figure 6.1. So while the ACK frames do not actively contest for the medium they do occupy bandwidth by using dedicated timing intervals, Tack and TT A , that otherwise could be used for data transfer. By disabling ACKs both TT A and TACK can be excluded from Equation 4.2. TACK is the time it takes to transmit the ACK packet and TT A is the turnaround time which is used to
  46. 46. 40 Figure 6.1: ACK Timing Diagram give the device time to change from receive state to transmit state. These parameters have the values: TT A = 0.192ms (6.1) SACK 88 TACK = = = 0.352ms (6.2) C 250000 TT A + TACK = 0.544ms (6.3) In our system 108 packets are generated per second excluding retransmissions. Therefore the minimum time required every ACK transmission is 58ms. This is 5.8% of the total time available for tranmsission. This value is the minimum boundary and will rise when restrnamsisisons are necessary, which as seen in Chapter 5 are common in this design. The ACK retry threshold (aMaxFrameRetries) was also investigated to 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)
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. 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
  51. 51. 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
  52. 52. 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.
  53. 53. 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
  54. 54. 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.
  55. 55. 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

×