The Technion Electrical Engineering
Networked Software Systems Laboratory
Wireless Sensor Network for Tracking the Congestion in INTERNET Network Routers
Supervisor: Mark Shifrin
Students: Yuri Kipnis
Nir Bar-Or
Table of Content
Table of Content 2
Table of Figures 4
Abbreviations 5
Description of The Project Idea 6
Why? 6
What are we suggest? 6
A view on our project 7
Development Environment 8
NS-2 8
NAM 8
FEDORA-9, Sulphur 8
TCL 9
Theoretical Background 10
Routers and Routing Protocols 10
WSN – Wireless Sensors Network 10
Developoment Process 12
Stage 1: Choosing NS2 12
Stage 2: Learning Tcl Language 12
Stage 3: Building a Simple Wired Network 13
Stage 4: Adding Queue-Monitors, Traces and Modified Links 13
Stage 5: Building a Simple Wireless Network with Monitoring 14
Stage 6: Simulating a Message Received Event Handler 14
Stage 7: Exploiting NS Features for Our Benefits 15
Stage 8: Integrating Both Routers and Wireless Sensors Networks 16
Stage 9: Sending Load Information to WSN-Central-Station 16
Simulation Networks Topology 18
NS-2 Tools 23
Simulation object 23
Routing object 26
Link object 27
FTP object 29
Monitor object 30
Trace files 31
Simulation Design 32
Simulation building sequence 32
Global Variables 32
Routers network procedures 34
BuildTopology_ROUTERS 34
BuildRoutes_ROUTERS 35
FTPoverTCP_ROUTERS 35
WSN network procedures 36
BuildTopology_WSN 36
BuildRoutes_WSN 36
FTPoverTCP_WSN 37
RouterMonitor 37
CentralMonitor 38
Finish 38
Summary 39
What is Next? 39
Satellite Communication 39
Appendix A – Simulation code 40
References 48
Books 48
Websites 48
Table of Figures
Figure 1 - Wireless Sensors Networks 11
Figure 2 - Routers network default topology 19
Figure 3 - Routers network specific routes topology 20
Figure 4 - WSN topology 21
Figure 5 - Simulation network topology 22
Figure 6 - The Structure of a Unicast Node (from NS-2 manual 2009) 24
Abbreviations
NS-2 - Network simulator used in this project
Tcl - script language used in this project
WSN - Wireless Sensor Network
WSN central-station or central station - the node in WSN network that collects information from the sensors, decides about the routing algorithm and sends response to sensors.
Description of The Project Idea
Why?
As the popularity of Internet Network is growths up the Internet performance and throughput are negatively affected. When a link or node (router) is carrying so much data that it’s quality of service deteriorates. Typical effects include queuing delay and packet loss of new connections. A consequence of these latter two is that incremental increases in offered load lead to an actual reduction in network throughput.
WSN – Wireless Sensor Network is commonly used around the world in different industrial and military uses such as surveillance in the battlefield, monitoring the physical conditions in a production area, etc.
So here is an idea: Set up a WSN on an existing routers network so we could monitor the traffic loads and routes in the network.
But monitoring isn’t enough! We can also alter the routing tables in order to distribute the load better on the network and by that improving the network's efficiency. Better resulting in saving time and improving Internet performance.
Now we have a sensor network that not only sense but also alter the router network, is it worth it? Will it save us a time? Will it indeed improve our efficiency?
What are we suggest?
As we can see from the previous paragraph we can build the WSN, mount it on an existing network and start experimenting but how can we be sure that this solution isn't only good for that specific network we've checked? How can we be sure that it will do the same for any type of network structure or routing? Checking this will be of a great cost and extremely time consuming.
Our solution: building a system that will allow us to test the simplified WSN affect on all types of network structure, routing protocols, any number of sensors and/or routers and even different algorithms of load distribution and do all that in our computer without the need of building anything.
A view on our project
· The first part of our project (discussed in this article) consists of building a platform that allows us to generate any type of router network that is well connected, routed and its data traffic is controllable.
· This platform will also generate a WSN which will be mounted on the routers network.
· The WSN structure is different than the routers network. This structure is star-like where all sensors are connected to a central station[1] and no two sensors will be connected to each other allowing data to flow only between a sensor and the WSN-central-station.
· The sensors report to the WSN-main-station about the load on each link going out from a router to any other router on the net (that is connected to it, of course), than the WSN-central-station runs the load-distribution-algorithm and, if needed, alters the router's routing table.
The platform that we have built will allow the user to build any type of router network, mount any number of sensors on each router the user will choose, write any load-distribution-algorithm that will be run by the WSN-central-station, run and document the traffic in several configurations: Simple run of the data in the routers network without sensing, run the routers network with data gathering by the sensors and the WSN-central-station but without dynamically altering the routing tables and run the routers and the WSN and its load-distribution-algorithm.
Development Environment
NS-2
NS or Network Simulator is a discrete event network simulator, meaning that the sequence is divided to chronological time units and each time unit will hold one or more events that will be performed.
NS is an open source model implemented mainly in C++ and provides a simulation interface through O-Tcl/TCL script languages. NS also has plentiful online documentation and those are the reasons for its wide use in academia.
NS supports several popular network protocols (TCP, UDP, etc.) and enables wired, wireless and even satellite networks. There are also supported AODV, DSDV, TORA and other routing protocols.
The main form of working with NS is to build a simulation scenerio in the form of a .tcl script file and run it with NS.
NAM
Nam is a Tcl/TK based animation tool for viewing network simulation traces and real world packet traces. It is mainly intended as a companion animator to the NS simulator. Using NAM the user can graphically see the network and data transportation. NAM supports topology layout, packet level animation and various data inspection tools.
FEDORA-9, Sulphur
Fedora is a general porpuse operating system built on top of a linux kernel, developed by community-supported Fedora-Project sponsored by Red Hat.
Fedora9, codenamed Sulphur, was released in 13/5/2008 and presents a windows-like interface.
TCL
Tool Command Language is a very powerful and easy to learn scripting language, often referred to as a programing language. TCL is widely used for scripted applications, GUI (Tcl/Tk), testing and file processing.
TCL is also used as the API for NS.
Theoretical Background
Routers and Routing Protocols
Internet routers are specialized computers that interconnect the network by switching communications from one line to another at cross points. When a computer communicates with another on the Internet, it associates each packet with some other IP address and then sends it to the other Internet router. The router then uses a routing algorithm to send the packet across the Internet to the destination computer.
Since the Internet routers service many packets and each router is a shared resource, many decisions must be made. There may be multiple paths from source to the destination. The main performance measures affected by the routing algorithm are throughput and average packet delay.
Routing is the process of selecting a path in which the packets are progressing in the network.
The most popular routing Internet protocols are: BGP, OSPF, RIP.
WSN – Wireless Sensors Network
Smart environments represent the next evolutionary development step in building utilities, industrial, home and transportation systems automation. Like any sentient organism, the smart environment relies first on sensory data from the real world. Sensory data comes from multiple sensors of different modalities in different locations. The smart environment needs information about its surroundings as well as about its internal workings. The challenges in the hierarchy of: detecting the relevant quantities, monitoring and collecting the data, assessing and evaluating the information, formulating meaningful user display decision-making and alarm functions are enormous. The information needed by smart environment is provided by Wireless Sensor Networks, which are responsible for sensing as well as for the processing hierarchy.
Wireless Sensor Networks is a wireless network consisting of separate distributed devices that use sensors to monitor and collect environmental conditions. Moreover, each sensor is equipped with communication device to transmit collected information to other devices or base station for further processing.
A sensor network normally constitutes of a wireless ad-hoc network, meaning that each sensor supports a multi-hop routing algorithm (several nodes may forward data packets to the base station).
Figure 1 - Wireless Sensors Networks
Developoment Process
Stage 1: Choosing NS2
As mentioned earlier in this book, NS is commonly used in academia. The main advantages of this product are simplicity, open source code, free product, wide documentation on the web and supporting most of the frequently used protocols.
The simulator required for this project had to:
· Support both wired and wireless communication
· Have monitoring abilities
· Have simple API (advantage)
· Produce structural output files that can be later processed
· Be well documented
For these reasons NS was chosen for this project.
Note: Even though NS is open-source, in this project we did not altered the C++ code that implements NS but tried to come up with solutions to our problems with only NS basic API and TCL scripting.
Stage 2: Learning Tcl Language
The Tcl is the most common API of NS-2 simulator.
The way to master Tcl programming is to understand these primary Tcl features:
· Command substitution.
· Variable substitution.
· Brackets (any type of it) and quotation marks – What is their influence on the different substitutions.
After understanding of these basic points, all that's left is to learn the commands list and start with the programming.
Stage 3: Building a Simple Wired Network
In this stage, which was the first stage of implementation, we wanted to start off with a simple network that will teach us the basics of NS and will ensure that we have installed Ns successfully.
We started with a simple wired network in a click structure. In that network we have used FTP over TCP and DSDV routing protocol.
In this stage we've learned how to:
· Create wired nodes and manipulate their configuration.
· Create links between nodes, single direction links, simplex-link and duplex-link.
· Create Tcp agents and connect it to the nodes.
· Create Ftp agents over the Tcp agents and connect them to each other.
· Start a simple data transmission simulation from all nodes randomly and under no restrictions.
· Run a simple Tcl script with NS.
Stage 4: Adding Queue-Monitors, Traces and Modified Links
Now we have a simple wired network, the next step was to learn how to extract information on the data transportation in the network.
To trace the network packets we used the trace files. During simulation each packet that is being sent, received or dropped at a link or a queue is documented in this file. The data is very detailed and organized but can not be processed in a standard way during simulation, therefore a different solution must be found.
Another tracing capability is monitoring. We've chosen queue-monitoring on every link in the network so we could gather detailed information from every router's outgoing links.
The combination of monitoring, where information is saved in the cache, with time scheduling enabled us to keep track of the load in the network during simulation.
Finally, we've investigated the link object and learned how to control its properties such as queue type, propagation delay, bandwidth, etc.
Stage 5: Building a Simple Wireless Network with Monitoring
As a first step in the WSN implementation we started in implementing the same network as implemented at stage 3 but using wireless nodes.
The next step was to change the structure of the network to a star-like structure where all the sensors are connected only to the WSN-main-station in a duplex link.
On this stage monitors have been added. To configuring the wireless node to work properly with the monitor the node configuration option -WiredRouting was set to ON, this enabled us to establish links between wireless stations and attach queue-monitors on it.
Stage 6: Simulating a Message Received Event Handler
By now we have simple implementations of both routers and wireless sensors networks. Here we encountered in one of the project's major obstacles: we need to simulate an event that will be triggered every time a node receives a packet.
We decided to take the next approach:
· Using the monitors we are constantly polling each link for the amount of packets that it received, by saving the previous read we can compare and see if the node had received new packets on that specific link, how many packets was dropped from the link queue and how many were received successfully.
· Because we know which link we are checking, we know the id number of the router node that send the packet and the id number of the receiving router node.
· Here we can run a Tcl procedure and continue on with the simulation, in the above mentioned procedure we can send a response to the packet we have received, alter any routing table we desire or perform any other alterations and/or calculations on the net's components.
This is how we simulated a much needed event handler.
Important note: The purpose weren't to create a generic event handler but something that we can use which will give the right behavior under our assumptions and rules.
Stage 7: Exploiting NS Features for Our Benefits