14-10-2016, 04:17 PM
[attachment=73045]
ABSTRACT
We study routing misbehavior in MANETs (Mobile Ad Hoc Networks) in this paper. In general, routing protocols for MANETs are designed based on the assumption that all participating nodes are fully cooperative. However, due to the open structure and scarcely available battery-based energy, node misbehaviors may exist. One such routing misbehavior is that some selfish nodes will participate in the route discovery and maintenance processes but refuse to forward data packets. In this paper, we propose the 2ACK scheme that serves as an add-on technique for routing schemes to detect routing misbehavior and to mitigate their adverse effect. The main idea of the 2ACK scheme is to send two-hop acknowledgment packets in the opposite direction of the routing path. In order to reduce additional routing overhead, only a fraction of the received data packets are acknowledged in the 2ACK scheme. Analytical and simulation results are presented to evaluate the performance of the proposed scheme.
INTRODUCTION
The system is acknowledgement based approach for detection of routing misbehavior in MANET. Here MANET is expanded as Mobile Ad-hoc Network. It is collection of mobile nodes which communicate with each other via wireless links. In between nodes there will be routers. Now, from one node to another node packets are transmitted. During this process the packets from source to destination may be transmitted through intermediate nodes. For transmitting packets from source to destination there may be several routes. In this context routing is important operation in the function of MANET. The operation of MANET also doesn’t depend on existing infrastructure base stations. Thus routing is dynamic in MANET. Since it is a wireless network, network topology rapidly changes. Now, routing of packets becomes more complex in this MANET which is large scale mobile dynamic network. Even in MANET there may be two types:
1. Closed MANET
2. Open MANET
In closed MANET all nodes co-operate each other with common goals. In open MANET there is no coordination among nodes. This again increases complexity of routing. In this environment of complex routing there may be routing misbehavior. Routing misbehavior means the direction of routing to destination suddenly changes in a wrong way. Now, we are introducing a system which detects misbehavior more efficiently and accurately with acknowledgement. This scheme is also called 2ACK scheme. The idea is when a packet forwards to next hop successfully the next hop will send an acknowledgement to the previous node to indicate the route is correct up to so far. This system is implementing 2ACK scheme using DSR protocol.
1.1 Purpose
The main purpose of the system is detection of routing misbehavior in a complex large scale heterogeneous mobile dynamic network in transmitting data packets from source to destination. It also aims to detect misbehavior of routing more efficiently, accurately, fastly. Its objective and main purpose is low false alarm rate, low missed detection rate. The purpose of using 2ACK scheme is to enhance the effect of DSR protocol.
1.2 Existing System
The existing system works with DSR algorithm in which we have the overhead in sending full data packet as acknowledgement. This can be eliminated in our proposed system. And in this we also detect the link misbehaviors.
1.3 Proposed System
In our proposed system we are using a special scheme called 2ACK in order to detect the routing misbehaviors in mobile ad-hoc networks. This scheme is an add on technique to the dsr algorithm.
1.4 Project Scope
The scope of this system is to provide efficient, accurate routing of data packets in heterogeneous mobile dynamic network MANET, so that the users working at different workstations in MANET cannot suffer from congestion and delay in transmission.
REQUIREMENTS
2.1 SDLC Methodology
This document play a vital role in the development of life cycle (SDLC) as it describes the complete requirement of the system. It means for use by developers and will be the basic during testing phase. Any changes made to the requirements in the future will have to go through formal change approval process.
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration models.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with a client reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.
The steps for Spiral Model can be generalized as follows:
• The new system requirements are defined in as much details as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
• A preliminary design is created for the new system.
• A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
• A second prototype is evolved by a fourfold procedure:
Evaluating the first prototype in terms of its strengths, weakness, and risks.
Defining the requirements of the second prototype.
Planning an designing the second prototype.
Constructing and testing the second prototype.
• At the customer option, the entire project can be aborted if the risk is deemed too great. Risk factors might involved development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer’s judgment, result in a less-than-satisfactory final product.
• The existing prototype is evaluated in the same manner as was the previous prototype, and if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
• The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
• The final system is constructed, based on the refined prototype.
• The final system is thoroughly evaluated and tested. Routine maintenance is carried on a continuing basis to prevent large scale failures and to minimize down time.
Advantages
• Estimates(i.e. budget, schedule etc .) become more relistic as work progresses, because important issues discoved earlier.
• It is more able to cope with the changes that are software development generally entails.
• Software engineers can get their hands in and start woring on the core of a project earlier.
2.2 Functional Requirements
• Select network
• Select the nodes, routers
• Chose source and destination nodes
• Send data packets to destination
• Apply 2ACK scheme
• Finally show the output
2.3 Non- Functional Requirements
The major non-functional Requirements of the system are as follows
• Usability
The system is designed with completely automated process hence there is no or less user intervention.
• Reliability
The system is more reliable because of the qualities that are inherited from the
chosen platform java. The code built by using java is more reliable.
• Performance
This system is developing in the high level languages and using the advanced front-end and back-end technologies it will give response to the end user on client system with in very less time.
• Supportability
The system is designed to be the cross platform supportable. The system is supported on a wide range of hardware and any software platform, which is having JVM, built into the system.
• Implementation
The system is implemented in web environment. The apache tomcat is used as the web server and windows xp professional is used as the platform.
• Interface The user interface is based on HTML and XHTML.
2.4 Hardware Requirements
• Pentium 4 processor
• 1 GB RAM
• 80 GB Hard Disk Space
2.5 Software Requirements
• Microsoft Windows XP Professional
• JDK 6.0
• Flash player
REVIEW OF LITERATURE
3.1 Introduction
A Review of Literature is a high-level capsule version of the entire System analysis and Design Process. The study begins by classifying the problem definition. Feasibility is to determine if it’s worth doing. Once an acceptance problem definition has been generated, the analyst develops a logical model of the system. A search for alternatives is analyzed carefully. There are 3 parts in Literature Survey.
3.2 Technical Survey
Evaluating the technical feasibility is the trickiest part of a feasibility study. This is because, at this point in time, not too many detailed design of the system, making it difficult to access issues like performance, costs on (on account of the kind of technology to be deployed) etc. A number of issues have to be considered while doing a technical analysis. Understand the different technologies involved in the proposed system before commencing the project we have to be very clear about what are the technologies that are to be required for the development of the new system. Find out whether the organization currently possesses the required technologies. Is the required technology available with the organization?
3.3 Operational Survey
Proposed project is beneficial only if it can be turned into information systems that will meet the organizations operating requirements. Simply stated, this test of feasibility asks if the system will work when it is developed and installed. Are there major barriers to Implementation? Here are questions that will help test the operational feasibility of a project Is there sufficient support for the project from management from users? If the current system is well liked and used to the extent that persons will not be able to see reasons for change, there may be resistance.
Are the current business methods acceptable to the user? If they are not, Users may welcome a change that will bring about a more operational and useful systems.
Have the user been involved in the planning and development of the project?
Early involvement reduces the chances of resistance to the system and in general and increases the likelihood of successful project.
Since the proposed system was to help reduce the hardships encountered. In the existing manual system, the new system was considered to be operational feasible.
3.4 Economic Survey
Economic feasibility attempts 2 weigh the costs of developing and implementing a new system, against the benefits that would accrue from having the new system in place. This feasibility study gives the top management the economic justification for the new system. A simple economic analysis which gives the actual comparison of costs and benefits are much more meaningful in this case. In addition, this proves to be a useful point of reference to compare actual costs as the project progresses. There could be various types of intangible benefits on account of automation. These could include increased customer satisfaction, improvement in product quality better decision making timeliness of information, expediting activities, improved accuracy of operations, better documentation and record keeping, faster retrieval of information, better employee morale.
3.5 The 2ACK scheme
The watchdog detection mechanism has a very low overhead. Unfortunately, the watchdog technique suffers from several problems such as ambiguous collisions, receiver collisions, and limited transmission power. The main issue is that the event of successful packet reception can only be accurately determined at the receiver of the next-hop link, but the watchdog technique only monitors the transmission from the sender of the next-hop link. Noting that a misbehaving node can either be the sender or the receiver of the next-hop link, we focus on the problem of detecting misbehaving links instead of misbehaving nodes. In the next-hop link, a misbehaving sender or a misbehaving receiver has a similar adverse effect on the data packet: It will not be forwarded further. The result is that this link will be tagged. Our approach discussed here significantly simplifies the detection mechanism.
Details of the 2ACK Scheme
The 2ACK scheme is a network-layer technique to detect misbehaving links and to mitigate their effects. It can be implemented as an add-on to existing routing protocols for
MANETs, such as DSR. The 2ACK scheme detects misbehavior through the use of a new type of acknowledgment packet, termed 2ACK. A 2ACK packet is assigned a fixed route of two hops (three nodes) in the opposite direction of the data traffic route.
Suppose that N1, N2, and N3 are three consecutive nodes (triplet) along a route. The route from a source node, S, to a destination node, D, is generated in the Route Discovery
phase of the DSR protocol. When N1 sends a data packet to N2 and N2 forwards it to N3, it is unclear to N1 whether N3 receives the data packet successfully or not. Such an ambiguity exists even when there are no misbehaving nodes. The problem becomes much more severe in open MANETs with potential misbehaving nodes. The 2ACK scheme requires an explicit acknowledgment to be sent by N3 to notify N1 of its successful reception of a data packet: When node N3 receives the data packet successfully, it sends out a 2ACK packet over two hops to N1 (i.e., the opposite direction of the routing path as shown), with the ID of the corresponding data packet. The triplet (N1 -> N2 -> N3) is derived from the route of the original data traffic. Such a triplet is used by N1 to monitor the link N2 -> N3. For convenience of presentation, we term N1 in the triplet (N1 -> N2 ->N3) the 2ACK packet receiver or the observing node and N3 the 2ACK packet sender.
Such a 2ACK transmission takes place for every set of triplets along the route. Therefore, only the first router from the source will not serve as a 2ACK packet sender. The last router just before the destination and the destination will not serve as 2ACK receivers.4
To detect misbehavior, the 2ACK packet sender maintains a list of IDs of data packets that have been sent out but have not been acknowledged. For example, after N1 sends a data packet on a particular path, say, (N1 ->N2 ->N3) it adds the data ID to LIST i.e., on its list corresponding to N2 ->N3.
A counter of forwarded data packets, Cpkts, is incremented simultaneously. At N1, each ID will stay on the list for τ seconds, the timeout for 2ACK reception. If a 2ACK packet corresponding to this ID arrives before the timer expires, the ID will be removed from the list. Otherwise, the ID will be removed at the end of its timeout interval and a counter called Cmis will be incremented. When N3 receives a data packet, it determines whether it needs to send a 2ACK packet to N1. In order to reduce the additional routing overhead caused by the 2ACK scheme, only a fraction of the data packets will be acknowledged via 2ACK packets. Such a fraction is termed the acknowledgment ratio, Rack. By varying Rack, we can dynamically tune the overhead of 2ACK packet transmissions. Node N1 observes the behavior of link N2 -> N3 for a period of time termed Tobs. At the end of the observation period, N1 calculates the ratio of missing 2ACK packets as Cmis/Cpkts and compares it with a threshold Rmis. If the ratio is greater than Rmis, link N2 -> N3 is declared misbehaving and N1 sends out an RERR (or the misbehavior report) packet. Since only a fraction of the received data packets are acknowledged, Rmis should satisfy Rmis > 1 - Rack in order to eliminate false alarms caused by such a partial acknowledgment technique. Each node receiving or overhearing such an RERR marks the link N2 ->N3 as misbehaving and adds it to the blacklist of such misbehaving links that it maintains. When a node starts its own data traffic later, it will avoid using such misbehaving links as a part of its route. The 2ACK scheme can be summarized in the pseudocode provided in the appendix for the 2ACK packet sender side (N3) and the observing node side (N1).
CHAPTER-4
SOFTWARE REQUIREMENT ANALYSIS
4.1 Overview
The first step in developing anything is to state the requirements. This applies just as much to leading edge research as to simple programs and to personal programs, as well as to large team efforts. Being vague about your objective only postpones decisions to a later stage where changes are much more costly.
The problem statement should state what is to be done and not how it is to be done. It should be a statement of needs, not a proposal for a solution. A user manual for the desired system is a good problem statement. The requestor should indicate which features are mandatory and which are optional, to avoid overly constraining design decisions. The requestor should avoid describing system internals, as this restricts implementation flexibility. Performance specifications and protocols for interaction with external systems are legitimate requirements. Software engineering standards, such as modular construction, design for testability, and provision for future extensions, are also proper.
Many problems statements, from individuals, companies, and government agencies, mixture requirements with design decisions. There may sometimes be a compelling reason to require a particular computer or language; there is rarely justification to specify the use of a particular algorithm. The analyst must separate the true requirements from design and implementation decisions disguised as requirements. The analyst should challenge such pseudo requirements, as they restrict flexibility. There may be politics or organizational reasons for the pseudo requirements, but at least the analyst should recognize that these externally imposed design decisions are not essential features of the problem domain.
A problem statement may have more or less detail. A requirement for a conventional product, such as a payroll program or a billing system, may have considerable detail. A requirement for a research effort in a new area may lack many details, but presumably the research has some objective, which should be clearly stated.
Most problem statements are ambiguous, incomplete, or even inconsistent. Some requirements are just plain wrong. Some requirements, although precisely stated, have unpleasant consequences on the system behavior or impose unreasonable implementation costs. Some requirements seem reasonable at first but do not work out as well as the request or thought. The problem statement is just a starting point for understanding the problem, not an immutable document. The purpose of the subsequent analysis is to fully understand the problem and its implications. There is no reasons to expect that a problem statement prepared without a fully analysis will be correct.
The analyst must work with the requestor to refine the requirements so they represent the requestor’s true intent. This involves challenging the requirements and probing for missing information. The psychological, organizational, and political considerations of doing this are beyond the scope of this book, except for the following piece of advice: If you do exactly what the customer asked for, but the result does not meet the customer’s real needs, you will probably be blamed anyway.
Problem in the existing system: In general , we are transmitting the data packets using some routing algorithms such as DSDV, DSR etc. These algorithms may allocate the path to the destination in a network. In DSR we have two steps. First Route Discovery and the second one is Route Maintenance. In the Route Discovery step it chooses different paths to the corresponding destination. In Route Maintenance step it maintains the route to the destination until it send out the packets. But in these cases there may be a chance to lost the data. If we are using the acknowledgement scheme to notify the packet delivery, it may not be feasible for manets. For eg a node knows the packet status of its neighbors only. Then in order to achieve the high packet delivery we are introducing the 2ACK scheme which sends two-hop acknowledgements.
4.2 Modules
In our proposed system we have three modules as follows
1. Network connection module
2. Data transmitting module
3. Routing module
Network connection module This module aims to provide various services to be accessed by source node in mobile ad-hoc network in order to establish connection with other dynamic nodes and also destination node. It supports following services:
Establishing network connection
TCP connection
UDP connection
Change connection
Disconnect
Data transmitting module This module provides various services related to transmission of data from source to destination, forwarding data from one node to next intermediate node, sending acknowledgement to source to destination, acknowledgement to destination by source so on. The following are various services offered by this module:
Detecting misbehavior
Performance of routing layer
Communicating with other nodes
Sharing resources
Sending acknowledgement
Sending packets
Receiving packets
Routing In this module we mainly have route discovery and route maintenance. This module is accessed by source node and intermediate nodes during data transmission to implement dynamic routing process. The objective of this module is:
Computing routing table
Find route to the destination
Find route to next hop
Updating dynamic routing table
Change routes dynamically
ABSTRACT
We study routing misbehavior in MANETs (Mobile Ad Hoc Networks) in this paper. In general, routing protocols for MANETs are designed based on the assumption that all participating nodes are fully cooperative. However, due to the open structure and scarcely available battery-based energy, node misbehaviors may exist. One such routing misbehavior is that some selfish nodes will participate in the route discovery and maintenance processes but refuse to forward data packets. In this paper, we propose the 2ACK scheme that serves as an add-on technique for routing schemes to detect routing misbehavior and to mitigate their adverse effect. The main idea of the 2ACK scheme is to send two-hop acknowledgment packets in the opposite direction of the routing path. In order to reduce additional routing overhead, only a fraction of the received data packets are acknowledged in the 2ACK scheme. Analytical and simulation results are presented to evaluate the performance of the proposed scheme.
INTRODUCTION
The system is acknowledgement based approach for detection of routing misbehavior in MANET. Here MANET is expanded as Mobile Ad-hoc Network. It is collection of mobile nodes which communicate with each other via wireless links. In between nodes there will be routers. Now, from one node to another node packets are transmitted. During this process the packets from source to destination may be transmitted through intermediate nodes. For transmitting packets from source to destination there may be several routes. In this context routing is important operation in the function of MANET. The operation of MANET also doesn’t depend on existing infrastructure base stations. Thus routing is dynamic in MANET. Since it is a wireless network, network topology rapidly changes. Now, routing of packets becomes more complex in this MANET which is large scale mobile dynamic network. Even in MANET there may be two types:
1. Closed MANET
2. Open MANET
In closed MANET all nodes co-operate each other with common goals. In open MANET there is no coordination among nodes. This again increases complexity of routing. In this environment of complex routing there may be routing misbehavior. Routing misbehavior means the direction of routing to destination suddenly changes in a wrong way. Now, we are introducing a system which detects misbehavior more efficiently and accurately with acknowledgement. This scheme is also called 2ACK scheme. The idea is when a packet forwards to next hop successfully the next hop will send an acknowledgement to the previous node to indicate the route is correct up to so far. This system is implementing 2ACK scheme using DSR protocol.
1.1 Purpose
The main purpose of the system is detection of routing misbehavior in a complex large scale heterogeneous mobile dynamic network in transmitting data packets from source to destination. It also aims to detect misbehavior of routing more efficiently, accurately, fastly. Its objective and main purpose is low false alarm rate, low missed detection rate. The purpose of using 2ACK scheme is to enhance the effect of DSR protocol.
1.2 Existing System
The existing system works with DSR algorithm in which we have the overhead in sending full data packet as acknowledgement. This can be eliminated in our proposed system. And in this we also detect the link misbehaviors.
1.3 Proposed System
In our proposed system we are using a special scheme called 2ACK in order to detect the routing misbehaviors in mobile ad-hoc networks. This scheme is an add on technique to the dsr algorithm.
1.4 Project Scope
The scope of this system is to provide efficient, accurate routing of data packets in heterogeneous mobile dynamic network MANET, so that the users working at different workstations in MANET cannot suffer from congestion and delay in transmission.
REQUIREMENTS
2.1 SDLC Methodology
This document play a vital role in the development of life cycle (SDLC) as it describes the complete requirement of the system. It means for use by developers and will be the basic during testing phase. Any changes made to the requirements in the future will have to go through formal change approval process.
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration models.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with a client reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.
The steps for Spiral Model can be generalized as follows:
• The new system requirements are defined in as much details as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
• A preliminary design is created for the new system.
• A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
• A second prototype is evolved by a fourfold procedure:
Evaluating the first prototype in terms of its strengths, weakness, and risks.
Defining the requirements of the second prototype.
Planning an designing the second prototype.
Constructing and testing the second prototype.
• At the customer option, the entire project can be aborted if the risk is deemed too great. Risk factors might involved development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer’s judgment, result in a less-than-satisfactory final product.
• The existing prototype is evaluated in the same manner as was the previous prototype, and if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
• The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
• The final system is constructed, based on the refined prototype.
• The final system is thoroughly evaluated and tested. Routine maintenance is carried on a continuing basis to prevent large scale failures and to minimize down time.
Advantages
• Estimates(i.e. budget, schedule etc .) become more relistic as work progresses, because important issues discoved earlier.
• It is more able to cope with the changes that are software development generally entails.
• Software engineers can get their hands in and start woring on the core of a project earlier.
2.2 Functional Requirements
• Select network
• Select the nodes, routers
• Chose source and destination nodes
• Send data packets to destination
• Apply 2ACK scheme
• Finally show the output
2.3 Non- Functional Requirements
The major non-functional Requirements of the system are as follows
• Usability
The system is designed with completely automated process hence there is no or less user intervention.
• Reliability
The system is more reliable because of the qualities that are inherited from the
chosen platform java. The code built by using java is more reliable.
• Performance
This system is developing in the high level languages and using the advanced front-end and back-end technologies it will give response to the end user on client system with in very less time.
• Supportability
The system is designed to be the cross platform supportable. The system is supported on a wide range of hardware and any software platform, which is having JVM, built into the system.
• Implementation
The system is implemented in web environment. The apache tomcat is used as the web server and windows xp professional is used as the platform.
• Interface The user interface is based on HTML and XHTML.
2.4 Hardware Requirements
• Pentium 4 processor
• 1 GB RAM
• 80 GB Hard Disk Space
2.5 Software Requirements
• Microsoft Windows XP Professional
• JDK 6.0
• Flash player
REVIEW OF LITERATURE
3.1 Introduction
A Review of Literature is a high-level capsule version of the entire System analysis and Design Process. The study begins by classifying the problem definition. Feasibility is to determine if it’s worth doing. Once an acceptance problem definition has been generated, the analyst develops a logical model of the system. A search for alternatives is analyzed carefully. There are 3 parts in Literature Survey.
3.2 Technical Survey
Evaluating the technical feasibility is the trickiest part of a feasibility study. This is because, at this point in time, not too many detailed design of the system, making it difficult to access issues like performance, costs on (on account of the kind of technology to be deployed) etc. A number of issues have to be considered while doing a technical analysis. Understand the different technologies involved in the proposed system before commencing the project we have to be very clear about what are the technologies that are to be required for the development of the new system. Find out whether the organization currently possesses the required technologies. Is the required technology available with the organization?
3.3 Operational Survey
Proposed project is beneficial only if it can be turned into information systems that will meet the organizations operating requirements. Simply stated, this test of feasibility asks if the system will work when it is developed and installed. Are there major barriers to Implementation? Here are questions that will help test the operational feasibility of a project Is there sufficient support for the project from management from users? If the current system is well liked and used to the extent that persons will not be able to see reasons for change, there may be resistance.
Are the current business methods acceptable to the user? If they are not, Users may welcome a change that will bring about a more operational and useful systems.
Have the user been involved in the planning and development of the project?
Early involvement reduces the chances of resistance to the system and in general and increases the likelihood of successful project.
Since the proposed system was to help reduce the hardships encountered. In the existing manual system, the new system was considered to be operational feasible.
3.4 Economic Survey
Economic feasibility attempts 2 weigh the costs of developing and implementing a new system, against the benefits that would accrue from having the new system in place. This feasibility study gives the top management the economic justification for the new system. A simple economic analysis which gives the actual comparison of costs and benefits are much more meaningful in this case. In addition, this proves to be a useful point of reference to compare actual costs as the project progresses. There could be various types of intangible benefits on account of automation. These could include increased customer satisfaction, improvement in product quality better decision making timeliness of information, expediting activities, improved accuracy of operations, better documentation and record keeping, faster retrieval of information, better employee morale.
3.5 The 2ACK scheme
The watchdog detection mechanism has a very low overhead. Unfortunately, the watchdog technique suffers from several problems such as ambiguous collisions, receiver collisions, and limited transmission power. The main issue is that the event of successful packet reception can only be accurately determined at the receiver of the next-hop link, but the watchdog technique only monitors the transmission from the sender of the next-hop link. Noting that a misbehaving node can either be the sender or the receiver of the next-hop link, we focus on the problem of detecting misbehaving links instead of misbehaving nodes. In the next-hop link, a misbehaving sender or a misbehaving receiver has a similar adverse effect on the data packet: It will not be forwarded further. The result is that this link will be tagged. Our approach discussed here significantly simplifies the detection mechanism.
Details of the 2ACK Scheme
The 2ACK scheme is a network-layer technique to detect misbehaving links and to mitigate their effects. It can be implemented as an add-on to existing routing protocols for
MANETs, such as DSR. The 2ACK scheme detects misbehavior through the use of a new type of acknowledgment packet, termed 2ACK. A 2ACK packet is assigned a fixed route of two hops (three nodes) in the opposite direction of the data traffic route.
Suppose that N1, N2, and N3 are three consecutive nodes (triplet) along a route. The route from a source node, S, to a destination node, D, is generated in the Route Discovery
phase of the DSR protocol. When N1 sends a data packet to N2 and N2 forwards it to N3, it is unclear to N1 whether N3 receives the data packet successfully or not. Such an ambiguity exists even when there are no misbehaving nodes. The problem becomes much more severe in open MANETs with potential misbehaving nodes. The 2ACK scheme requires an explicit acknowledgment to be sent by N3 to notify N1 of its successful reception of a data packet: When node N3 receives the data packet successfully, it sends out a 2ACK packet over two hops to N1 (i.e., the opposite direction of the routing path as shown), with the ID of the corresponding data packet. The triplet (N1 -> N2 -> N3) is derived from the route of the original data traffic. Such a triplet is used by N1 to monitor the link N2 -> N3. For convenience of presentation, we term N1 in the triplet (N1 -> N2 ->N3) the 2ACK packet receiver or the observing node and N3 the 2ACK packet sender.
Such a 2ACK transmission takes place for every set of triplets along the route. Therefore, only the first router from the source will not serve as a 2ACK packet sender. The last router just before the destination and the destination will not serve as 2ACK receivers.4
To detect misbehavior, the 2ACK packet sender maintains a list of IDs of data packets that have been sent out but have not been acknowledged. For example, after N1 sends a data packet on a particular path, say, (N1 ->N2 ->N3) it adds the data ID to LIST i.e., on its list corresponding to N2 ->N3.
A counter of forwarded data packets, Cpkts, is incremented simultaneously. At N1, each ID will stay on the list for τ seconds, the timeout for 2ACK reception. If a 2ACK packet corresponding to this ID arrives before the timer expires, the ID will be removed from the list. Otherwise, the ID will be removed at the end of its timeout interval and a counter called Cmis will be incremented. When N3 receives a data packet, it determines whether it needs to send a 2ACK packet to N1. In order to reduce the additional routing overhead caused by the 2ACK scheme, only a fraction of the data packets will be acknowledged via 2ACK packets. Such a fraction is termed the acknowledgment ratio, Rack. By varying Rack, we can dynamically tune the overhead of 2ACK packet transmissions. Node N1 observes the behavior of link N2 -> N3 for a period of time termed Tobs. At the end of the observation period, N1 calculates the ratio of missing 2ACK packets as Cmis/Cpkts and compares it with a threshold Rmis. If the ratio is greater than Rmis, link N2 -> N3 is declared misbehaving and N1 sends out an RERR (or the misbehavior report) packet. Since only a fraction of the received data packets are acknowledged, Rmis should satisfy Rmis > 1 - Rack in order to eliminate false alarms caused by such a partial acknowledgment technique. Each node receiving or overhearing such an RERR marks the link N2 ->N3 as misbehaving and adds it to the blacklist of such misbehaving links that it maintains. When a node starts its own data traffic later, it will avoid using such misbehaving links as a part of its route. The 2ACK scheme can be summarized in the pseudocode provided in the appendix for the 2ACK packet sender side (N3) and the observing node side (N1).
CHAPTER-4
SOFTWARE REQUIREMENT ANALYSIS
4.1 Overview
The first step in developing anything is to state the requirements. This applies just as much to leading edge research as to simple programs and to personal programs, as well as to large team efforts. Being vague about your objective only postpones decisions to a later stage where changes are much more costly.
The problem statement should state what is to be done and not how it is to be done. It should be a statement of needs, not a proposal for a solution. A user manual for the desired system is a good problem statement. The requestor should indicate which features are mandatory and which are optional, to avoid overly constraining design decisions. The requestor should avoid describing system internals, as this restricts implementation flexibility. Performance specifications and protocols for interaction with external systems are legitimate requirements. Software engineering standards, such as modular construction, design for testability, and provision for future extensions, are also proper.
Many problems statements, from individuals, companies, and government agencies, mixture requirements with design decisions. There may sometimes be a compelling reason to require a particular computer or language; there is rarely justification to specify the use of a particular algorithm. The analyst must separate the true requirements from design and implementation decisions disguised as requirements. The analyst should challenge such pseudo requirements, as they restrict flexibility. There may be politics or organizational reasons for the pseudo requirements, but at least the analyst should recognize that these externally imposed design decisions are not essential features of the problem domain.
A problem statement may have more or less detail. A requirement for a conventional product, such as a payroll program or a billing system, may have considerable detail. A requirement for a research effort in a new area may lack many details, but presumably the research has some objective, which should be clearly stated.
Most problem statements are ambiguous, incomplete, or even inconsistent. Some requirements are just plain wrong. Some requirements, although precisely stated, have unpleasant consequences on the system behavior or impose unreasonable implementation costs. Some requirements seem reasonable at first but do not work out as well as the request or thought. The problem statement is just a starting point for understanding the problem, not an immutable document. The purpose of the subsequent analysis is to fully understand the problem and its implications. There is no reasons to expect that a problem statement prepared without a fully analysis will be correct.
The analyst must work with the requestor to refine the requirements so they represent the requestor’s true intent. This involves challenging the requirements and probing for missing information. The psychological, organizational, and political considerations of doing this are beyond the scope of this book, except for the following piece of advice: If you do exactly what the customer asked for, but the result does not meet the customer’s real needs, you will probably be blamed anyway.
Problem in the existing system: In general , we are transmitting the data packets using some routing algorithms such as DSDV, DSR etc. These algorithms may allocate the path to the destination in a network. In DSR we have two steps. First Route Discovery and the second one is Route Maintenance. In the Route Discovery step it chooses different paths to the corresponding destination. In Route Maintenance step it maintains the route to the destination until it send out the packets. But in these cases there may be a chance to lost the data. If we are using the acknowledgement scheme to notify the packet delivery, it may not be feasible for manets. For eg a node knows the packet status of its neighbors only. Then in order to achieve the high packet delivery we are introducing the 2ACK scheme which sends two-hop acknowledgements.
4.2 Modules
In our proposed system we have three modules as follows
1. Network connection module
2. Data transmitting module
3. Routing module
Network connection module This module aims to provide various services to be accessed by source node in mobile ad-hoc network in order to establish connection with other dynamic nodes and also destination node. It supports following services:
Establishing network connection
TCP connection
UDP connection
Change connection
Disconnect
Data transmitting module This module provides various services related to transmission of data from source to destination, forwarding data from one node to next intermediate node, sending acknowledgement to source to destination, acknowledgement to destination by source so on. The following are various services offered by this module:
Detecting misbehavior
Performance of routing layer
Communicating with other nodes
Sharing resources
Sending acknowledgement
Sending packets
Receiving packets
Routing In this module we mainly have route discovery and route maintenance. This module is accessed by source node and intermediate nodes during data transmission to implement dynamic routing process. The objective of this module is:
Computing routing table
Find route to the destination
Find route to next hop
Updating dynamic routing table
Change routes dynamically