While our topology planning algorithms are implemented in C++, the communica- tion protocols are implemented in the open-source network simulator ns-2 version 2.33 [2]. Ns-2 is a discrete-event, packet-level network simulator that is widely used for WSN and other network simulations, such as wired, wireless and satellite net- works. In its distribution, it has a large number of libraries and tools for WSN simulations. Ns-2’s main functionality and detailed protocol implementation are written in C++, while the simulation configuration is controlled by Tcl scripts. We will describe the simulation components that we used in the following subsections.
3.4.1
Input and Output
Ns-2 takes as input Tcl scripts and topology files. In the Tcl scripts, we define simulation configurations, including global configurations for nodes (protocol stack, radio propagation model, antenna type, energy model, etc that will be explained in details in the consecutive subsections), a simulation event scheduler to indicate when nodes should start or stop transmitting packets, traffic load, network topology and output files.
To generate static network topologies in a perturbed grid deployment, we implement a topology generator using C++. The two-dimensional network area is divided into grid cells, where one node is placed inside one unit grid square and the coordinates are randomly perturbed. The topology generator produces topology files using ns-2 topology format, where the coordinates of each node in the network are written as the following:
$node (<node id>) set X <x coordinate>
$node (<node id>) set Y <y coordinate>
$node (<node id>) set Z <z coordinate>
All variables are self-explanatory. The topology files are read as input by ns-2 and used to construct the topology to be simulated.
Ns-2 produces trace files as its output to allow packet tracing, where we can get information such as node that sends or receives a packet, time when the action happened, layer where it happened, the remaining energy of the node, etc. We can also generate our personalised trace files to save CPU resources by selecting which parameters to be traced.
3.4.2
Protocol Stack
The five core layers of a sensor node consist of the application layer, transport layer, routing layer, MAC layer and physical layer. At a simulated node, the application layer generates data packets at regular time intervals and passes them down to the transport layer. At the transport layer, a node implements User Datagram Protocol (UDP), where no connection setup is needed prior to data transfer. It adds nothing to the packets and passes them to the routing layer [57]. Our proposed technique, ER-MAC in Chapter 4, has its own forward-to-parent routing mechanism, where every node sends packets to their parent nodes in the routing tree. Therefore, upon reception of a packet, ER-MAC arranges channel access and passes the packet to the physical layer for transmission. Later in the evaluation of ER-MAC, we use Z-MAC [97] as a comparison. Z-MAC does not have any routing policies. So, we implement Shortest Path Tree Routing (STR), which is similar to the routing protocol from Collection Tree Protocol (CTP) [47], at the routing layer. While CTP uses expected transmissions as the cost metric, our implementation of STR uses hop counts. When STR receives a packet, it finds a one-hop neighbour that has the shortest route to the destination. After that, STR passes the packet down to Z-MAC for arranging channel access, and then Z-MAC passes it down to the physical layer for transmission. When a node receives a packet at another side of the transmission, the packet is passed up the stack until received by the application layer.
3.4.3
WirelessPhy Model
Each node has a WirelessPhy interface which represents the hardware interface and the properties of its radio. The interface puts transmission data, such as trans- mitted signal power, into the header of each packet. When a packet is received, the propagation model uses the transmission data to determine whether it has the minimum signal power to be received by the receiving node. If the received sig- nal power is below the receiving threshold RXThresh, the packet will be dropped. This model approximates the Lucent WaveLAN Direct-Sequence Spread-Spectrum (DSSS) radio interface. We can specify the transmission range of a node by setting an appropriate value of the transmitted signal power and the receiving threshold. To get a 10-metre transmission range in ns-2, we set the transmitted signal power
Pt equal to 5.35395e-05 and the receiving threshold RXThresh equal to 3.65262e-
10. While RXThresh is set to ns-2 default value, we use a separate C program, i.e.
threshold.cc, that comes with the ns-2 installation to compute the value of Pt.
The WirelessPhy interface also has a direct access to control the properties of a node’s radio, which can be set to either on or off mode. When the radio is turned off, all received packets are discarded.
3.4.4
Radio Propagation Model
To represents the transmission range of a sensor node as an ideal circle, we select a simple wireless channel using the two-ray ground radio propagation model. The radio propagation model is used to predict the received signal power of each packet. Using a standard model, the received signal power at a distance d is calculated by
Pr(d) =
PtGtGrh2th2r
d4L (1)
Pr(d) is the received signal power given a transmitter-receiver distance,
Pt is the transmitted signal power,
Gt is the antenna gain of the transmitter,
Gr is the antenna gain of the receiver,
ht is the height of the transmit antenna above ground,
hr is the height of the receive antenna above ground,
d is the distance between the transmitter and the receiver, and L is the system loss in the transmit/receive circuitry.
The omni-directional antenna that we use in the simulation can radiate or receive
energy equally well in all directions. It has the following specifications: Gt = Gr =
1, ht= hr = 1.5 metres, and no system loss (L = 1) [116].
3.4.5
Simulation Parameters
We set the transmission power of each sensor node at 0 dBm, where its transmission range in an indoor environment is about 10 metres [119]. Our simulation uses the energy model of the Tmote sky hardware [4]. Tmote sky, which is depicted in Figure 22, is a popular wireless sensor node. Its current consumption for radio transmitting at 0 dBm is 17.4 mA and for radio receiving is 19.7 mA. Tmote uses 2 × AA batteries. Each AA battery is 1.5 Volts and has energy up to 10,000 Joules. Note that we need one joule of energy to produce one watt of power for one second. Our simulation parameters are presented in Table 7. These parameters are used for our ns-2 simulations to evaluate the proposed ER-MAC protocol in Chapter 4 and the network performance of designed topologies in Chapter 8.
Low Power Wireless Sensor Module
Moteiv Corporation Tmote Sky : Datasheet (2/6/2006) Page 1 of 28
Ultra low power IEEE 802.15.4 compliant wireless sensor module
Humidity, Light, and Temperature sensors with USB
Product Description
Tmote Sky is an ultra low power wireless module for use in sensor networks, monitoring applications, and rapid application prototyping. Tmote Sky leverages industry standards like USB and IEEE 802.15.4 to interoperate seamlessly with other devices. By using industry standards, integrating humidity, temperature, and light sensors, and providing flexible interconnection with peripherals, Tmote Sky enables a wide range of mesh network applications.
Tmote Sky is a drop-in replacement for Moteiv’s successful Telos design. Tmote Sky includes increased performance, functionality, and expansion. With TinyOS support out-of-the-box, Tmote leverages emerging wireless protocols and the open source software movement. Tmote Sky is part of a line of modules featuring on-board sensors to increase robustness while decreasing cost and package size.
Key Features
• 250kbps 2.4GHz IEEE 802.15.4 Chipcon Wireless Transceiver • Interoperability with other IEEE 802.15.4 devices
• 8MHz Texas Instruments MSP430 microcontroller (10k RAM, 48k Flash) • Integrated ADC, DAC, Supply Voltage Supervisor, and DMA Controller • Integrated onboard antenna with 50m range indoors / 125m range outdoors • Integrated Humidity, Temperature, and Light sensors
• Ultra low current consumption • Fast wakeup from sleep (<6μs)
• Hardware link-layer encryption and authentication • Programming and data collection via USB
• 16-pin expansion support and optional SMA antenna connector • TinyOS support : mesh networking and communication implementation • Complies with FCC Part 15 and Industry Canada regulations
Figure 22: Tmote sky [4]
Table 7: Simulation parameters in ns-2
Simulation parameters Default value
Transmission range 10 m
Transmit power (txPower) 17.4 mA × 3 V = 52.2 mW Receive power (rxPower) 19.7 mA × 3 V = 59.1 mW
Idle power 19.7 mA × 3 V = 59.1 mW
Sleep power 1 µA × 3 V = 3 µW
Transition power 19.7 mA × 3 V = 59.1 mW
Transition time 580 µs
Node initial energy 20,000 J (2 × AA batteries)