Java-based simulator for wireless multihop networks using directional antennas Ghadi Rayess, Ioannis Tsirilakis, Antonis Kalis (
[email protected],
[email protected],
[email protected])
Athens Information Technology 19.5Km Markopoulo Ave., 19002, Athens, Greece. appropriate simulator. Recently, there has been some advancement in such tools, with the development of JSIM [2], TOSSIM [3] and NS-2. The last, open source tool represents the most popular solution for large wired networks. With the CMU’s Monarch extensions, it has also covered the wireless domain [4]; however, little work has been done for sensor networks. It is known that the implemented in ns-2 protocols are in many cases not suitable for use in sensor topologies. The latter, for example, require more light-weight MAC protocols than the heavy 802.11 widely accepted for generic ad hoc networks. Apart from that, functional components like directional antennas are not included in ns-2 and should be plugged in, taking under consideration all code-block interdependencies of the tool. Since we wanted also to test our own MAC and IP protocols, it was clear that most of the code should be written from scratch. Hence, creating the whole software from the beginning and including only the relevant to sensor networks operations, led to a faster and more reliable development. The remainder of the paper is organized as follows. Section 2 briefly describes the simulator’s architecture providing for a guideline to any external user. In section 3 we discuss the physical model assumed in all simulations and how the directive gain of each sensor is calculated. Sections 4 and 5 present the MAC and network layer modeling respectively. Examples of applications and the validation of the presented software tool are mentioned in Section 6.
ABSTRACT In this work, we present an event-based simulator for wireless networks using the Java programming language. Special focus has been placed on scalability and modularity of the implementation. Indeed, the new testbed can support easily up to 10000 nodes; at the same time the different components interact with each other with well-defined interfaces permitting separate and independent modification. Even though the simulator can be used for any ad hoc wireless network, we have concentrated on the more energy-limited and constrained sensor networks. The supported physical model includes the use of directional antennas, enabling the switching of the antennas’ lobe at will and the finding of direction of arrival (DoA) of the signal. Two variants of Aloha and one CSMA are the major MAC protocols implemented. At the network layer, emphasis was given on SPEED [1] and its enhancements. Finally, the user is provided with a configuration file to set its inputs, an excel output file holding all the statistics of the simulation and an interactive GUI showing the flow of information across the sensor nodes.
1. Introduction Wireless sensor networking is an emerging technology that has a wide range of potential applications including habitat monitoring and industrial sensing and diagnostics. This type of networks requires the cooperation of a large number of distributed nodes that should organize themselves into a multihop wireless network. Unlike a centralized system, it is subject to a unique set of resource constraints such as finite on-board battery power and limited network communication bandwidth. Given that network lifetime composes one of the main objectives of efficient protocol design, smart antennas and especially cost efficient switched beam arrays rise as a promising solution. Such an approach guarantees better communication efficiency, less interference and collisions leading to significant energy savings. In order to validate our intuition about the beneficial use of smart antennas on sensor nodes, we had to utilize an
2. Simulator’s Architecture For a simulator to be easily reused by other than its authors, modularity is a major concern. Based on this statement, we modeled each layer of the protocol stack as a separate class. These classes communicate with each other through welldefined interfaces, exposing and invoking other objects’ methods, and providing a straightforward tool for adding new software modules. Furthermore, such a design approach allows for more than one developer to work independently on separate aspects of the simulation tool leading to its faster readiness. Figure 1 describes the object oriented architecture of our approach.
1
ConfigFile Configuration Module
GUI
command line WSN topology draw ing of lobes routing info
Runscenarios
init()
collect_stats()
SimulationModule
Statistics
SystemClock
IPModule
find to w hich neigh to forw ard the packet suppress duplicates
Sendunicast/ multicast
Scheduler Scheduler
compute performance metrics w rite to excel file
MACModule
ACK send packet unicast/multicast support check for collision/ timeout
Collision/ Timeout
Update energy
PhysicalModule
connect w ith neighs calculate directivity SN's functionality
Figure 1. Simulator’s Architecture the demonstrated list of events in the queue. Every new event generated will be queued in the QueueOfEvents in the corresponding place keeping the array in an ascending sorted order. So, event with timestamp 220ms will be queued right after event 200 and before 230ms. On every turn, the event on top of the queue is scheduled to run.
Many things need to be taken into account when a real time simulator is to be built using a heavy programming language such as Java. Crucial challenges, apart from the aforementioned ones, are related to the highly distributed environment, time constraints, and efficient implementation. One should also bear in mind that thousands of sensor nodes have to build a network, communicate, and be able to deliver messages across it. This requires light coded objects that will occupy as little resources (such as memory and CPU cycles), as possible. This is why all the events like sending a packet, or waiting for an acknowledgement are modeled as independent threads, which run concurrently in each simulation. Such threads must be synchronized such that all events happen in chronological order. The mechanism to ensure this coordination is the scheduler. An example of its operation is evident in Figure 2. There is a global array called the QueueOfEvents which maintains a queue of events that will occur in the future. Those events are sorted in chronological order. The events are symbolized by a number which is the time at which they will occur in the future. Suppose we have
There is also a need to decide on how precise the simulation will be, so as to cover the needs of the experiment, and at the same time be light enough to be able to execute it hundreds of times and come up with acceptable results. We have tuned our simulator’s distinction capability to 1us. This means that any two events, generated at times differing more than 1us, will be scheduled correctly. The building blocks of the software are analyzed in the rest of the paper
2
node, but the majority stands for parameters just used by the simulator. Some of the parameters are the following: Sensor Name, Position of the Node, Transmission Speed, Packet Length and other parameters derived from them like for example the Transmission Time of a Packet.
QueueOfEvents 12
Queuing an event
45
Calling an event
46
220
Energy Category 120
Due to the nature of their design, sensor nodes are subject to strict energy consumption constraints. We render this important aspect of a sensor node by classifying a separate category for the parameters emulating its power consumption. The most important parameters included are the Initial Energy, Energy Left, Energy per transmitted packet, Energy per received packet, and Processing Energy. The values for these parameters were taken directly from the specifications of the Rene Motes. The Initial Energy of a node for example is 560mAh. Moreover, we have modeled three cases in which a sensor node consumes energy. The cases are when the node is transmitting a packet, receiving a packet, and processing a packet. We have not assumed any power consumption in idle mode.
150 190
Keep the events sorted
200 230
Figure 2. The scheduler’s queue
CPU Radio EEPROM LEDs Photo Diode Temperature
Active 5 mA 7 mA (TX) 3 mA 4 mA 200 µA 200 µA
Idle 2 mA 4.5 mA (RX) 0 0 0 0
Directive Antennas Category
Sleep 5 µA 5 µA 0 0 0 0
Smart antennas in general have been for long considered unsuitable for integration in wireless sensor nodes. They consist of more than one antenna element and therefore require a larger amount of space than traditional antennas. In addition to that, processing of more than one signal requires more computational power and electronics that translate radio frequency signals to baseband signals suitable for processing. However, it has been shown [7] that the use of smart antennas in sensor networks is in some cases obligatory and in other cases achievable, with minimal additional cost. We have therefore integrated in our simulation of the physical layer a category able to model the performance of network utilizing this new feature, as this is described in the following lines.
Figure 3. Rene motes specifications
3. The physical layer model We have used the specifications of Rene Motes [5] to model the Physical Module of the sensor node in our simulator. The major parameters taken from Rene Motes are the transmission rate, the transmitting and receiving power consumed, and the initial energy found in the battery. Figure 3 shows a list of parameters of a Rene Mote, along with an image of the physical hardware [6].
Each node can create a fixed number of directional beams, directed towards diverse directions. The lobes are created using switched parasitic arrays as those described in [8], and the superposition of all lobes ensures coverage towards all directions of the azimuth plane. Figure 4 describes an example of 4 switched lobes created by a sensor node, compared to an omni-directional pattern. Note that we model the maximum range of the directional lobes to be equal to that of the omnidirectional pattern. In general, concentrating the energy emitted by a directional antenna towards one direction ensures that the range of transmission towards that direction will increase, compared to the range of an omni-directional antenna. However, since our simulation tool focuses on the modeling of wireless sensor networks where node lifetime is most critical, we choose to use the directionality of the antennas to enhance the power consumed per transmission instead of the transmission range. Indeed, from antenna theory
In this section we describe how the parameters in the program are classified into categories, and how they are combined to simulate the behavior of a real sensor node. We have implemented three categories for the physical layer, described in the following paragraphs: Basic, Energy, and Directional Antennas. Basic Category The basic category contains the parameters needed in order to simulate the basic functionality of a sensor node. Some of the parameters represent actual variables stored in an actual sensor
3
the relationship revealing the power advantage in case of directional transmissions and receptions is given by,
2
⎡ Beamwidth ⎤ PTdir = PTomni ⎢ 0 ⎥⎦ ⎣ 360
Offset angle ω = 450
Lobe 1
3
In Figure 4, the offset angle is the angle of the first lobe relative to the horizontal axis. This value is randomly generated for each node, in order to emulate random sensor placement in a field. In this example, the offset angle is equal to 45 degrees.
Figure 4. Ranges of directional (gray) and omnidirectional (white) antennas and offset angle
In addition to the transmitting range where a node can establish a successful radio connection, an interference range is also incorporated. At this range, the power of the signal received is below the threshold value, meaning that the packet won’t be able to be received successfully at the receiving node, but can cause a collision to other packets being received. An example is shown in Figure 5: suppose that node “a” is transmitting a packet to node “d” and node “c” is transmitting a packet to node “b” at the same time. Notice that node “b” is not in the range of node “a” but resides within the interference range of node “a”. As a result, the packet from “a” to “d” will interfere with the packet sent from “c” to “b” and cause a collision at node “b”.
c
b
d
(1)
where PTdir and PTomni are the power needed to achieve the same range when directional and omni directional antennas are used, respectively.
4
a
2
Modeling the Directional Lobe In current analyses of the use of directional antennas [9], the directional lobes are described as radial sectors. In our simulation tool a more accurate approach has been followed, described in Figure 6. Consider a node “q” centered at the black dot, with a range of radius R and a point “p” on the circle at distance R from the node. The omni directional coverage of the node is modeled by the big circle. The directional lobe on the other hand is modeled by the ellipse inside the circle on the right of node q. The equation of the ellipse is given by
Interference lobe
Omni lobe Directional lobe
Figure 5. Interference lobe
PR u R*(0.5)1/2
2
W/2
a/2
q
R/2 Xa,Ya
2
( x − Xa) ( y − Ya) + =1 2 2 ( R / 2) (W / 2) PR
(2)
where Xa, Ya denote the center of the ellipse, R and W are the corresponding horizontal and vertical diameters of the ellipse, and x and y represent the coordinates of the points on the ellipse that satisfy the equation.
p
As mentioned before, the transmitting range of the directional lobe is set equal to that of the omnidirectional one, which is R in our case. Points Xa, Ya can be calculated as the midpoint between points “p” and “q”. So the only parameter missing in order to completely determine equation (2) is the parameter W. If we find a point which belongs to the ellipse, other than
Figure 6. Calculating the ellipse equation
4
“b”, with the equation of the ellipse of the corresponding lobe. Assume that the intersection points are named Ii, where I1 is the intersection of the line with the equation of the ellipse of lobe 1. Ii correspond to the points where the power received is just at the critical value. In other words, any nodes residing just an inch further from that point and are not covered by another available lobe from the transmitter will be receiving to weak to understand signals. From equations (5) we have:
points “p” or “q”, then we can replace the value of this point in the equation and solve for W. This point, which is point “u” at the figure, can be derived as follows: Under large scale modeling, the log-distance model provides that: 2
⎛ λ ⎞ 1 Pr = Pt Gt Gr ⎜ ⎟ n ⎝ 4π ⎠ r
(3)
⎛r G2 = ⎜⎜ 2 ⎝ r1
Fixing all the parameters and varying Pr and Gt, we get
Gt1 P = r1 Gt 2 Pr 2
(4)
(5)
where the path loss exponent n is taken to be equal to 2. Beamwidth specifies the angle at which the Gain is reduced to half. Suppose that the beamwidth, which is specified by the user, is equal to “a”. Then at angles +a/2 and –a/2 from the maximum gain (which is towards point p), the gain Gt is reduced to half. So the missing point we need, belonging to the ellipse, is a point at angle + a/2 from the direction of the maximum gain, and at a distance r2 satisfying equation (5).
r2 = r1 n
Calculation of the direction of arrival In the simulator, direction of arrival of a packet is calculated using the positions of the transmitting and receiving sensor nodes. However, in a real case scenario nodes do not need to know their geographical position, but they can still calculate the direction of arrival of a packet by using their directional lobes in a fashion similar to that when calculating the gain, as described in [8]. In the idle state the node activates only the omnidirectional lobe. When a node starts receiving a packet, it will switch between the lobes and record the different received power for each lobe. From the power received, and using equation (3), the receiving node calculates the gain Gr. Using equations (5) and (1), the node calculates the point on the ellipse satisfying the new range, and calculates the direction of arrival.
G2 ⇒ r2 = R ⋅ n 0.5 G1
where r1 (=R) is the distance to point p of the maximum gain Now that we have the distance r2 and the angle a/2 we can calculate the coordinates of the point “u”.
X u = r2 × cos( a / 2) + X q
(7)
G2 and r2 are the Gain and Range for the points we just calculated above for each directional lobe. G1 and r1 are the gain and range of the point on the ellipse with maximum directivity. G1 is equal to 1 which is the maximum gain. r1 = Range, which is the transmitting range of the node. r2 is the distance from node “a” to the point of intersection of the ellipse. Replacing those values in equation (7) and solves for G2, we can compute the gain at the points of interest. Energy efficiency, clearly suggests that the lobe with the highest gain G2 must be selected as the best lobe to use to transmit to the neighboring node.
Similarly, fixing all the parameters and varying Gt and r, we get
Gt1 r1n = Gt 2 r2 n
n
⎞ ⎟⎟ G1 ⎠
(6)
Yu = r2 ×sin(a / 2) + Yq Having found the points needed, we replace all the variables in equation (2) and solve for W.
Intersection with Lobe 2 Calculation of the Gain
3
Every node keeps a list of neighboring nodes that can establish radio connection with. Directional lobes are favored over the omnidirectional ones, because lower transmission power is needed as mentioned in the previous paragraph. In order to choose which lobe to use, we calculate the gain of each directional lobe in the direction of the receiving node and favor the lobe with the highest gain, as described below.
a
Suppose node “a” wants to transmit a packet to node “b”, as shown in Figure 7. For each lobe in turn, we check if the destination node (“b”) lies inside it. If this condition is satisfied, we calculate the intersection of the line joining “a” &
b
2 1
Intersection with Lobe 3
Intersection with Lobe 1
Figure 7. Calculation of gain
5
4. Higher layer modules
Collision: The second case leading to a timeout is when a receiving node receives two packets from two different sending nodes and the reception of the packets overlap in space and time. In this case the receiver node will not send an acknowledgment, hence allowing for the corresponding sending nodes to retransmit after the AckTimeout expires.
The MAC model Our simulator includes two variants of Aloha (simple and Binary Exponential Backoff Aloha (BEBA) [10]) and the nonpersistent CSMA protocol. In simple Aloha, the procedure followed is sending the first message immediately and waiting for backoff before any retransmission. In BEBA, there is a waiting for a backoff period before all transmissions, even the very first one. This version is particularly useful in multicast transmissions, where the one hop neighbors receiving the same packet at the same time, should not begin relaying these packets simultaneously due to the certainty of collision. With BEBA, all nodes in the vicinity of the source node receive the packet at the same time because of the broadcast mode. However, instead of retransmitting the packets immediately, they wait a random period of time according to the exponential backoff algorithm, thus reducing the probability of collision. Non-persistent CSMA is a less greedy version of the known 1-peristent Carrier Sense Multiple Access scheme, where:
It must be noted than no collisions are assumed for ACKs. Even though we take under consideration the time required for sending and receiving an ACK, we assume that it always gets through without collisions, due to its small size. Since the MAC layer of the protocol stack is responsible for the reliable transfer of information across individual physical links, it will not notify the network layer until the message is successfully delivered. Therefore, it will retransmit the packet after a random period that grows exponentially with the number of collisions. Once the message is successfully delivered the MAC of the specific node can be invoked by its upper network layer to transmit another packet. The network layer model The routing module constitutes of a class with different routing algorithms implemented. The corresponding routing algorithm is chosen by the user during configuration of the simulation scenario. The list of currently implemented algorithms includes:
The node firstly senses the channel If the channel is idle, then it transmits If the channel is busy, then it waits one packet duration and then re-senses
Other more intelligent MAC protocols, like 802.11 with the RTS/CTS mechanism were not implemented due to the fact that our focus was on wireless sensor networks rather than ad hoc ones. With the battery capacity of sensor nodes and their processing and storage capabilities we believe that these simpler MAC protocols are more suitable. Finally, a multicast extension is provided for all protocols, allowing for the network layer to send a packet to more than one node with a single transmission, and inferring additional energy savings.
Broadcast Flooding (multicast) Normal Flooding Directional Flooding SPEED Broadcast (multicast) SPEED with duplicate suppression SPEED with hole detection SPEED with energy enhancement
All the functionalities of the network layer are implemented in the routing module. Some of these functionalities include, for example, choosing the next node to forward the packet and suppressing duplicates. The routing module communicates with the MAC module through a well defined interface. The major functionalities provided to the MAC module are two: to send a packet in multicast mode, and to send a packet to a specific node in unicast mode. In multicast, the next hop node is not specified, so all nodes residing within the source node’s transmission lobe, receive the packet and process it as if destined to them. In this case no acknowledgements are sent and in the case of collisions no retransmissions are done. In the unicast mode, the next hop is specified by the transmitter. So among the receiving nodes, only the node specified will process the packet while the rest of the neighbouring nodes ignore it.
Collisions and Retransmissions When a transmitting node sends a packet to a neighbouring node, the transmitting nodes waits for a certain period of time called “AckTimeout” where it waits to receive an acknowledgment packet from the receiving node. If the AckTimeout expires before receiving any reply, the transmitting node assumes a collision at the receiver and retransmits the packet again. We have set the value of AckTimeout in our simulator to be equal to two times the transmission time of a packet. We have distinguished between 2 cases leading to a retransmission: Timeout: The first case that leads to a retransmission is when a transmitting node is sending to a node that at the time acts as a transmitter itself. In this scenario the destination node will not “hear” the transmitted packet, and it will therefore not respond with an acknowledgement.
From the routing algorithms listed above, only Broadcast Flooding and SPEED Broadcast use the available multicast
6
Aloha Throughput 0.25
Throughput (S)
0.2 0.15 0.1 0.05 0 0.1
0.3
0.5
1
1.5
2
3
5
Offered Load (G)
Figure 11. Validation results of an Aloha network of 500 nodes mode. The implementation of the multicast transmission mode exploits the wireless multicast advantage: This reflects the medium nature which allows for a message destined to a node to be heard instantly at all nodes in the transmitter’s range. Exploiting this advantage, all intended destination nodes can receive a message from a single node without the need of multiple unicast transmissions.
Figure 8. Configuration File
5. Simulation examples and validation Each simulation scenario is modeled and initialized through a user-friendly graphical user interface (GUI). The GUI is used to view and edit the simulation parameters of a given scenario, through the use of a configuration file. The configuration file includes all the parameters of the various layers modeled by the simulation tool. Figure 8 shows an example configuration file, including topology parameters, physical, MAC and Network layer parameters. The topology parameter defines the way that sensor nodes are placed in a rectangular field of userdefined dimensions. The topologies available are square grid, random, random with a central hole, or random with random holes, where a hole is defined as a region in the network with absence of sensor nodes.
Figure 9. Sample network of 30 nodes and the directive lobes of node 8
The GUI also provides the capability to view the topology of the network, view the area coverage of the lobes of a certain node and view the activated nodes in the network. Figure 9 shows an example of the topology of a network of 30 nodes along with the area coverage of the lobes of node 8. Figure 10 on the other hand shows the topology of a network of 5000 nodes; the activated nodes are colored in real time when routing a message from the top left corner to the bottom right corner using the SPEED protocol.
Using the interface provided by the simulation tool we have modeled a wireless ad-hoc network of 500 nodes that are all within the range of each other, use a simple Aloha MAC protocol, and omni-directional antennas. The results shown in Figure 11, where the maximum throughput of the network is equal to 19% of the channel capacity, are in accordance to the theoretical analysis of the Aloha protocol [11]. Therefore, the
Figure 10. Network of 5000 nodes. Snapshot showing the activated nodes in black
7
simulation tool produces valid results and can be used to accurately model ad-hoc and sensor networks having a large number of nodes.
7. References [1] Tassos Dimitriou, Ioannis Krontiris, Fotios Nikakis and Paul Spirakis. “SPEED: Scalable Protocols for Efficient Event Delivery in Sensor Networks”, Networking 2004, Athens, Greece [2] J.A. Miller, R.S. Nair, Z. Zhang, H. Zhao, “JSIM: A Java-based simulation and animation environment”, Proceedings of the 30th Annual Simulation Symposium, 7-9 Apr 1997, pp. 31-42 [3] Philip Levis and Nelson Lee, “TOSSIM: A Simulator for TinyOS Networks”, September 17 2003, http://www.cs.berkeley.edu/~pal/pubs/nido.pdf [4] http://www.isi.edu/nsnam/ns [5] F. Zhao,L. Guibas, “Wireless Sensor Networks – An information processing approach”, Morgan Kaufmann, 2004 [6] F.Zhao, Programming Embedded Sensor Networks, http://www.ece.uci.edu/codes+isss/Invited/FengZhao.pdf [7] D. Leang, A. Kalis, “Smart SensorDVB: sensor network development boards with smart antennas” International Conference on Communications, Circuits and Systems, 2004. vol. 2 , pp. 1476 – 1480 [8] S. Preston, V. Thiel, T. Smith, S. O’Keefe, and J. Lu, “Basestation tracking in mobile communications using a switched parasitic antenna array,” IEEE Trans. Antennas Propagat., vol. 46, no. 6, pp. 841–844, June 1998. [9] S. Yi, Y. Pei, S. Kalyanaraman, ” On the Capacity Improvement of Ad Hoc Wireless Networks Using Directional Antennas” MobiHoc’03, June 1–3, 2003 [10] N. O. Song, B. J. Kwak and L.E, Miller, "On the stability of exponential backoff", J. Res. Natl. Inst. Stand. Technol., vol. 108, pp.289-297, August 2003 [11] T. S. Rappaport, “Wireless Communications”, ISBN 0-13042232-0, pp. 463
6. Conclusion In this paper we presented a flexible software tool to simulate wireless ad hoc and sensor networks using directional antennas. The tool is based on the Java language, is eventdriven, and provides a friendly graphical interface for modeling wireless network scenarios. The simulator provides for modeling of the physical, MAC, and network layers of large wireless networks that have not been displayed in the literature hitherto. Moreover, extensive support for directional antennas with any possible number of lobes and directions has been included. A variety of MAC and network protocols were modeled and the adaptability of the simulation tool to different scenarios has been demonstrated. Large networks of 10000 nodes ran without a problem, producing meaningful outputs in excel files ready for post-simulation analysis. We intend to extend the capabilities of the simulation tool that we presented, modeling more MAC and Network layer algorithms for multi-hop networks. Furthermore, more accurate modeling could be developed regarding the introduction of frame error rates in the transmission of packets, the consideration of collisions for ACK frames, and the development of more accurate energy models on the network nodes, taking into account the fact that the architecture of the system promises fast integration of new functions and models with the rest of the code through well defined interfaces.
8
