REFERENCES

[1] W. Choi, P. Shah, and S. K. Das, “A Framework for Energy-Saving Data Gathering Using Two-Phase Clustering in Wireless Sensor Networks”, in Proceedings of the International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous), Boston, 2004, pp. 203-212.

[2] M. Lee, and S. Lee, “Data Dissemination for Wireless Sensor Networks”, in Proceedings of the 10^th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC’07).

[3] C. Intanagonwiwat, R. Govindan, D. Estrin, J. Heidemann, and F. Silva, “Directed Diffusion for Wireless Sensor Networking”, IEEE/ACM Transactions on Networking, Vol. 11, no. 1, Feb 2003.

[4] H. Cam, S. Ozdemir, P. Nair, and D. Muthuavinashiappan, “ESPDA: Energy-Efficient and Secure Pattern-based Data Aggregation for Wireless Sensor Networks”, in Proceedings of IEEE Sensor- The Second IEEE Conference on Sensors, Toronto, Canada, Oct. 22-24, 2003, pp. 732-736.

[5] L. Gatani, G. Lo Re, and M. Ortolani, “Robust and Efficient Data Gathering for Wireless Sensor Networks”, in Proceeding of the 39th Hawaii International Conference on System Sciences – 2006.

[6] K. Dasgupta, K. Kalpakis, and P. Namjoshi, “An Efficient Clustering-based Heuristic for Data Gathering and Aggregation in Sensor Networks”, IEEE 2003.

[7] E. Fasolo, M. Rossi, J. Widmer, and M. Zorzi, “In-Network Aggregation Techniques for Wireless Sensor Networks: A Survey”, IEEE Wireless communication 2007.

[8] M. Lee and V.W.S. Wong, “An Energy-aware Spanning Tree Algorithm for Data Aggregation in Wireless Sensor Networks,” IEEE PacRrim 2005, Victoria, BC, Canada, Aug. 2005.

[9] M. Ding, X. Cheng, and G. Xue, “Aggregation tree construction in sensor networks,” in Proc. of IEEE VTC’03, Vol. 4, Orlando, FL, Oct. 2003.

[10] “The Design Space of Wireless Sensor Networks” by Kay R¨omer and Friedemann Mattern

http://www.vs.inf.ethz.ch/publ/papers/wsn-designspace.pdf

[11] http://en.wikipedia.org/wiki/Wireless_Sensor_Networks

[12] “Handbook of Sensor Networks: Compact Wireless and Wired Sensing Systems” by Mohammad Ilyas and Imad Mahgoub.

[13] “Ad-hoc & Sensor Networks” by Carlos de Morais Cordeiro and Dharma Prakash Agrawal.

[14] S. Madden et al., “TAG: a Tiny Aggregation Service for Ad-hoc Sensor Networks,” OSDI 2002, Boston, MA, Dec. 2002.

[15] S. Nath et al., “Synopsis Diffusion for Robust Aggregation in Sensor Networks,” ACM SenSys 2004, Baltimore, MD, Nov. 2004.

[16] K. Dasgupta et al., “Maximum Lifetime Data Gathering and Aggregation in Wireless Sensor Networks”, In Proc. of IEEE Networks’02 Conference, 2002.

[17] W. Heinzelman, A.P. Chandrakasan, and H. Balakrishnan, “Energy-Efficient Communication Protocols for Wireless Microsensor Networks”, In Proc. Of Hawaiian Intl. Conference on System Science, 2000.

[18] NRL’s Sensor Network Extension to ns-2. http://nrlsensorsim.pf.itd.nrl.navy.mil/

[19] David curren, “A survey of Simulation in Sensor Networks”. www.cs.binghamton.edu/~kang/teaching/cs580s/david.pdf

[20] The Network Simulator NS-2, http://www.isi.edu/nsnam/ns/ , January 2008.

Network Simulator-2

The Network Simulator version 2 (NS-2) is a deterministic discrete event network simulator, initiated at the Lawrence Berkeley National Laboratory (LBNL) through the DARPA funded Virtual InterNetwork Testbed (VINT) project. The VINT project is collaboration between the Information Sciences Institute (ISI) at the University of Southern California (USC), Xerox's Palo Alto Research Center (Xerox PARC), University of California at Berkeley (UCB) and LBNL [20].

NS-2 was initially created in 1989 as an alternative to the REAL Network Simulator. Since then there is significant growth in uses and width of NS project. Although there are several different network simulators available today, ns-2 is one of the most common. NS-2 differs from most of the others by being open source software, supplying the source code for free to anyone that wants it. Whereas most commercial network simulators will offer support and a guarantee but keeping the moneymaking source code for themselves. The release of the source code helps users to create their own functions and subprograms, but also makes it easier to implement them into the ns-2 environment. One of the main benefits for the ns project group releasing the source code is that independent researchers can help in the development of ns-2. It is fairly common that a researcher contributes with the code of a non-implemented protocol or algorithm, after constructing it for his studies.

It should be noted that NS-2 is a research progressive effort and not a kind of commercial software release. The difference is that there are very few people in the ns project group compared to ordinary software, leading to difficulties in supporting all the users. That problem has lead to the solution of having a huge mailing list (http://mailman.isi.edu/mailman/listinfo/ns-users) for anyone interested, as well as a complete archive of all the mails ever been sent to this mailing list. The mailing list is based on the idea of user helping user, taking the load of the ns project group. The mailing list and the archives are a huge help for all users of ns-2, no matter old or new, since usually someone else has had the same problem before.

Another important thing to note is that NS-2 is an ongoing progressive project and hence can not be considered as a complete product. This is the reason why it is free of cost and only offers the mailing lists as support. The people that are in charge of the project heavily rely on the users to find bugs and faults and reporting these when discovered. This also leaves the validating of results to the user, but the user is not alone so help is just an email away. The most commonly used protocols are so well implemented and checked so the main concerns are the new implementations. New implementations usually start out as a research assignment not linked to the ns project group. Since the project group does not have a full company helping them in verification and implementation they have no possibility to do everything themselves thus encouraging any help they can get.

A 1 The NS-2 structure

NS-2 is made up of hundreds of smaller programs, separated to help the user sort through and find what he or she is looking for. Every separate protocol, as well as variations of the same, sometimes has separate files. Though some are simple, but still dependent on the parental class [20].

                           

Figure A.1 The basic structure of NS-2

A 1.1 C++

C++ is the predominant programming language in ns-2. It is the language used for all the small programs that make up the ns-2 hierarchy. C++, being one of the most common programming languages and specially designed for object- oriented coding, was therefore a logical choice what language to be used. This helps when the user wants to either understand the code or do some alterations to the code. There are several books about C++ and hundreds, if not thousands, of pages on the Internet about C++ simplifying the search for help or answers concerning the ns-2 code.

A 1.2 OTcl

Object Tcl (OTcl) is object-oriented version of the command and syntax driven programming language Tool Command Language (Tcl). This is the second of the two programming languages that NS-2 uses. The front-end interpreter in NS-2 is OTcl which link the script type language of Tcl to the C++ backbone of NS-2. Together these two different languages create a script controlled C++ environment. This helps when creating a simulation, simply writing a script that will be carried out when running the simulation. These scripts will be the formula for a simulation and is needed for setting the specifications of the simulation itself. Without a script properly defining a network topology as well as the data-rows, both type and location, nothing will happen. For a more in depth presentation of these scripts, it is better to have a closer look at the introduction and related chapters in the NS-2 manual.

A 1.3 Nodes

A node is exactly what it sounds like, a node in the network. A node can be either an end connection or an intermediate point in the network. All agents and links must be connected to a node to work. There are also different kinds of nodes based on the kind of network that is to be simulated. The main types are node and mobile node, where node is used in most wired networks and the mobile node for wireless networks. There are several different commands for setting the node protocols to be used, for instance what kind of routing is to be used or if there is a desire to specify a route that differs from the shortest one. Most of the commands for node and mobile node can be easily found in the ns documentation. Nodes and the closely connected link creating commands, like simplex link and duplex link, could be considered to simulate the behavior of both the Link Layer.

A 1.4 Agents

An agent is the collective name for most of the protocols you can find in the transport layer. In the ns-2 documentation agents are defined as the endpoints where packets are created and consumed. All the agents defined in ns-2, like tcp, udp etc., are all connected to their parent class, simply called Agent. This is where their general behavior is set and the offspring classes are mostly based on some alterations to the inherent functions in the parent class. The modified functions will overwrite the old and thereby change the performance in order to simulate the wanted protocol.

A 1.5 Applications

The applications in ns-2 are related to the Application Layer in the TCP/IP suite. The hierarchy here works in the similar way as in the agents case. To simulate some of the most important higher functions in network communication, the ns-2 applications are used. Since the purpose of ns-2 is not to simulate software, the applications only represent some different aspects of the higher functions. Only a few of the higher layer protocols has been implemented, since some are quite similar when it comes to using the lower functions of the TCP/IP stack. For instance there is no use adding both a SMTP and a HTTP application since they both use TCP to transfer small amounts of data in a similar way. The only applications incorporated in the release version of ns-2 are a number of different traffic generators for use with UDP and telnet and FTP for using TCP. All the applications are script controlled and when concerning the traffic generators, you set the interval and packet-size of the traffic. FTP can be requested to send a data packet whenever the user wants to, or to start a transfer of a file of an arbitrary size. If starting an FTP transmission and not setting a file-size the transmission will go on until someone calls a stop.

A 1.6 NAM

The Network Animator NAM is a graphic tool to use with ns-2. It requires a nam-tracefile recorded during the simulation and will then show a visual representation of the simulation. This will give the user the possibility to view the traffic packet by packet as they move along the different links in the network. NAM offers the possibility of tracing a single packet during its travel and the possibility to move the nodes around for a user to draw up his network topology according to his own wishes. Since the simulation has already been performed there is no possibility for the user to change the links or any other aspect of the simulation except the representation. The existence of an X-server allows NAM to be able to open a graphical window. Therefore if NAM is to work, there must be a version of X-server running.