Communication Protocols for a Multi-Hoping Wireless Body Sensor Network

Transcription

1 Communication Protocols for a Multi-Hoping Wireless Body Sensor Network Garrick Bugler ( ) 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 Table of Contents Table of Contents Abstract Contributions i iv v 1 Introduction Wireless Sensor Network Evolution WSN Applications WSNs in Medical Environments Technical Background MAC Protocol Overview IEEE Physical Layer Medium Access Control Layer Network Architecture Non-Beaconed Mode Data Transfer Unslotted CSMA/CA Interference and Coexistence Literature Review and Proposed Work Multi-Patient WBSN Design Priority For Critical Data Interference Analysis MICS and WMTS Services OPNET and Theoretical Limits Theoretical Delay and Throughput OPNET Channel Capacity Transmission Power i

3 ii 5 Multi-Patient WBSN Hospital Room Design of a Multi-Patient WBSN Hospital Room Multi-Patient WBSN Simulation Results Improvements for Critical Patient Data Network Backbone CSMA/CA and MAC Parameter Modifications ACK Mechanism Minimum Backoff Exponent Maximum Number of Backoffs Transmission Power Combined Results Interference Analysis Modeling Interference in OPNET Modification of Existing Nodes Interference Model Limitations of Designed Nodes Interference Results WLAN Applications Distance Frequency Band Overlap IEEE Packet Size Interference Effects on Multi-Patient WBSN Modeling MICS and WMTS Services Medical Implant Communication Service (MICS) Wireless Medical Telemetry Service (WMTS) OPNET Implementation Conclusion and Future Work Conclusion Future Work A Beacon-Enabled Mode and CSMA/CA Algorithms 65 A.1 Beacon-Enabled Mode A.2 Slotted CSMA/CA A.3 Unslotted CSMA/CA B Simulation Results 71 B.1 Original Design Results B.2 Improved Design Results

4 iii C Wireless Transmission of Data in OPNET 74 C.1 Radio Transceiver Pipeline C.2 Graphical Radio Transceiver Pipeline Stages C.3 Standard Specific Pipeline Stages D MICS and WMTS Implementation Code 83 D.1 Dual Implementation Code D.2 WMTS Implementation Code D.3 MICS Implementation Code E OPNET Limitations, Constraints and Error Messages 93 E.1 General Problems E.2 Zigbee Problems E.3 Modeling Custom Scenarios Problems E.4 Interference Problems Bibliography 99

5 Abstract A wireless body sensor network (WBSN) is a wireless network that incorporates embedded 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 allowing remote access of data whenever necessary. This project aims to investigate various aspects of IEEE 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 interference 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 excessive 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 successful in the design and construction of an interference model that accurately models various IEEE b 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 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 using these services by modifying existing OPNET source code. iv

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 protocol parameters and consideration of network backbone infrastructure. 3. Proposed final design wireless body sensor network with recommendations and constraints defined. 4. Design and construction of an interference model for various wireless local area network applications. 5. Simulation and evaluation of interference on the designed wireless body area network. 6. Implementation of IEEE 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 Chapter 1 Introduction 1.1 Wireless Sensor Network Evolution In the past, the most common form of information processing has been done on multipurpose 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 influenced 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 applications 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 microprocessors 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 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 composition in paddocks to allow precise irrigation, fertilisation and pest control measures [1]. Intelligent Buildings: Sensor nodes monitor real-time values of temperature, humidity, 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 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 creates 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 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 elderly, 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 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 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 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 7 2.2 IEEE This report specifically deals with the IEEE protocol. The IEEE finalised this standard in October of 2003 [1]. IEEE defines both the PHY and MAC sublayer [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 and Zigbee interchangeably. Zigbee is an emerging standard from the Zigbee Alliance [1] that uses IEEE 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 are used interchangeably. Figure 2.1: IEEE and Zigbee Open System Interconnection (OSI) Model Physical Layer IEEE 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 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 8 Frequency Bandwidth (kb/s) Modulation Location No. Of Channels 2.4 GHz 250 OQPSK Worldwide MHz 40 BPSK Americans MHz 20 BPSK Europe 1 Table 2.1: IEEE Technical Specifications bandwidth per channel and the greatest number of channels (16 non overlapping) and is the dominant band for IEEE chips [15]. The 2.4 GHz frequency is what we will be concerned with when referring to Zigbee or IEEE 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 is a single channel protocol and can only use one channel at a time [1] Medium Access Control Layer IEEE uses Carrier Sense Multiple Access (CSMA) as part of it data transfer procedure. 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 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 MAC protocol, they are: Full Function Device (FFD): This device can be used as any one of three roles [1]:

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 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 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] Data Transfer In non-beaconed mode the entire channel access time is made up of one continuous contention access period (CAP). The lack of a beacon means that the devices are not time synchronised 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] 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, 2 BE 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 11 If NB is below it s maximum value it recalculates a new delay period. reaches it s maximum value a transmission failure is reported [11]. When NB 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 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 (Zigbee), IEEE (WLAN) and IEEE (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 b IEEE b is one protocol out of a group of protocols that define WLANs. The terms IEEE b and WLAN will be used interchangeably throughout this report. IEEE b operates at the 2.4GHz and 5GHz frequencies. Since both IEEE and WLANs use spread spectrum techniques, it is theoretically possible that coexistence can be

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 and IEEE b bandwidth of IEEE b is larger than that of IEEE , the interference power of IEEE b can be considered as Additive White Gaussian Noise (AWGN) on IEEE Also the interference power of IEEE 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 [15]. Some IEEE b 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 has an Energy Detection (ED) function to determine the activity of another system but lacks a DCS tool [15].

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 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 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 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 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 location. 3.3 Interference Analysis Literature Review [4] investigates the interference between multiple IEEE systems. This mutual interference 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 optional dynamic procedures [4]. [4] investigated the effects when two IEEE 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 for different applications, including file transfer protocol (FTP), hyper text transfer protocol (HTTP), , and video. The IEEE transmitted four types of data while the previous WLAN data transfers were taking place. The IEEE signals were ECG, blood analysis, supervisory data and alarm status. This was done with the IEEE

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 system. In this situation [4] concluded that the likelehood of data not reaching its destinalltion is so high that one should not use IEEE under these circumstances. For the latter situation where IEEE used CCAs on both its frames and WLAN frames it was observed that the packet loss was lower for almost all applications but was still at an unacceptably high level. The WLAN packet loss was negligible in this scenario as the IEEE 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 In some situations the BER in the IEEE 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 Service (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 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 communications. Proposed Work This report aims to model IEEE using the WMTS and MICS services by modification 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 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 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: T P = 8x delay(x) (4.1) Where x is the payload in bytes that has been received from the network layer and the delay on each packet is given by: delay(x) = T BO + T frame (x) + T T A + T ACK + T IF S (x) (4.2) Where T BO is the backoff period T frame (x) is the transmission time for x payload bytes T T A is the turn around time T ACK is the transmission time for an ACK T IF 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: T BO = BO slots T BOslots (4.3) Where: BO slots is the number of unit backoff slots T BOslots 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 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: Where: T frame (x) = 8 S P HY + S MAC HDR + S address + x + S MAC F T R R data (4.4) S P HY is the size of the PHY overhead in bytes S MAC HDR is the size of the MAC header in bytes S ADDRESS is the size of the MAC address info field S MAC F T R is the size of the MAC footer in bytes R data 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 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 The following values of overhead were discovered by running simulations, reading source code and by contact with OPNET technical support. 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 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. The

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 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 At the frequency that we are concerned with in this report

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]: Where: C = C P T payload T payload + T ack + T overhead + T wait (4.5) A description of all terms is seen below: T payload = S payload C P, T ack = S ack C P, T overhead = S overhead C P T wait is the minimum time the radio has to wait before sending a packet T payload is the time it takes to transmit the actual data payload T ack is the time it takes to send the ACK packet over the air T overhead is the time it takes to send the MAC and PHY overheads over the air S payload is the size of the payload S ack is the size of the ACK packet S overhead is the total size of the MAC and PHY overhead C P 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 ms ms ms This equates to 63% of the maximum stated channel capacity. C kb/s (4.6) 2 The minimum CCA wait time, minimum radio turnaround time and minimum inter-frame spacing are used to get a wait time of ms [11]

30 24 OPNET Performance Evaluation It was shown that the actual pure channel capacity is less than 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 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: Where: P L = 20 log 4πd (db) (4.7) λ d is the distance between transmitter and receiver λ is the wavelength of the signal and is equal to c 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 between 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 Figure 4.5: IEEE Transmitter Power 26

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 ml/s ECG mv Respiratory Rate 2-50 breaths/min Blood Pressure mm Hg Blood ph ph units Body Temperature deg C Table 5.1: Physiological Parameters 27

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 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 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. 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. In a 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 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 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 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) Inter-Arrival Time (s) 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 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 performance 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 successfully 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 33 Figure 5.2: End-to-End Application Data Delay Figure 5.3: Application Data Throughput

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 exceeded. 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 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 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 36 is much lower than that used in IEEE 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 patients. 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 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 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 introduces 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 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 resimulated 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 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 T BO while the ACK mechanism affects T T A and T ACK ACK Mechanism When the ACK mechanism is enabled the receiver must send an ACK packet to the transmitter 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 application. 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, T ack and T T A, that otherwise could be used for data transfer. By disabling ACKs both T T A and T ACK can be excluded from Equation 4.2. T ACK is the time it takes to transmit the ACK packet and T T A is the turnaround time which is used to

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: T T A = 0.192ms (6.1) T ACK = S ACK C = 88 = 0.352ms (6.2) T T A + T ACK = 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 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 retranmsissions. 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 network 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 Minimum Backoff Exponent The number of backoff slots for each delay period is randomly chosen from the range [0,2 BE 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 algorithm). 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 avoidance 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 BO slots 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 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 corresponds 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 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 improvement 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. Consequently 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 optimal value for critical data. It is recommended to use a macminbe of one for the critical

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 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 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 dbm dbm dbm 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 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 Chapter 7 Interference Analysis As introduced in Chapter 2 both IEEE and IEEE b use the unlicensed ISM frequency band to transmit data. This section relates to modeling interference effects of IEEE b on IEEE that might exist in a hospital environment. More specifically 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 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 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 application (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, bandwidth, 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 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 itself 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 interference nodes will model IEEE b 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. 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 system. Attribute WLAN IEEE 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 The

56 Limitations of Designed Nodes The created WLAN interference nodes are limited to modeling the PHY layer only. As mentioned this will model things like frequency, modulation type, data rate, packet lengths etc, but with no MAC layer functions. This limits the investigation in the following ways: The lack of a MAC protocol means a absence of IFS. This will not allow us to investigate weather there is transmission of IEEE in the IFS between transmissions of IEEE b frames. This theoretically could allow transmissions of small packets in highly congested networks. As there is no channel access protocol IEEE packets will not affect WLAN transmission. This is not a major issue as we are not looking at the effect on WLAN, although collisions would require retransmissions which would increase the load on the medium possibly causing a greater interference effect on IEEE Interference Results To verify the accuracy of the WLAN interference nodes and to investigate the basic effects of interference the setup seen in Figure 7.1 was used to investigate interference effects in a number of different scenarios. The distances, D Z and D W LAN, are varied accordingly and Figure 7.1: Setup for Modeling Interference Effects represent the distance between Zigbee transmitter, and WLAN transmitter, with the Zigbee receiver respectively. The different scenarios below varied the type of WLAN application traffic, the distance between the WLAN and Zigbee devices, the size of Zigbee packets and also the Zigbee transmission channel. The Zigbee data transmission characteristics are kept

57 51 constant throughout the simulations unless otherwise mentioned. The data transmission models the sensor 1 data from Chapter 5 and 6 and has ACKs disabled. A note must be made about the effect of the interference on the Zigbee PAN formation. If sufficient interference is present before the PAN is formed it can become impossible for the PAN to form and data transfer cannot take place. If the interference is configured to start after the PAN has formed then data transfer can still be possible with this same amount of interference. This occurs because data transfer can complete with a one way transfer of data, PAN formation on the other hand requires a multi-step handshake that has more chance of experiencing packet loss. For this reason the interference sources start emitting interference after the Zigbee network has formed. The practical implications of this is that in high interference locations the Zigbee network will not form at all thus raising the interference issue during network implementation. Although WLAN usually produces burstly traffic and thus is more likely to have periods of low and high use, allowing PAN formation WLAN Applications This section investigates the interference effect of different types of WLAN data. Different types of WLAN applications have variations in packet inter-arrival time and also data and packet distribution types. The WLAN maximum packet size was kept constant for all applications. The maximum payload was bits with additional overhead of 224 bits per packet, making a total maximum packet size of bits, to agree with the scenario in [4]. Table 7.2 shows the WLAN parameters for each data application which are also based on [4] except for the video application which is based on MJPEG (medium compression) with 20 frames per sec and a frame size of 46 kb/s. Each WLAN application was broadcast over the Zigbee data transfer to produce the results in Table 7.3. D Z and D W LAN were both set to a constant value of 5m. As can be seen the and HTTP applications have very little effect on the Zigbee system. The only has a very small effect on the MAC delay (0.14ms) and causes no collisions. HTTP does cause collisions at the Zigbee receiver which accounts for a small percentage of data loss. The FTP and video applications have a great effect on the performance of the Zigbee devices. They are only allowing 7% and 5% respectively of total application data to be delivered due to collisions. There is also a dramatic increase in MAC delay. Overall as the amount of interference in incresed we are

58 52 WLAN Inter-arrival Packet File Size Packet Application Time (s) Generation (Bytes) Distribution Distribution Send Group 120 Exponential 1024 Constant Receive Group 60 Exponential 1024 Constant HTTP Object 1 5 Exponential Constant Object 2 5 Exponential to Uniform FTP 120 Constant 100 M Constant Video 0.03 Constant Constant Table 7.2: WLAN Applications WLAN Application BER End- End Application Data Loss (%) Delay (ms) No Interference HTTP E FTP E Video E Table 7.3: WLAN Applications Results

59 53 seeing an increase in MAC delay. The increase in MAC delay is caused from the Zigbee tranmsimmer performing a CCA and determining a busy medium due to the interference. It must be noted that all data generated is tranmsitted and no packets are dropped due to channel access problems. All lost data is due to collisions after the medium has been accessed. This is due to the Maximum Number of Backoffs error identified in Chapter 6 and is explanied in Appendix E Distance This section investigates the effect of varying the distance between WLAN and Zigbee devices using the different application data sources. D W LAN was varied from xero to ten meters while D Z was set to tem meters to produce Figure 7.2. Again throughput is defined as Figure 7.2: Effect of WLAN Distance on Interference the application data delivered to the source as a percentage of the total generated application data. As can be seen, for FTP and video, the degradation in network performance occurs at a distance of around 8m from the Zigbee device and performance continues to decline until it is 4m, where and the Zigbee throughput is zero. The application was not included in the figure as it did not impact the throughput even at small distances. Also the HTTP has little effect on the throughput, it did experience a decrease in throughput at a similar distance as FTP and video but as can be seen this decrease is small and throughput

60 54 does not drop below 98%. These results agree with that from [14]. It is also important to consider the effect of varying the distance between Zigbee transmitter and receiver and Figure 7.3 shows the results of this when D Z is varied between zero and ten meters and D W LAN is set to five meters. These results show a similar shaped curve as when varying Figure 7.3: Effect of Zigbee Separation with Interference the WLAN distance. There is no data loss when the Zigbee devices are less than 3m apart. With an increase of only 2m the throughput drops to zero. There is a stepping variation as the throughput drops with distance. This effect was much larger for shorter simulation runs and was reduced as the simulation length was increased Frequency Band Overlap This section investigated the interference as the Zigbee channel is varied across the band of a transmitting WLAN station. WLAN channel 11 was used and the Zigbee channels were varied from 20 to 26. This gives a full range of possible overlap. The results showed no change between various Zigbee channels inside the WLAN channel. This shows that the created interference models have a constant power spectral density (PSD) profile throughout the 22 MHz spectrum. This is not what happens in reality, where the maximum intensity is at the center frequency and there are side bands present outside the frequency range. After further investigation it was found that this is not just a limit of the created interference

61 55 nodes but exists in all OPNET models (including Zigbee). To be able to fully understand the coexistence issues between these two standards a model must be developed to take into account an imperfect radio channel IEEE Packet Size This section explores the effect of changing the IEEE packet size in regards to interference. Figure 7.4 shows the change in application data throughput as the packet size changes. In these simulations the application data rate is kept constant while changing the packet size. When the packet size is small there is a greater overall data rate due to the increase in overhead. Initially, looking from right to left, the throughput increases as the Figure 7.4: Packet Size Effect on Throughput packet size decreases. This happens until a critical point, where the throughput quickly decreases. As the data rate of Zigbee is increased the critical point occurs at larger packet sizes. The 12 kb/s scenario only just peaks at a packet size of 880 bits while the 18 kb/s application has a peak greater that 880 bits, which is not supported by Zigbee and is not shown. The reason for the increases in performance for smaller packet size is that a smaller packet has less chance of a bit error than a large packet. This is seen in Figure 7.5 which shows a comparison of BER and bit errors per packer (BE/P). As can be seen the BE/P decreases as packet size decreases as explained above. The BER on the other hand increases,

62 56 Figure 7.5: Packet Size Effect on BER and Bit Errors Per Packet due to the overall increased data rate. It has been concluded that the changing BER and BE/P has a positive effect up until a critical point where the BER increase becomes to great and the system performance declines. The final decline would also be seen when interference is not present due to the data rate increasing too high but it must be noted that the decline happens at a larger packet size when interference is present. 7.3 Interference Effects on Multi-Patient WBSN Now that the interference model has been created and it s results verified it can be modeled in the WBSN presented in Chapter 6. To do this a trajectory was created to model a doctor walking around the hospital room. The trajectories created were random in nature but were saved and reused for comparability. This was done to model the effects of a personal digital assistant (PDA) or laptop that the doctor might be carrying. The application data throughput for the HTTP application is seen in Figure 7.6. The simulations were limited to 24 interference nodes as this is in excess of what would be present in reality and still allows us to investigate the effect of increased interference nodes. The effect on the interference is much more dramatic for the non-critical data when looking at the overall application data throughput. The critical application data only drops to 99.6% when there is 24 HTTP

63 57 Figure 7.6: Throughput with HTTP Interference interference nodes whereas the non-critical data only has a throughput of 13.9%. The interference nodes are causing collisions for both types of data although the restrnamissions are still allowing successful data delivery of critical data. This has an effect on the end-toend delay, seen in Figure 7.7. The increasing retransmissions are leading to an increase in delay for the critical data as the number of interference nodes increases. The non-critical data only has an increase in 2.7ms which is due to an increase in MAC delay. It must be noted that while the critical data delay does increase it does not reach an unacceptable level. The interference has a greater effect on the non-critical data throughput. The results for the application have the same curve shape as for HTTP although it s overall effect on the network is less with non-critical data throughput dropping to 55.6% and delay of critical data rising to 87.9ms for 24 interference nodes. The critical data throughput and non-critical data remain unchanged as for the HTTP application. When the FTP and video application were introduced the network fails to function at all. The interference effect of these nodes anywhere in the room is enough to stop all data transfer. The introduction of these interference nodes degrades the channel to an extent where the majority of data is dropped due to PAN formation errors. Because of this the critical and non-critical sensors only transmit on average 23 and 2 b/s respectively for the FTP application and all of this data experiences collisions. When the video application is present the WBSN only gets half

64 58 Figure 7.7: End-To-End with HTTP Interference that amount of data onto the medium and it too experience 100% collisions. As can be seen WLAN applications that mt be present in a hospital environment have the ability to have a degrading effect on an IEEE WBSN. The WBSN design has been proved to provides higher QoS for critical data in low interference environments. However for high interference environments the WBSN design completely fails. It is therefore advised that IEEE and IEEE b be operated at different non-overlapping channels although more research is needed to investigate non-perfect PSD of WLAN and Zigbee devices. Overall the WBSN designed in this report can handle a low level of interference but not for a prolonged period of time as the non-critical data is still affected.

65 Chapter 8 Modeling MICS and WMTS Services Using Zigbee and WLAN for medical data collection is not an ideal solution as they do not comply with the medical standards due to their size, power consumption and interference from other sources [46]. It is for this reason the Medical Implant Communication Service (MICS) and Wireless Medical Telemetry Service (WMTS) were defined. The Zigbee modules have been edited to allow IEEE to operate using these two services. [16] stated that this was not possible as the source code of the network layer is withheld, this is incorrect as the PHY layer defines the frequency range and the MAC defines channel indexing processes. The network layer does decide what specific channel to transmit on out of the available channels defined by the lower layers. A brief introduction to the two services is given below. 8.1 Medical Implant Communication Service (MICS) MICS is an ultra low power, unlicensed radio service that uses miniaturised electronics that can operate as an implanted device or externally. Examples of applications include cardiac pacemakers, defibrillators and hearing aids [46]. In addition to interference from other sources being less of an issue, the frequency band of operation has propagation characteristics conductive to the transmission of radio signals within the human body [9]. The 59

66 60 characteristics of MICS are seen in Table 8.1. This frequency range and bandwidth allows Frequency Bandwidth Transmit Range (MHz) (MHz) Power (dbm) (m) MICS Table 8.1: MICS Technical Specifications for 10 non overlapping channels. 8.2 Wireless Medical Telemetry Service (WMTS) WMTS is another service for data collection in medical applications but is used for nonimplantable devices and has a longer distance range [9]. Table 8.2 presents some technical specifications regarding the channel. The channel spacing within these bands is 25kHz Frequency Bandwidth Transmit Range (MHz) (khz) Power (dbm) (m) Band or 50 Band > 1.8 and Band Table 8.2: WMTS Technical Specifications but can support 50 khz channels which are implemented in the larger band with 6 MHz bandwidth. In [39] MICS was used for the short range communication and WMTS was then used for the longer range communication, for this reason both services were implemented in OPNET. 8.3 OPNET Implementation Parameters Used The MICS and WMTS implementations are based on the prototype developed in [39] and uses the values from Tables 8.2, 8.1 and 8.3. It must be noted that both MICS and WMTS can transmit in excess of the data rates presented in Table 8.3 but the OPNET implementation has been designed to model the specific transceiver type used in [39]. This is also

67 61 MICS WMTS Data rate (kb/s) Modulation BPSK FSK Transceiver AMIS Chipcon CC1010 Table 8.3: MICS and WMTS Implementation Specifications true for the modulation used. The AMIS actually uses ASK modulation but this is currently not available in OPNET so BPSK was used as a substitute. Procedure To implement IEEE using the MICS and WMTS services the existing Zigbee modules in OPNET were edited. file and MAC process model code. This included changes to both IEEE header Both services were implemented separately, so that all three transmission bands could be implemented for WMTS, and they were also both implemented on the same node along with Zigbee (so that either MICS, WMTS or Zigbee can be implemented on the one device by enabling that channel). All the edited code is presented in Appendix D while Table 8.4 shows the breakdown of which files implement which services. MICS.h WMTS.h Dual.h (WMTS, MICS and Zigbee) WMTS MHz No Yes Yes MHz No Yes No MHz No Yes No MICS MHz Yes No Yes Zigbee 2.4 GHz No No Yes Table 8.4: WMTS, MICS and Zigbee Implementations in OPNET Header File The IEEE header file was changed to allow transmission over the desired frequency bands, with the relevant data rate and bandwidths. Since different WMTS channels were

68 62 implemented with different bandwidths extra bandwidth definitions had to be declared. These steps are summarised as: Edit data rate definitions Edit frequency definitions Edit bandwidth definition Create extra bandwidth definitions Rename definitions Process Model The process model was then changed to support our new services, these changes are Rename constants changed in header file Edit channel indexing code to support desired channel spacing and channel numbers Change modulation specification Change symbol rate calculation Insert code to print channel centre frequency The channel indexing code specifies the channel separation within a frequency band. Each channel is scanned for beacons and then this information is passed to the network layer which makes a decision on which channel to use. Since the network layer source code is withheld it is not possible to specify which channel will be used. The default in OPNET seems to be to use the last available channel in each frequency band. The last step in the list above is optional and is used to easily verify correct frequency specifications.

69 Chapter 9 Conclusion and Future Work 9.1 Conclusion This report has successfully designed and simulated a multi-hop, multi-patient WBSN that can support a maximum of six patients. Due to topological and power requirements the design has an excessive BER largely due to the hidden terminal problem. For this reason the report finds the non-beaconed version of IEEE unsuitable for a WBSN in a medical environment. It is recommended to use a RTS/CTS handshake or possibly the beaconed version of the protocol to reduce these collisions. It was found that using a different standard with a greater data rate as the network backbone freed up resources significantly. The effects of reducing the Minimum Backoff Exponent were found to produce an improvement in the throughput and delay of critical data. This improvement was found to be limited due to the high BER that caused the backoff exponent to quickly increase to it s maximum value. When collision avoidance was disabled there was an increase in collisions that degraded network performance. It was found that enabling ACKs only on critical data reduced to total overhead on the system while maintaining reliable critical data transfer. This project was successful in the design and construction of an interference model that accurately models various WLAN application data. This was used to model WLAN interference on the WBSN design. It was found that the design has sufficient QoS considerations to handle low interference levels. However this report recommends using different, non overlapping channels as some WLAN applications were found to completely 63

70 64 prevent IEEE transmissions. It was also found that in an interference effected environment reducing packet length increases throughput, although this effect was limited as the data rate increased. This project edited the existing IEEE source code to successfully implement IEEE using the WMTS and MICS services. The changes included modification of data rate, frequency, bandwidth, modulation, symbol rate and channel indexing and separation code. 9.2 Future Work This report has continued on from the work presented in [16] and has provided the contribution outlined above. However there is still a lot of research and design to be done before a final simulation model is complete. What follows is a discussion of possible future work in the field. To reduce the BER it might be an advantage to implement a RTS/CTS handshake. This will completely eliminate collisions caused from the hidden terminal problem. This could also be achieved using the GST mechanism in the beaconed enabled version of the protocol. Re-simulation of the results presented here using one of these two methods is predicted to reduce collisions. The interference results presented here offer a solid base for understanding interference effects although some improvements are necessary. A model is needed that accurately models a real (imperfect) PSD. This is one that has the highest power at the centre frequency and also with power leakage outside of the defined frequency range. This would show the real effects of adjacent channel operation, which in this report was found to have no effect. Battery consumption is a critical factor to a WBSN. It is for that reason that a model for power consumption and battery life would be useful. This will give a understanding of how different network parameters and protocols will affect a hardware prototype. The implementation of the MICS and WMTS services is a step forward in the simulation of a WBSN that fully adheres to the medical standards. The next step is to be able to connect a MICS device to a WMTS device. This would enable the short distance MICS (embedded data collection) to be connected to a WMTS backbone (data transfer and storage). To do this a hybrid device would need to be created that can receive MICS and transmit using WMTS, and vice versa depending on the specific application.

71 Appendix A Beacon-Enabled Mode and CSMA/CA Algorithms This project relates to the non-beaconed mode of IEEE , which uses the unslotted version of CSMA/CA. This is what the current version of OPNET supports. In reality a WBSN is more suited to the beacon-enabled version and for this reason a brief summary the the beacon-enabled mode is given below. Future versions of OPNET will support this version and [12] has designed and implemented their own model using OPNET. A.1 Beacon-Enabled Mode In beacon-enabled mode the coordinator node broadcasts beacons periodically to synchronise all associated devices [14]. Below is a discussion on the beacon-enabled mode of IEEE , including the superframe structure, Guaranteed Time Slot (GTS), data transfer and slotted CSMA/CA. Superframe Structure The coordinator node of each star network using beaconed-mode uses the frame in Figure A.1 to control channel access and data transmission [1]. The following points are true about the superframe structure in Figure A.1: Every superframe is the same length [1]. 65

72 66 Figure A.1: Superframe Structure of IEEE The start of the superframe is a beacon packet [1]. The beacon packet includes the superframe specification, which identifies the lengths of each component of the superframe [1]. The superframe is divided into an active and an inactive period. In the optional inactive period the devices can sleep to conserve power [22]. They must wake before the beacon that starts the next active period. The active period is subdivided into 16 time slots, the first of which is occupied by the beacon [1]. The remainder of the active period is partitioned into a Contention Access Period (CAP) and Guaranteed Time Slots (GTS) [1]. The lengths of the active and inactive periods, individual time slots, CAP and GTS are all configurable [1]. The coordinator node is active in the entire active period [1]. The devices are active in the GTSs allocated to them and are inactive or sleeping for the GTSs not allocated to them [1]. It can be seen that the devices do little work when compared to the coordinator node. This shows that the beacon-enabled version is optimised for applications where the sensor devices are energy-constrained [1].

73 67 Data Transfer Procedure GTS Management During the CAP devices send request packets to the coordinator node if they have data to send or receive. The coordinator node then responds by allocating a GTS to that device. The device s request packet identifies whether it s a read or receive request and the number of contiguous GTS needed. The coordinator node replies with an immediate ACK packet and later when enough resources are available to be allocated it sends a GTS descriptor in the next beacon frame [1]. The device will continue to use this GTS until it is specifically de-allocated by either the coordinator node or by itself. [1]. Data Transfer When a device wants to transmit to it s coordinator node, assuming it has already been allocated a GTS, it wakes just before its GTS starts. It immediately sends the packet without running any CSMA/CA. A similar procedure happens when the coordinator node needs to send data to the device. This scenario of the handshake between coordinator and device when the node receives a packet is outlined below: The coordinator adds the devices address to the pending address field of the beacon [1]. The devices sees it address in the beacon and sends a data request to the coordinator node during the CAP [1]. The coordinator acknowledges the device s data request with an ACK [1]. The device receives the ACK and prepares to receive data The coordinator node sends the data The device receives the data, sends an ACK and then sleeps until the next beacon [1].

74 68 Slotted CSMA/CA When nodes need to send control packets in the CAP they use slotted CSMA/CA. This is a contention based protocol where a possible opportunity to transmit can be acted upon by multiple devices [1]. The behaviour of slotted CSMA/CA is determined by three parameters. These are, Backoff Exponent (BE), Initial value of the Congestion Window (CW) and the Maximum number of Backoffs (NB). The actual process of slotted CSMA/CA and its relation to the previous parameter are listed below and can be seen in Figure A.2 adapted from [11]. The variables NB, BE and CW are initiated with NB is set to zero, BE is set to macminbe and CW is set to 2 [11]. macminbe is a protocol parameter in the range [0, 3] which is user defined with a default of 3. BE can have a value between macminbe and amaxbe (5). NB is user defined in the range [0, 5] with a default of 4. The number of delay backoff periods is found randomly from the interval [0, 2 BE 1]. A CCA is performed at defined backoff period boundaries after the delay to sense if the channel is busy [11]. If the channel is sensed as idle CW is decremented. If CW is zero a packed is transmitted, if it is not zero another CCA is performed at the next backoff boundary. If the channel is sensed to be busy, NB and BE are both incremented with CW set back to it s initial value [11]. If NB is below it s maximum value it recalculates a new delay period. reaches it s maximum value a transmission failure is reported [11]. When NB The effect of CW means that devices have to sense an idle medium twice before transmission, this parameter is not used in the unslotted version.

75 69 A.2 Slotted CSMA/CA Figure A.2: Slotted CSMA/CA Algorithm

76 70 A.3 Unslotted CSMA/CA Figure A.3: Unslotted CSMA/CA Algorithm

77 Appendix B Simulation Results B.1 Original Design Results Parameter Value Parameter Value Sensor MAC Delay 67.4 ms PCU BER PCU MAC Delay 37.9 ms CCU BER CCU MAC Delay 74.1 ms DB BER Sensor 1 Queuing Delay 40.6 ms PAN Formation Data Lost 20.7 kb/s PCU Queuing Delay 24.4 ms ACK Threshold Data Lost 1.2 kb/s CCU Queuing Delay 74.1 ms Application Data Throughput 53.3% End-To-End Delay ms Goodput 33.1% Table B.1: Six Patient WBSN Design Simulation Results 71

78 72 B.2 Improved Design Results WLAN/Wired Backbone Results Measurement WLAN/Wired Improvement Backbone End-to end Delay (ms) % PCU MAC Delay (ms) % PCU Queuing Delay (ms) % PAN Formation Data Lost (kb/s) % Throughput 75.0% 21.7% Goodput 65.0% 33.9% ACK Threshold % Data Lost (kb/s) Table B.2: WLAN Backbone Simulation Results ACK Mechanism Results Measurement ACKs Only Critical ACKs Enabled Data ACKs Enabled Disabled Critical Patient Data End-to end Delay (ms) Throughput (%) Non-Critical Patient Data End-to end Delay (ms) Throughput (%) Table B.3: ACK Mechanism Simulation Results

79 73 Combined Results Parameter Critical Data Non-Critical Data Value Improvement Value Improvement Sensor MAC % % Delay (ms) PCU MAC % % Delay (ms) Sensor 1 Queuing % 0 100% Delay (ms) PCU Queuing % % Delay (ms) End-To-End % % Delay (ms) PCU BER % % Application Data % % Throughput (%) Table B.4: Improved WBSN Critical and Non-Critical Data Simulation Results Global Final Improvement Parameter Design CCU BER % Goodput (%) % PAN Formation 0 100% Data Lost (kb/s) ACK Threshold 0 100% Data Lost (kb/s) Table B.5: Improved WBSN Global Results

80 Appendix C Wireless Transmission of Data in OPNET C.1 Radio Transceiver Pipeline To model wireless transmission of data OPNET uses the Radio Transceiver Pipeline, which is a set of sequential stages that determine how to process received radio data. A separate pipeline is needed for each receiver in a wireless network. This is because radio waves access the medium with broadcasts and every transmission can have an effect at multiple receivers. The Radio Transceiver Pipeline has 14 stages, seen in Figure C.2. It is important to have a good understanding of this pipeline to be ale to understand how Zigbee will handle interference from outside sources. Figure C.2 is the pipeline process as a whole but it must be noted that stages 0-5 are implemented at the radio transmitter and stages 6-13 implemented at the receiver. Stages 9, 10, 11 and 12 can be executed multiple times for each receiver, this might need to be done because of the possibility of interactions with multiple concurrent transmissions from other sources [41]. Basically the pipeline is used to classify arriving packets, as valid, invalid or noise, and process them accordingly. Stage 0: Receiver Group This stage determines each transmitter channel s initial receiver group and is specified by the rxgroup model attribute in the transmitter node model. The receiver group lists 74

81 75 the possible receivers for each transmitter. Due to the dynamic nature of simulations the receiver group stage includes a receiver channel unless it can be determined in advance that a receiver channel will never be a match for that transmitter. If a receiver is in a transmitter s receiver group is can be disqualified during a simulation due to frequency/bandwidth mismatch, physical separation or directional antenna issues. Stage 1: Transmission Delay This stage calculates the amount of time taken for the packet to complete transmission and is specified by the txdel model attribute in the transmitter node model. This result is the simulation time difference between the beginning of transmission of the first bit and the end of transmission of the last bit of each packet [41]. This stage is the first stage to get run for every new transmission and this result is used to create an end of transmission trigger where the transmitter can transmit the next packet or if no packets are available the medium becomes idle. Stage 2: Link Closure This stage determines if a receiver can be affected by the transmission and is specified by the closure model attribute in the transmitter node model. This stage is run once for each receiver in the transmitter s receiver group and if the transmission is capable of reaching the receiver it is called a link closure. A link closure is based on physical conditions and signal levels and does not take into account whether the signal is valid for the receiver. This means that interference signals can and will cause a link closure. When considering link closures a propagation model is used that considers things like path-loss and terrain modeling. Stage 3: Channel Match This stage labels the transmission in regards to validity to the receiver and is specified by the chanmatch model attribute in the transmitter node model. This stage is run once for each successful link closure and can apply one of three possible labels to each packet: Valid: These packets are compatible with the receiver. This decision is based on frequency, bandwidth, data rate, spreading code and modulation.

82 76 Noise: These packets are not compatible with the receiver but can have an impact on the receiver s performance (i.e. interference). This decision is based on incompatibilities of the parameters listed in the previous point. Ignored: These packets have no effect on a receiver s performance. The pipeline will be discontinued. Stage 4: Tx Antenna Gain This stage calculates the gain provided by the transmitters antenna and is specified by the tagain model attribute in the transmitter node model. This stage is run separately for each channel that is labeled as either valid or noise from the previous stage and the result is commonly used at Stage 7 for the received power calculation. Stage 5: Propagation Delay This stage calculates the time needed for the packet to travel from the transmitter to the receiver and is specified by the propdel model attribute in the transmitter node model. This is used to create a beginning of reception trigger for the receiver and also used in conjunction with the result from Stage 1 to calculate the time that the packet completes reception [41]. Stage 6: Rx Antenna Gain This stage calculates the the gain provided by the receivers antenna and is specified by the ragain model attribute in the receiver node model. This stage is comparable to the Tx Antenna Gain stage and the result is also used at Stage 7 to calculate received power. Stage 7: Received Power This stage calculates the received power of the arriving packets signal and is specified by the power model attribute in the receiver node model. For valid packets this is an important factor for the receiver to be able to decode information in the packet. For noise packets the received power is used for SNR calculations. The received power calculations are based on transmitter power, distance, frequency and antenna gains.

83 77 Stage 8: Background Noise This stage represents all noise sources except for concurrent arriving interference noise and is specified by the bkgnoise model attribute in the receiver node model. The result is a sum of powers from all other noise sources. These source could be things such as ambient noise level, constant source of background noise, and constant thermal noise at the receiver. Since we are concerned with the interference effect on Zigbee the following values relate to Zigbee. This model, used by Zigbee, defines the background noise and in-band ambient noise as: N bkg = (T Rx + T bkg ) B BW rx N ambient = N level BW rx (C.1) (C.2) Where: T Rx is the Receiver Temperature T bkg is the Background Temperature (290 K) BW rx is Receiver Bandwidth (2 MHz) B is Boltzmann Constant (1.379e 23 J/K) N level is the Ambient Noise Level (1e 26 W) The effective receiver temperature is given by: T Rx = (NF 1) T bkg (C.3) Where: NF is the Noise Figure (1) For the Zigbee modules the the following results are used by default: N bkg = e 15 W N ambient = 2e 20 W (C.4) (C.5) Therefore: N bkg + N ambient = e 15 W (C.6)

84 78 Stage 9: Interference Noise This stage accounts for the interactions between concurrently arriving transmissions at the same receiver and is specified by the inoise model attribute in the receiver node model. This stage will be run when a valid packet arrives at its destination while a second packet is already being received or when a valid packet is being received when a second packet, valid or invalid arrives. The level of all noise from interference sources is recorded with the power of successfully received valid or invalid packets subtracted from this. The power of successfully received invalid packets is dealt with in the next section. Stage 10: Signal-To-Noise Ratio This stage calculates the current SNR for the arriving packet and is specified by the snr model attribute in the receiver node model. SNR is a network performance measure that measures the receivers ability to correctly decode the packets content. This stage is run when a valid packet arrives at its destination channel, when a second packet arrives while the valid packet is being received or when a second packet completes reception while the valid packet is being received. The SNR calculation is based on received power, background noise and interference noise: SNR = P signal P signal P noise = P bkg noise + P intf noise P signal SNR(dB) = 10log 10 P bkg noise + P intf noise Where: P signal is the signal power calculated in Stage 7 P bkg noise is the background noise calculated in Stage 8 P intf noise is the interference noise calculated in Stage 9 (C.7) (C.8) (C.9) Stage 11: Bit Error Rate This stage derives the probability of bit errors using the SNR and modulation type used for transmission and is specified by the ber model attribute in the receiver node model. This stage is run when a valid packet completes reception at it s destination channel, when a

85 79 valid packet is already being received and another packet (valid or invalid) arrives or when a valid packet is already being received and another packet (valid or invalid) completes reception. This stage uses the SNR calculation from Stage 10 and the modulation type to calculate the BER. The modulation used in Zigbee is Quadrature Phase Shift Keying (QPSK) whose BER curve is seen in Figure C.1. Figure C.1: QPSK BER Curve [35] Stage 12: Error Allocation This stage estimates the number of bit errors in a packet segment based on the bit error probability from the previous section and is specified by the error model attribute of the receiver node model. It also records the empirical bit error rate.

86 80 Stage 13: Error Correction This stage determines whether the arriving packet can be accepted and forwarded to higher layers and is specified by the ecc model attribute of the receiver node model. Weather the packet can be forwarded or not depends on if the packet has experienced collisions, the result calculated in the error allocation stage, and the effect of error correction. This stage is run when a valid packet completes reception. Based on these results of this stage the packet is either forwarded or destroyed.

87 81 C.2 Graphical Radio Transceiver Pipeline Stages Figure C.2: Radio Transceiver Pipeline Stages

88 82 C.3 Standard Specific Pipeline Stages Stage Number Stage Name WLAN Model Zigbee Model Transmitter Stages 0 Receiver Group wlan rxgroup dra rxgroup 1 Transmission Delay wlan txdel dra txdel 2 Link Closure dra closure dra closure 3 Channel Match wlan chanmatch dra chanmatch 4 Tx Antenna Gain none dra tagain 5 Propagation Delay wlan propdel dra propdel Receiver Stages 6 Rx Antenna Gain none dra ragain 7 Received Power wlan power Zigbee dra power 8 Background Noise dra bkgnoise dra bkgnoise 9 Interference Noise wlan inoise dra inoise 10 Signal-To-Noise Ratio dra snr dra snr 11 Bit Error Rate wlan ber dra ber 12 Error Allocation wlan error dra error 13 Error Correction wlan ecc dra ecc Table C.1: WLAN and Zigbee Default Pipeline Stages

89 Appendix D MICS and WMTS Implementation Code D.1 Dual Implementation Code This code implements WMTS, MICS and Zigbee all on the one device. The desired standard is specified in the node attributes. Header File Modifications This code replace lines of the Header File ( h) /* ZigBee, WMTS and MICS physical layer constants. */ /* WMTS and MICS can have a data rate in excess of 250 kb/s */ /* It is limited here due to chip data rate */ #define WPANC_MICS_BAND_DRATE #define WPANC_WMTS_BAND_DRATE #define WPANC_Zigbee_BAND_DRATE #define WPANC_MICS_BAND_FREQ #define WPANC_WMTS_BAND_FREQ #define WPANC_Zigbee_BAND_FREQ 2405 #define WPANC_Zigbee_BANDWIDTH 2 #define WPANC_MICS_BANDWIDTH

90 84 #define WPANC_WMTS_BANDWIDTH 0.05 #define WPANC_Zigbee_BAND 1 #define WPANC_WMTS_BAND 2 #define WPANC_MICS_BAND 3 Process Model Modifications This code replaces lines of the Function Block for the MAC layer ( mac.pr.m). /*MICS*/ for (index = 1; index < 11; index++){ channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle, sizeof (WPAN_Channel_Info)); channel_center_frequency = WPANC_MICS_BAND_FREQ + 0.3*(index-1); channel_info_ptr->min_frequency = channel_center_frequency - WPANC_MICS_BANDWIDTH/2.0 ; if (data_rate == -1) channel_info_ptr->drate = WPANC_MICS_BAND_DRATE; else channel_info_ptr->drate = data_rate; channel_info_ptr->tx_band = WPANC_WMTS_BAND; op_prg_list_insert (channel_info_lptr, channel_info_ptr, OPC_LISTPOS_TAIL); } printf("\n The MICS center frequency is: %5.4f\n", channel_center_frequency); /*WMTS*/ for (index = 2242; index < 2479; index = index + 2){ channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle, sizeof (WPAN_Channel_Info)); channel_center_frequency = WPANC_WMTS_BAND_FREQ *(index-2242); channel_info_ptr->min_frequency =

91 85 channel_center_frequency - WPANC_WMTS_BANDWIDTH/2.0 ; if (data_rate == -1) channel_info_ptr->drate = WPANC_WMTS_BAND_DRATE; else channel_info_ptr->drate = data_rate; channel_info_ptr->tx_band = WPANC_WMTS_BAND; op_prg_list_insert (channel_info_lptr, channel_info_ptr, OPC_LISTPOS_TAIL);} printf("\n The WMTS center frequency is: %5.4f\n", channel_center_frequency); /*Zigbee*/ for (index = 11; index < 27; index++){ channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle, sizeof (WPAN_Channel_Info)); channel_center_frequency = WPANC_Zigbee_BAND_FREQ + 5*(index-11); channel_info_ptr->min_frequency = channel_center_frequency - WPANC_Zigbee_BANDWIDTH/2.0 ; if (data_rate == -1) channel_info_ptr->drate = WPANC_Zigbee_BAND_DRATE; else channel_info_ptr->drate = data_rate; channel_info_ptr->tx_band = WPANC_Zigbee_BAND; op_prg_list_insert (channel_info_lptr, channel_info_ptr, OPC_LISTPOS_TAIL);} printf("\n The Zigbee center frequency is: %5.4f\n", channel_center_frequency); This code replaces lines of the Function Block for the MAC layer ( mac.pr.m). /* Also update the module wide memory with appropriate symbol rate. */ if (channel_info_ptr->tx_band == WPANC_WMTS_BAND channel_info_ptr->tx_band == WPANC_MICS_BAND)

92 86 modmem_ptr->symbol_rate = channel_info_ptr->drate; else modmem_ptr->symbol_rate = 0.25* (channel_info_ptr->drate); drate_sv = channel_info_ptr->drate; This code replaces lines of the Function Block for the MAC layer ( mac.pr.m). /* Set the modulation scheme appropriately */ if (channel_info_ptr->tx_band == WPANC_Zigbee_BAND){ op_ima_obj_attr_set (tx_objid, "modulation", "qpsk"); op_ima_obj_attr_set (rcvr_objid, "modulation", "qpsk");} else if(channel_info_ptr->tx_band == WPANC_MICS_BAND){ /* Set modulation to BPSK when using MICS */ op_ima_obj_attr_set (tx_objid, "modulation", "bpsk"); op_ima_obj_attr_set (rcvr_objid, "modulation", "bpsk");} else { /* Set modulation to FSK whenusing WMTS*/ op_ima_obj_attr_set (tx_objid, "modulation", "fsk2"); op_ima_obj_attr_set (rcvr_objid, "modulation", "fsk2");} D.2 WMTS Implementation Code This code implements all three available bands of WMTS. WMTS Header File Modifications This code replace lines of the Header File ( h) /* WMTS physical layer constants. */ /* WMTS can use a bandwidth greater than 250 kb/s. */ /* Data rate given here are specific of chips used */ #define WPANC_WMTS1_BAND_DRATE #define WPANC_WMTS2_BAND_DRATE 76000

93 87 #define WPANC_WMTS3_BAND_DRATE /* Mhz, BW = 6 MHz */ #define WPANC_WMTS1_BAND_FREQ /* MHz, BW = 5 MHz */ #define WPANC_WMTS3_BAND_FREQ /* MHz, BW = 5 MHz */ #define WPANC_WMTS2_BAND_FREQ /*Band 1 BW 50 khz */ #define WPANC_WMTS1_BANDWIDTH 0.05 /*Band 2 BW 25kHz */ #define WPANC_WMTS3_BANDWIDTH /*Band 3 BW 25kHz */ #define WPANC_WMTS2_BANDWIDTH #define WPANC_WMTS1_BAND 1 #define WPANC_WMTS2_BAND 2 #define WPANC_WMTS3_BAND 3 WMTS Process Model Modifications This code replaces lines of the Function Block for the MAC layer ( mac.pr.m). /* For each enabled band allocate the memory associated with its channel and populate the channels. */ /* WMTS 3 ( MHz) */ for (index = 33721; index < 33921; index++){ channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle, sizeof (WPAN_Channel_Info)); channel_center_frequency = WPANC_WMTS3_BAND_FREQ *(index-33721); channel_info_ptr->min_frequency = channel_center_frequency - WPANC_WMTS3_BANDWIDTH/2.0 ; if (data_rate == -1) channel_info_ptr->drate = WPANC_WMTS3_BAND_DRATE;

94 88 else channel_info_ptr->drate = data_rate; channel_info_ptr->tx_band = WPANC_WMTS3_BAND; op_prg_list_insert (channel_info_lptr, channel_info_ptr, OPC_LISTPOS_TAIL);} printf("\n The centre frequency is: %5.4f\n", channel_center_frequency); /* WMTS 2 ( MHz) */ for (index = 35005; index < 35205; index++){ channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle, sizeof (WPAN_Channel_Info)); channel_center_frequency = WPANC_WMTS2_BAND_FREQ *(index-35005); channel_info_ptr->min_frequency = channel_center_frequency - WPANC_WMTS2_BANDWIDTH/2.0 ; if (data_rate == -1) channel_info_ptr->drate = WPANC_WMTS2_BAND_DRATE; else channel_info_ptr->drate = data_rate; channel_info_ptr->tx_band = WPANC_WMTS2_BAND; op_prg_list_insert (channel_info_lptr, channel_info_ptr, OPC_LISTPOS_TAIL);} printf("\n The centre frequency is: %5.4f\n", channel_center_frequency); /* WMTS 1 ( MHz) */ for (index = 2242; index < 2479; index = index + 2) /*Double indexing due to the increased channel BW*/{ channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle, sizeof (WPAN_Channel_Info)); channel_center_frequency = WPANC_WMTS1_BAND_FREQ *(index-2242); channel_info_ptr->min_frequency = channel_center_frequency - WPANC_WMTS1_BANDWIDTH/2.0 ; if (data_rate == -1) channel_info_ptr->drate = WPANC_WMTS1_BAND_DRATE;

95 89 else channel_info_ptr->drate = data_rate; channel_info_ptr->tx_band = WPANC_WMTS1_BAND; op_prg_list_insert (channel_info_lptr, channel_info_ptr, OPC_LISTPOS_TAIL);} printf("\n The centre frequency is: %5.4f\n", channel_center_frequency); This code replaces lines of the Function Block for the MAC layer ( mac.pr.m). /* Also update the module wide memory with appropriate symbol rate. */ /* For FSK the symbol rate is equal to the data rate */ modmem_ptr->symbol_rate = channel_info_ptr->drate; drate_sv = channel_info_ptr->drate; This code replaces lines of the Function Block for the MAC layer ( mac.pr.m). /* Set the modulation scheme to FSK independent of what band is transmitting */ op_ima_obj_attr_set (tx_objid, "modulation", "fsk2"); op_ima_obj_attr_set (rcvr_objid, "modulation", "fsk2"); D.3 MICS Implementation Code This code implements the one MICS band. MICS Header File Modifications This code replace lines of the Header File ( h) /* WMTS physical layer constants. */ /* MICS data rate can exceed 250 kb/s */ /* It is limited here due to the AMIS IC */ #define WPANC_MICS1_BAND_DRATE 16000

96 90 #define WPANC_MICS2_BAND_DRATE #define WPANC_MICS3_BAND_DRATE /* MCIS ( MHz) */ #define WPANC_MICS1_BAND_FREQ #define WPANC_MICS2_BAND_FREQ #define WPANC_MICS3_BAND_FREQ /* MCIS BW 300 Hz */ #define WPANC_BANDWIDTH 0.3 #define WPANC_MICS1_BAND 1 #define WPANC_MICS2_BAND 2 #define WPANC_MICS3_BAND 3 MICS Process Model Modifications This code replaces lines of the Function Block for the MAC layer ( mac.pr.m). /* For each enabled band allocate the memory associated with its channel and populate the channels. */ /*MICS Band 1 */ for (index = 1; index < 4; index++){ channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle, sizeof (WPAN_Channel_Info)); channel_center_frequency = WPANC_MICS1_BAND_FREQ + 0.3*(index-1); channel_info_ptr->min_frequency = channel_center_frequency - WPANC_BANDWIDTH/2.0 ; if (data_rate == -1) channel_info_ptr->drate = WPANC_MICS1_BAND_DRATE; else channel_info_ptr->drate = data_rate; channel_info_ptr->tx_band = WPANC_MICS1_BAND; op_prg_list_insert (channel_info_lptr, channel_info_ptr, OPC_LISTPOS_TAIL);}

97 91 printf("\n The centre frequency is: %5.4f\n", channel_center_frequency); /*MICS Band 2 */ for (index = 4; index < 7; index++){ channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle, sizeof (WPAN_Channel_Info)); channel_center_frequency = WPANC_MICS3_BAND_FREQ + 0.3*(index - 4); channel_info_ptr->min_frequency = channel_center_frequency - WPANC_BANDWIDTH/2.0 ; if (data_rate == -1) channel_info_ptr->drate = WPANC_MICS3_BAND_DRATE; else channel_info_ptr->drate = data_rate; channel_info_ptr->tx_band = WPANC_MICS3_BAND; op_prg_list_insert (channel_info_lptr, channel_info_ptr, OPC_LISTPOS_TAIL);} printf("\n The centre frequency is: %5.4f\n", channel_center_frequency); /*MICS Band 3*/ for (index = 7; index < 11; index++){ channel_info_ptr = (WPAN_Channel_Info*) op_prg_cmo_alloc (wpan_cmo_handle, sizeof (WPAN_Channel_Info)); channel_center_frequency = WPANC_MICS2_BAND_FREQ + 0.3*(index-7); channel_info_ptr->min_frequency = channel_center_frequency - WPANC_BANDWIDTH/2.0 ; if (data_rate == -1) channel_info_ptr->drate = WPANC_MICS2_BAND_DRATE; else channel_info_ptr->drate = data_rate; channel_info_ptr->tx_band = WPANC_MICS2_BAND; op_prg_list_insert (channel_info_lptr, channel_info_ptr, OPC_LISTPOS_TAIL);} printf("\n The centre frequency is: %5.4f\n", channel_center_frequency);

98 92 This code replaces lines of the Function Block for the MAC layer ( mac.pr.m). /* Also update the module wide memory with appropriate symbol rate. */ /* For our case the symbol is equal to data rate */ modmem_ptr->symbol_rate = channel_info_ptr->drate; drate_sv = channel_info_ptr->drate; This code replaces lines of the Function Block for the MAC layer ( mac.pr.m). /* Set the modulation to BPSK until ASK becomes available */ op_ima_obj_attr_set (tx_objid, "modulation", "bpsk"); op_ima_obj_attr_set (rcvr_objid, "modulation", "bpsk");

99 Appendix E OPNET Limitations, Constraints and Error Messages This section is provided to assist troubleshooting of similar projects and to to assist in reproducing the results presented in this report. E.1 General Problems Memory <<< Program Fault >>> program abort -- Invalid Memory Access This error is due to the lack of available RAM on the PC running OPNET. Three things can be done to solve problem. The first approach is to edit simulation parameters to reduce the memory needed by the simulation. This isn t a real option in most applications. Another solution is to increase the RAM on the PC. It may also help to close all other applications running on the PC to free up as much RAM as possible. The most viable solution is to change the random seed number used in the simulation. It was found as a general rule that reducing the seed number allowed memory greedy simulations to run successfully. License Issues To execute a simulation, you must contact a license server 93

100 94 with a valid "Simulation Site License" or "Simulation Runtime" license Terminating Simulation. This error is due to the OPNET software not being able to access the license file. This could be due to another instance on OPNET already open on the PC, another PC has used the license while it was not in use or OPNET might not of released the license last time it was used if it terminated abruptly. From the OPNET start window go to License and then License Management to view the status of the license. Restarting OPNET can sometimes solve this problem or restarting the PC if necessary. Simulation Sample Rate It was found that some measurements required a higher sampling rate then other measurements to obtain correct results. This is true of BER and SNR. For example Figure E.1 which shows BER and SNR for a sample rate of 10 and 10M. The 10M samples does not Figure E.1: SNR and BER Measurements for Different Sampling Rates even seem to be enough and the maximum number of samples that can be exported into Excel is approximately This must be considered when taking these statistics. Using the bucket function to collect sample mean results is suggested and not using values or seconds bucket functions.