Mitigating Performance Degradation in Congested Sensor Networks

Transcription

1 Mitigating Performance Degradation in Congested Sensor Networks 1 Sandip B. Chavan, 2 H K Sawant Abstract: In today s world Wireless Sensor Networks are used in many industrial and civilian application areas. Maintaining Sensor Network is very cost-effective so sensors will be shared by multiple applications to gather various types of data. All the data generated in Sensor Network will not be equally important, some data may be important than other. Thus a differentiated data delivery is required in Sensor Networks for HP and LP data. To accomplish this task this system uses CAR and MCAR routing mechanisms whose main aim is to increase the delivery ratio of HP data and to increase the performance of the system in presence of congestion. So the scope of the system can be confined as the task of integration of the existing technology and proposed routing protocols to the maximum level possible so that it reduce the time and cost significantly and the system can be utilized and implied in the suitable way possible. System objective is to lessen the progressive performance failure in an overcrowded Sensor Networks using CAR and MCAR and increase the Delivery Ratio of High Priority Data. Use energy more uniformly in the deployment and reduce the energy consumed in the nodes that lie on the conzone, which leads to an increase in connectivity lifetime. I. INTRODUCTION This proposed system carried according to the specifications of Waterfall Model, popularly known as Linear Sequential Model which suggests a systematic, sequential approach to software development. This project consisting of the following phases of waterfall model A. Feasibility Study A detailed feasibility study was conducted to know the technical and financial feasibility of the project and it was found that the project is feasible to design, develop, use, and maintain in all respects. B. Requirement Analysis and Project Planning Before starting the design of the project, in detail the requirements of the project is analyzed which includes system requirement specification, software and hardware requirements and after project planning is done with the help of requirement analysis. As part of the requirement collection the project found the following things are need to be implemented. 196 A protocol to work as a differentiated protocol and route HP and LP packets for measuring the performance of the network. Different modules each for measuring the performance of the general traffic flow of the network. Separate modules to form the network, to find the congestion zone and to rout the data. A good GUI (Graphical User Interface) and controls to setup and use the tool as required in different scenario. C. Design After successful analysis of system requirement, design of the project started where various design constraints are analyzed. The design phase consists of two main modules CAR and MCAR, intern CAR consist of three sub-modules network formation, conzone discovery, differentiated routing and MCAR consists of two sub-modules network formation, setting modes and routing data, each of which designed to do a specific task in monitoring and analyzing the performance of the network. A functional design methodology and top-down strategy is used in this design phase. D. Coding The design of the system produced during the design phase is converted into code in java environment; it also makes use of Java Development Kit 1.5 (JDK 1.5). The coding is done according to the design strategy i.e., code is done according to the module wise. The coding is done for routing of HP and LP data to exhibit different modules of the project. The source code makes use of some standard java built-in packages, classes, functions, and structures to ease coding. E. Testing The program is tested by executing with a set of test cases in different environments of the networks and stand alone machine and then output of the program for the test cases is evaluated to determine if the program is performing as expected. Incremental Testing Strategy is used to ensure functional testing. First some main parts of the project were tested independently. Then these parts are combined together forming subsystems, which are then tested separately.

2 II. ADHOC ON-DEMAND DISTANCE VECTOR (AODV) ROUTING PROTOCOL Adhoc On-Demand Distance Vector (AODV) Routing is a routing protocol for mobile adhoc networks and other wireless ad-hoc networks. It is jointly developed in Nokia Research Center of University of California, Santa Barbara and University of Cincinnati by C. Perkins and S. Das. AODV is capable of both unicast and multicast routing. It is a reactive routing protocol, meaning that it establishes a route to a destination only on demand. In contrast, the most common routing protocols of the Internet are proactive, meaning they find routing paths independently of the usage of the paths. AODV is, as the name indicates, a distance-vector routing protocol. In AODV, the network is silent until a connection is needed. At that point the network node that needs a connection broadcasts a request for connection. Other AODV nodes forward this message, and record the node that they heard it from, creating an explosion of temporary routes back to the needy node. When a node receives such a message and already has a route to the desired node, it sends a message backwards through a temporary route to the requesting node. The needy node then begins using the route that has the least number of hops through other nodes. Unused entries in the routing tables are recycled after a time. When a link fails, a routing error is passed back to a transmitting node, and the process repeats. Much of the complexity of the protocol is to lower the number of messages to conserve the capacity of the network. For example, each request for a route has a sequence number. Nodes use this sequence number so that they do not repeat route requests that they have already passed on. Another such feature is that the route requests have a "time to live" number that limits how many times they can be retransmitted. Another such feature is that if a route request fails, another route request may not be sent until twice as much time has passed as the timeout of the previous route request. The advantage of AODV is that it creates no extra traffic for communication along existing links. Also, distance vector routing is simple, and doesn't require much memory or calculation. However AODV requires more time to establish a connection, and the initial communication to establish a route is heavier than some other approaches. The Ad hoc On-Demand Distance Vector (AODV) Routing protocol uses an ondemand approach for finding routes, that is, a route is established only when it is required by a source node for transmitting data packets. It employs destination sequence numbers to identify the most recent path. The major difference between AODV and Dynamic Source Routing (DSR) stems out from the fact that DSR uses source routing in which a data packet carries the complete path to be traversed. However, in AODV, the source node and the intermediate nodes store the nexthop information corresponding to each flow for data 197 packet transmission. In an on-demand routing protocol, the source node floods the Route Request packet in the network when a route is not available for the desired destination. It may obtain multiple routes to different destinations from a single Route Request. The major difference between AODV and other ondemand routing protocols is that it uses a destination sequence number (DestSeqNum) to determine an upto-date path to the destination. A node updates its path information only if the DestSeqNum of the current packet received is greater than the last DestSeqNum stored at the node. A RouteRequest carries the source identifier (SrcID), the destination identifier (DestID), the source sequence number (SrcSeqNum), the destination sequence number (DesSeqNum), the broadcast identifier (BcastID), and the time to live (TTL) field. DestSeqNum indicated the freshness of the route that is accepted by the source. When an intermediate node receives a RouteRequest, it either forwards it or prepares a RouteReply if it has a valid route to the destination. The validity of a route at the intermediate node is determined by comparing the sequence number at the intermediate node with the destination sequence number in the Route Request packet. If a Route Request is received multiple times, which is indicated by the BcastID-SrcID pair, the duplicate copies are discarded. All intermediate nodes having valid routes to the destination, or the destination node itself, are allowed to send RouteReply packets to the source. Every intermediate node, while forwarding a RouteRequest, enters the previous node address and its BcastID. A timer is used to delete this entry in case a RouteReply is not received before the timer expires. This helps in storing an active path at the intermediate node as AODV does not employ source routing of data packets. When a node receives a RouteReply packet, information about the previous node from which the packet was received is also stored in order to forward the data packet to this next node as the next hop toward the destination. III. DYNAMIC SOURCE ROUTING Dynamic Source Routing (DSR) is a routing protocol for wireless mesh networks. It is similar to AODV in that it forms a route on-demand when a transmitting computer requests one. However, it uses source routing instead of relying on the routing table at each intermediate device. Determining source routes requires accumulating the address of each device between the source and destination during route discovery. The accumulated path information is cached by nodes processing the route discovery packets. The learned paths are used to route packets. To accomplish source routing, the routed packets contain the address of each device the packet will traverse.

3 This may result in high overhead for long paths or large addresses, like (Internet Protocol v6) IPv6. To avoid using source routing, DSR optionally defines a flow id option that allows packets to be forwarded on a hop-by-hop basis. This protocol is truly based on source routing whereby all the routing information is maintained (continually updated) at mobile nodes. It has only 2 major phases which are Route Discovery and Route Maintenance. Route Reply would only be generated if the message has reached the intended destination node (route record which is initially contained in Route Request would be inserted into the Route Reply). To return the Route Reply, the destination node must have a route to the source node. If the route is in the Destination Node's route cache, the route would be used. Otherwise, the node will reverse the route based on the route record in the Route Reply message header (symmetric links). In the event of fatal transmission, the Route Maintenance Phase is initiated whereby the Route Error packets are generated at a node. The erroneous hop will be removed from the node's route cache; all routes containing the hop are truncated at that point. Again, the Route Discovery Phase is initiated to determine the most viable route. For information on other similar protocols, see the ad hoc routing protocol list. DSR is an on-demand protocol designed to restrict the bandwidth consumed by control packets in ad hoc wireless networks by eliminating the periodic table-update messages required in the tabledriven approach. The major difference between this and the other on-demand routing protocols is that it is beacon-less and hence does not require periodic hello packet (beacon) transmissions, which are used by a node to inform its neighbors of its presence. The basic approach of this protocol (and all other on-demand routing protocols) during the route construction phase is to establish a route by flooding Route Request packets in the network. The destination node, on receiving a Route Request packet, responds by sending a Route Reply packet back to the source, which carries the route traversed by the Route Request packet received. Consider a source node that does not have a route to the destination. When it has data packets to be sent to that destination, it initiates a Route Request packet. This Route Request is flooded throughout the network. Each node, upon receiving a Route Request packet, rebroadcasts the packet to its neighbors if it has not forwarded already or if the node is not the destination node, provided the packet s time to live (TTL) counter has not exceeded. Each Route Request carries a sequence number generated by the source node and the path it has traversed. A node, upon receiving a Route Request packet, checks the sequence number on the packet before forwarding it. The packet is forwarded only if it is not a duplicate Route Request. The sequence number on the packet is used to prevent loop formations and to avoid multiple transmissions of the 198 same Route Request by an intermediate node that receives it through multiple paths. Thus, all nodes except the destination forward a Route Request packet during the route construction phase. A destination node, after receiving the first Route Request packet, replies to the source node through the reverse path the Route Request packet had traversed. Nodes can also learn about the neighboring routes traversed by data packets if operated in the promiscuous mode (the mode of operation in which a node can receive the packets that are neither broadcast nor addressed to itself). This route cache is also used during the route construction phase. If an intermediate node receiving a Route Request has a route to the destination node in its route cache, then it replies to the source node by sending a Route Reply with the entire route information from the source node to the destination node. IV. DISTANCE VECTOR ROUTING A Distance Vector Routing Protocol is one of the two major classes of routing protocols used in packetswitched networks for computer communications, the other major class being the link-state protocol. In distance vector routing each router maintains a routing table indexed by and containing one entry for each router in subnet. This entry contains two parts, the preferred outgoing line to use for that destination and an estimate of the time or distance to that destination. The metric used might be number of hops, time delay in milliseconds etc. The router is assumed to know the distance to each of its neighbors. If the metric is hops, the distance is just one hop. 4.1 Client-Server Numerous applications run in a client-server environment, a server is anything that has some resource that can be shared. There are compute servers, which provide computing power; print servers, which manage a collection of printers; disk servers, which provide networked disk space; and web servers, which store web pages. A client is simply any other entity that wants to gain access to a particular server. A network socket is a lot like an electrical socket. Various plugs around the network have a standard way of delivering their payload. Anything that understands the standard protocol can plug in to the socket and communicate. Internet protocol (IP) is a low-level routing protocol that breaks data into small packets and sends them to an address across a network, which does not guarantee to deliver said packets to the destination. Transmission Control Protocol (TCP) is a higher-level protocol that manages to reliably transmit data. A third protocol, User Datagram Protocol (UDP), sits next to TCP and can be used directly to support fast, connectionless, unreliable transport of packets. The notion of a socket allows as single computer to serve many different clients at once, as well as serving many different types of information.

4 This feat is managed by the introduction of a port, which is a numbered socket on a particular machine. A server process is said to listen to a port until a client connects to it. A server is allowed to accept multiple clients connected to the same port number, although each session is unique. To mange multiple client connections, a server process must be multithreaded or have some other means of multiplexing the simultaneous I/O (Input/Output). The client/server model is particularly recommended for networks requiring a high degree of reliability, the main advantages being: Centralized resources: given that the server is the centre of the network, it can manage resources that are common to all users, for example: a central database would be used to avoid problems caused by redundant and inconsistent data Improved security: as the number of entry points giving access to data is not so important Server level administration: as clients do not play a major role in this model, they require less administration Scalable network: thanks to this architecture it is possible to remove or add clients without affecting the operation of the network and without the need for major modification Client/Server architecture also has the following drawbacks: Increased cost: due to the technical complexity of the server Weak link: the server is the only weak link in the client/server network, given that the entire network is built around it. Fortunately, the server is highly fault tolerant. A client/server system operates as outlined in the following Figure 1. The client sends a request to the server using its IP address and the port, which is reserved for a particular service running on the server. The server receives the request and responds using the client IP address and port. traffic is routed by on-conzone nodes and LP traffic is routed out of the conzone. A. Network Formation in CAR In the network formation all the nodes are connected and depth is assigned to all nodes. Initially all the nodes are in off-conzone. Node N1 is considered as a critical area node. Node N1 is connected to N2, N2 is connected to N3, N4 and N5. Nodes N3, N4 and N5 are connected to Sink. In sink there are three JPanels two LP JPanels and one HP JPanel. CAR forms a HP network, nodes forwarding HP data forms HP network, by dividing nodes in the network as congestion zone nodes and off-conzone nodes. Only on-conzone nodes will forward the HP data. LP data generated inside the conzone is routed out of the conzone. HP network formation is very difficult if the data source is moving often and often and congestion zone is changing frequently or if the HP traffic is short-lived. So one limitation with CAR is it requires some overhead to discover the congestion zone if the conzone is changing frequently. So to address the mobility of data sources MCAR is used. In many applications sensor networks are characterized by low mobility, in such cases CAR is used. MCAR is used for high mobility applications. Figure 2: Network Formation in CAR Figure 1: Client-Server System V. CAR CAR comprises three steps: network formation, conzone discovery, and differentiated routing. The combination of these functions segments the network into on-conzone and off-conzone nodes. Only HP B. Conzone Discovery in CAR In this module Nodes discover if they are on the Conzone by using the Conzone discovery mechanism. A Conzone must be then discovered from that neighborhood to the sink for the delivery of HP data. To do this, critical area nodes broadcast discover Conzone to sink (To_Sink) messages. This message includes the ID of the source and its depth and is sent to all neighbors. When a node hears more than threshold Thre_Alpha distinct To_Sink messages coming from its neighbors, it marks itself as onconzone and if it is not Sink it propagates a To_Sink message with its ID and depth to its neighbors. If it is Sink it will not braodcast To_Sink message simply it marks itself as it is in conzone. 199

5 If To_Sink messages received by node is not greater than Thre_Alpha then the node marks itself as it is in off-conzone.thre_alpha is given by Dx*Bx*Nx where Dx is depth, Bx is some constant setted according to requirement and Nx is Neighborhood size (the number of nodes within the communication range). C. Differentiated Routing in CAR Once the Conzone is discovered, in differentiated routing, HP data is routed in the conzone, and LP data is routed off the Conzone. LP data generated inside the conzone is routed out of the conzone. HP data is received from Sink in HP JPanel and LP data is received in either of two JPanels. Compared to existing systems like AODV, CAR increase the fraction of HP data delivery and decrease delay and jitter for such delivery while using energy more uniformly in the deployment. CAR also routes an appreciable amount of LP data in the presence of congestion. MCAR maintains HP data delivery rates in the presence of mobility and the route setup and teardown times associated with the HP flows are minimal. Both CAR and MCAR support effective HP data delivery in the presence of congestion. CAR is better suited for static networks with long-duration HP floods. For bursty HP traffic and/or mobile HP sources, MCAR is a better fit. VI. MCAR MCAR comprises three steps: network formation, setting modes and routing data. A. Network Formation in MCAR In the network formation all the nodes are connected and depth is assigned to all nodes. Unlike CAR, MCAR does not form an HP network instead HP paths are dynamically created, since the sources or sinks are expected to be mobile. B. Setting Modes and Routing Data in MCAR In setting modes each node in a network can be in one of the three modes: LP mode, HP mode or shadow mode. A node dynamically changes its state and route the appropriate data. LP Mode: In this mode, nodes forward LP data. All nodes in the network are initially in the LP mode. Upon receiving an LP data, nodes remain in the LP mode and forwards LP data, if a node in the LP mode receives an HP data, it transitions to the HP mode and forwards HP data. HP Mode: Nodes in the path of HP data are in the HP mode. Node that forward HP data would change as HP mode. If a node in this mode receives an HP data it stays in the same mode and forwards HP data. If a node in this mode receives an LP data either it changes to LP mode and forwards LP data or it changes to shadow mode and drops the LP data. Shadow Mode: In this mode if node receives HP data it transitions to the HP mode and forwards HP data. If a node receives LP data it drops the LP data.the drawback of MCAR is it neglects the service provided to LP data when the node turns to shadow mode it drops the LP data. VII. CONCLUSION In this System, addressed data delivery issues in the presence of congestion in Wireless Sensor Networks. We proposed CAR, which is a differentiated routing protocol and uses data prioritization. We also developed MCAR, which deals with mobility and dynamics in the sources of HP data. REFERENCES [1] Draft Supplement to Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Medium Access Control (MAC) Enhancements for Quality of Service (QoS), IEEE e/ D4.0, Nov [2] G.-S. Ahn, S.G. Hong, E. Miluzzo, A.T. Campbell, and F. Cuomo, Funneling-MAC: A Localized, Sink-Oriented MAC for Boosting Fidelity in Sensor Networks, Proc. Fourth ACM Conf. Embedded Networked Sensor Systems (SenSys), [3] G.-S. Ahn, L.-H. Sun, A. Veres, and A.T. Campbell, Swan: Service Differentiation in Stateless Wireless Ad Hoc Networks, Proc. IEEE INFOCOM, [4] K. Akkaya and M.F. Younis, An Energy-Aware QoS Routing Protocol for Wireless Sensor Networks, Proc. 23rd IEEE Int l Conf. Distributed Computing Systems (ICDCS 03), pp , [5] S.R. Das, C.E. Perkins, and E.M. Belding-Royer, Performance Comparison of Two On-Demand Routing Protocols for Ad Hoc Networks, Proc. IEEE INFOCOM 00, pp. 3-12, [6] C.T. Ee and R. Bajcsy, Congestion Control and Fairness for Many-to-One Routing in Sensor Networks, Proc. Second ACM Conf. Embedded Networked Sensor Systems (SenSys 04), pp , [7] E. Felemban, C.-G. Lee, and E. Ekici, MMSPEED: Multipath Multi-SPEED Protocol for QoS Guarantee of Reliability and Timeliness in Wireless Sensor Networks, IEEE Trans. Mobile Computing, vol. 6, pp , [8] T. He, J.A. Stankovic, C. Lu, and T. Abdelzaher, Speed: A Stateless Protocol for Real-Time Communication in Sensor Networks, Proc. 23rd IEEE Int l Conf. Distributed Computing Systems (ICDCS), [9] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, System Architecture Directions for Network Sensors, Proc. Ninth Int l Conf. Architectural Support for Programming Languages and Operating Systems (ASPLOS 00), Nov [10] B. Hull, K. Jamieson, and H. Balakrishnan, Mitigating Congestion in Wireless Sensor Networks, Proc. Second ACM Conf. Embedded Networked Sensor Systems (SenSys), [11]Eyesifxv2 Version 2. Infineon,

6 [12] C. Intanagonwiwat, R. Govindan, and D. Estrin, Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks, Proc. ACM MobiCom 00, Aug [13] D.B. Johnson and D.A. Maltz, Dynamic Source Routing in Ad Hoc Wireless Networks, Mobile Computing, pp , Kluwer Academic Publishers, Feb [14] B. Karp and H. Kung, GPSR: Greedy Perimeter Stateless Routing for Wireless Networks, Proc. ACM MobiCom, [15] C. Lu, B. Blum, T. Abdelzaher, J. Stankovic, and T. He, RAP: A Real-Time Communication Architecture for Large-Scale Wireless Sensor Networks, Proc. Eighth IEEE Real-Time and Embedded Technology and Applications Symp. (RTAS 02), pp , [16] S. Madden, M. Franklin, J. Hellerstein, and W. Hong, Tag: A Tiny Aggregation Service for Ad-Hoc Sensor Networks, Proc. Fifth Symp. Operating System Design and Implementation (OSDI), [17] ns2: Network Simulator, [18] C.E. Perkins and E.M. Royer, Ad Hoc On-Demand Distance Vector Routing, Proc. Second IEEE Workshop Mobile Computing Systems and Applications (WMCSA 99), Feb [19] J. Polastre, J. Hill, and D. Culler, Versatile Low Power Media Access for Wireless Sensor Networks, Proc. Second ACM Conf. Embedded Networked Sensor Systems (SenSys), [20] S. Rangwala, R. Gummadi, R. Govindan, and K. Psounis, Interference-Aware Fair Rate Control in Wireless Sensor Networks, Proc. ACM SIGCOMM, [21] Raju Kumar,Riccardo Crepaldi,Hosam Rowaihy,Alber F.Harris,Guohong Cao,Michele Zorzi,Thomas F.La Porta, Mitigating Performance Degradation in Congested Sensor Networks, (IEEE Transaction Paper on Mobile Computing, JUNE 2008). [22] Charles E.Perkins,Elizabeth M.Royer, Ad-hoc Ondemand Distance Vector Routing, (IEEE Workshop Mobile Computing Systems and Applications FEB 1999). 201