sem
Content
A Three-Tier Framework for Intruder Information Sharing in Sensor Networks
ABSTRACT
Index Modules. 1. Functional and Non- functional requirements. 2. Feasibility Study. 3. SDLC. 4. Conclusion. 5. References.
The project is divided in to four modules 1. Verifiable Intruder Reporting Module 2. Quorum Based Caching module 3. Collaborative Boom filter module. 4. Simulator module
Verifiable Intruder Reporting Module: This module is responsible for detecting the
intruder who penetrated into the system. The detected intruder will be reported to the base station. The intruder information is placed with public access to all the sensors in the network.
Quorum Based Caching Module: This module will deal with caching of information.
Information caching is required for better performance of the system. Since sensors always refer to the intruder information when data transmission is done. The frequent referred data is to be cached by this module.
Collaborative Boom filter Module: This module will filter the data streams based on
the probabilistic data structure.
Simulator Module: This module will deal with the simulation of sensor networks
application. The GUI is built in this module. The Functional Requirements package details behavioral requirements that specify how a proposed system will process and handle information. It details the features and rules that must be present to fully implement the functionality desired
Functional requirements
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7
custom Functional Requirements Business Rules EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 + Data Selection EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 + Data Transmission + Key Generation EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 Features Saving + Key + Key Distribution Functional Requirements describe the features, behavior, business rules and general functionality that the proposed system must support. + Attacker Detection
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7
+ Wake UP DMs
++Request Response Random Node Generator. + Sensor Generation
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7
Figure: Functional Requirements
Note Status: Proposed Phase: 1.0 Priority: Version: 1.0 Difficulty:
Functional Requirements describe the features, behavior, business rules and general functionality that the proposed system must support.
Business Rules
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Detection Trial Version Attacker UnregisteredMarking «Functional Status: Proposed EA 7.1 Unregistered Trial Version » EA 7.1 Unregistered1.0 Version Phase: Trial
Request Response Data Selection T he Business Rules package is a catalogue of explicit business rules which are required to be implemented within the current project. Business Rules are typically executed during program execution and control the processing of information and transactions.
custom Business Logic
EA 7.1 Unregistered Trial Version Key Generation Key Saving EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
Data T ransmission Attacker Detection
Sensor Generation
EA 7.1 Unregistered Trial Version Key Distribution EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre
Wake UP DMs
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
Figure: Business Logic
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
Priority: Medium Difficulty: Medium EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trial Version Version: 1.0 EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trialmust have provision to mark a sensor node as the detected Trial Version The system Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered
attacker. EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
Data Selection
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
«Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The data to be sent to the sensors must be collected first in order send the data to the destination.
Data Transmission «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The data selected can be transmitted across the network to the destination. The system must have a provision to transmit the data from one system to another system.
Key Distribution «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The previously generated keys must be distributed across the network. The system must have a provision to distribute the keys across the sensors of the network safely. The key previously generated and stored into the file system is required to be read by the system and distributed to the sensors over the network.
Key Generation «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The system must have a provision to generate the keys. Keys are used in network security and cryptography streams for data encryption and decryption.
Key Saving «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The system must have a provision to store the generated keys in to the file system safely. The generated keys are required to be saved for future use.
Request Response «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The system must have a provision to simulate the route between the two sensors through the request response method.
Sensor Generation «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The simulator must have a provision to generate the sensors randomly. The generated sensors can be placed on different positions on the screen.
Wake UP DMs «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The system must have a provision to wake up the dms system .
NON FUNCTIONAL REQUIREMENTS The project non functional requirements include the following. y y y y Updating Work status. Problem resolution. Error occurrence in the system. Customer requests.
3.3.1 USABILITY The system is used by the four persons namely Administrator, Project Manager, Developer and the customer. Each person is having their own roles and are separated by the security issues.
3.3.2 RELIABLITY The system is said to be reliable because the entire system was built using java which is most robust language. Reliability refers to the standards of the system.
3.3.3 PERFORMANCE System is highly functional and good in performance. The system must use the minimal set of variables and minimal usage of the control structures will dynamically increase the performance of the system.
3.3.4 SUPPORTABILITY The system is supportable with different platforms and a wide range of machines. the java code used in this project is more flexible and having a feature of platform independence. And also added support for wide range of mobile phone which supports CLDC platform.
3.3.5 IMPLEMENTATION The system would be implemented in a networked and mobile based WAP environment.
3.3.6 INTERFACE This system uses three user interfaces. Most of the project is developed by using the java Swing user interface and some components in mobile interface and customer module in the web based interface. 3.3.7 PACKAGING The entire system was packaged into single package.
3.3.8 LEGAL The legal issues of this project are unknown as that rights are not applicable for the project done for the academics. All the legal rights are sol proprietor of the organization.
CONCLUSION
In this paper, we proposed a three-tier framework for intruder information sharing in sensor networks. The framework consists of a verifiable intruder reporting (VIR) scheme, a quorumbased caching (QBC) scheme for system-wide propagation of intruder information, and a collaborative Bloom Filter (CBF) scheme for local management of intruder information. Extensive analysis and simulation are also conducted to verify the efficiency of the proposed framework as long as the system parameters are carefully chosen.
SYSTEM STUDY
2.1 FEASIBILITY STUDY
The feasibility of the project is analyzed in this phase and business proposal is put forth with a very general plan for the project and some cost estimates. During system analysis the feasibility study of the proposed system is to be carried out. This is to ensure that the proposed system is not a burden to the company. For feasibility analysis, some understanding of the major requirements for the system is essential.
Three key considerations involved in the feasibility analysis are ECONOMICAL FEASIBILITY j TECHNICAL FEASIBILITY j SOCIAL FEASIBILITY
ECONOMICAL FEASIBILITY
This study is carried out to check the economic impact that the system will have on the organization. The amount of fund that the company can pour into the research and development of the system is limited. The expenditures must be justified. Thus the developed system as well within the budget and this was achieved because most of the technologies used are freely available. Only the customized products had to be purchased.
TECHNICAL FEASIBILITY
This study is carried out to check the technical feasibility, that is, the technical requirements of the system. Any system developed must not have a high demand on the available technical resources. This will lead to high demands on the available technical resources. This will lead to high demands being placed on the client. The developed system must have a modest requirement, as only minimal or null changes are required for implementing this system.
SOCIAL FEASIBILITY
The aspect of study is to check the level of acceptance of the system by the user. This includes the process of training the user to use the system efficiently. The user must not feel threatened by the system, instead must accept it as a necessity. The level of acceptance by the users solely depends on the methods that are employed to educate the user about the system and to make him familiar with it. His level of confidence must be raised so that he is also able to make some constructive criticism, which is welcomed, as he is the final user of the system.
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.
ABSTRACT
Index Modules. 1. Functional and Non- functional requirements. 2. Feasibility Study. 3. SDLC. 4. Conclusion. 5. References.
The project is divided in to four modules 1. Verifiable Intruder Reporting Module 2. Quorum Based Caching module 3. Collaborative Boom filter module. 4. Simulator module
Verifiable Intruder Reporting Module: This module is responsible for detecting the
intruder who penetrated into the system. The detected intruder will be reported to the base station. The intruder information is placed with public access to all the sensors in the network.
Quorum Based Caching Module: This module will deal with caching of information.
Information caching is required for better performance of the system. Since sensors always refer to the intruder information when data transmission is done. The frequent referred data is to be cached by this module.
Collaborative Boom filter Module: This module will filter the data streams based on
the probabilistic data structure.
Simulator Module: This module will deal with the simulation of sensor networks
application. The GUI is built in this module. The Functional Requirements package details behavioral requirements that specify how a proposed system will process and handle information. It details the features and rules that must be present to fully implement the functionality desired
Functional requirements
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7
custom Functional Requirements Business Rules EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 + Data Selection EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 + Data Transmission + Key Generation EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 Features Saving + Key + Key Distribution Functional Requirements describe the features, behavior, business rules and general functionality that the proposed system must support. + Attacker Detection
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7
+ Wake UP DMs
++Request Response Random Node Generator. + Sensor Generation
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7 EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7
Figure: Functional Requirements
Note Status: Proposed Phase: 1.0 Priority: Version: 1.0 Difficulty:
Functional Requirements describe the features, behavior, business rules and general functionality that the proposed system must support.
Business Rules
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Detection Trial Version Attacker UnregisteredMarking «Functional Status: Proposed EA 7.1 Unregistered Trial Version » EA 7.1 Unregistered1.0 Version Phase: Trial
Request Response Data Selection T he Business Rules package is a catalogue of explicit business rules which are required to be implemented within the current project. Business Rules are typically executed during program execution and control the processing of information and transactions.
custom Business Logic
EA 7.1 Unregistered Trial Version Key Generation Key Saving EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
Data T ransmission Attacker Detection
Sensor Generation
EA 7.1 Unregistered Trial Version Key Distribution EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre EA 7.1 Unre
Wake UP DMs
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
Figure: Business Logic
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
Priority: Medium Difficulty: Medium EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trial Version Version: 1.0 EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trialmust have provision to mark a sensor node as the detected Trial Version The system Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered
attacker. EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
Data Selection
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
«Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The data to be sent to the sensors must be collected first in order send the data to the destination.
Data Transmission «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The data selected can be transmitted across the network to the destination. The system must have a provision to transmit the data from one system to another system.
Key Distribution «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The previously generated keys must be distributed across the network. The system must have a provision to distribute the keys across the sensors of the network safely. The key previously generated and stored into the file system is required to be read by the system and distributed to the sensors over the network.
Key Generation «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The system must have a provision to generate the keys. Keys are used in network security and cryptography streams for data encryption and decryption.
Key Saving «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The system must have a provision to store the generated keys in to the file system safely. The generated keys are required to be saved for future use.
Request Response «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The system must have a provision to simulate the route between the two sensors through the request response method.
Sensor Generation «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The simulator must have a provision to generate the sensors randomly. The generated sensors can be placed on different positions on the screen.
Wake UP DMs «Functional Status: Proposed » Phase: 1.0
Priority: Medium Version: 1.0
Difficulty: Medium
The system must have a provision to wake up the dms system .
NON FUNCTIONAL REQUIREMENTS The project non functional requirements include the following. y y y y Updating Work status. Problem resolution. Error occurrence in the system. Customer requests.
3.3.1 USABILITY The system is used by the four persons namely Administrator, Project Manager, Developer and the customer. Each person is having their own roles and are separated by the security issues.
3.3.2 RELIABLITY The system is said to be reliable because the entire system was built using java which is most robust language. Reliability refers to the standards of the system.
3.3.3 PERFORMANCE System is highly functional and good in performance. The system must use the minimal set of variables and minimal usage of the control structures will dynamically increase the performance of the system.
3.3.4 SUPPORTABILITY The system is supportable with different platforms and a wide range of machines. the java code used in this project is more flexible and having a feature of platform independence. And also added support for wide range of mobile phone which supports CLDC platform.
3.3.5 IMPLEMENTATION The system would be implemented in a networked and mobile based WAP environment.
3.3.6 INTERFACE This system uses three user interfaces. Most of the project is developed by using the java Swing user interface and some components in mobile interface and customer module in the web based interface. 3.3.7 PACKAGING The entire system was packaged into single package.
3.3.8 LEGAL The legal issues of this project are unknown as that rights are not applicable for the project done for the academics. All the legal rights are sol proprietor of the organization.
CONCLUSION
In this paper, we proposed a three-tier framework for intruder information sharing in sensor networks. The framework consists of a verifiable intruder reporting (VIR) scheme, a quorumbased caching (QBC) scheme for system-wide propagation of intruder information, and a collaborative Bloom Filter (CBF) scheme for local management of intruder information. Extensive analysis and simulation are also conducted to verify the efficiency of the proposed framework as long as the system parameters are carefully chosen.
SYSTEM STUDY
2.1 FEASIBILITY STUDY
The feasibility of the project is analyzed in this phase and business proposal is put forth with a very general plan for the project and some cost estimates. During system analysis the feasibility study of the proposed system is to be carried out. This is to ensure that the proposed system is not a burden to the company. For feasibility analysis, some understanding of the major requirements for the system is essential.
Three key considerations involved in the feasibility analysis are ECONOMICAL FEASIBILITY j TECHNICAL FEASIBILITY j SOCIAL FEASIBILITY
ECONOMICAL FEASIBILITY
This study is carried out to check the economic impact that the system will have on the organization. The amount of fund that the company can pour into the research and development of the system is limited. The expenditures must be justified. Thus the developed system as well within the budget and this was achieved because most of the technologies used are freely available. Only the customized products had to be purchased.
TECHNICAL FEASIBILITY
This study is carried out to check the technical feasibility, that is, the technical requirements of the system. Any system developed must not have a high demand on the available technical resources. This will lead to high demands on the available technical resources. This will lead to high demands being placed on the client. The developed system must have a modest requirement, as only minimal or null changes are required for implementing this system.
SOCIAL FEASIBILITY
The aspect of study is to check the level of acceptance of the system by the user. This includes the process of training the user to use the system efficiently. The user must not feel threatened by the system, instead must accept it as a necessity. The level of acceptance by the users solely depends on the methods that are employed to educate the user about the system and to make him familiar with it. His level of confidence must be raised so that he is also able to make some constructive criticism, which is welcomed, as he is the final user of the system.
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.
