A Three-Tier Framework For Intruder Information Sharing in Sensor Networks

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
support.system will process and handle information. It details the features and rules that must
proposed
functionality
be present thatimplement
to fully the proposedthesystem must
functionality desired
features, behavior, business rules and general
Functional requirements
Functional Requirements describe the
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.

custom Functional Requirements
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered

Business Rules Trial Version EA 7.
+ Attacker Detection
+ Data Selection
+ Data Transmission
+ Key Distribution
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered
+ Key Generation Trial Version EA 7.
Features
+ Key Saving
++Request
RandomResponse
Node Generator.
+ Sensor Generation
+ Wake UP DMs

Figure: Functional Requirements
Note
Status: Proposed Priority: Difficulty:
Phase: 1.0 Version: 1.0
Functional Requirements describe the features, behavior, business rules
and general functionality that the proposed system must support.
Business Rules
and transactions.
execution and control the processing of information
Rules are typically executed during program
implemented within the current project. Business
explicit business rules which are required to be
The Business Rules package is a catalogue of
custom Business Logic

EA 7.1 Unregistered Trial Version EAKey7.1 Unregistered
Generation
Trial Version Sensor
Key Saving
EA 7.1 Unregistered Trial Version EA 7.1 Unregis
Key Distribution
Generation
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregis
Request Data Selection Data Attacker Wake UP DMs
Response Transmission Detection
Figure: Business Logic
EA 7.1 Unregistered
Attacker Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregis
Detection Marking
«Functional Status: Proposed
EA 7.1 Unregistered Trial Version EAPriority: MediumTrial Version
7.1 Unregistered Difficulty:
EA 7.1Medium
Unregistered Trial Version EA 7.1 Unregis
»
Phase: 1.0
EA 7.1 Unregistered Trial Version EAVersion: 1.0
7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregis
The system
EA 7.1 Unregistered Trial must have
Version EAprovision to mark
7.1 Unregistered a sensor
Trial Versionnode
EA as
7.1the detected Trial Version EA 7.1 Unregis
Unregistered
attacker.
Data Selection
«Functional Status: Proposed
EA 7.1 Unregistered Trial Version EAPriority: MediumTrial Version
7.1 Unregistered Difficulty:
EA 7.1Medium
Unregistered Trial Version EA 7.1 Unregis
»
Phase: 1.0
EA 7.1 Unregistered Trial Version EAVersion: 1.0
7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregis
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 Priority: Medium 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
»
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
»
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
»
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
»
The system must have a provision to simulate the route between the two
sensors through the request response method.
Sensor Generation
»
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
»
The system must have a provision to wake up the dms system .
NON FUNCTIONAL REQUIREMENTS
The project non functional requirements include the following.
 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 quorum-
based 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
 TECHNICAL FEASIBILITY
 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.

A Three-Tier Framework For Intruder Information Sharing in Sensor Networks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Three-Tier Framework For Intruder Information Sharing in Sensor Networks

Uploaded by

Copyright:

Available Formats

A Three-Tier Framework for Intruder

Information Sharing in Sensor Networks

1. Functional and Non- functional requirements.

1. Verifiable Intruder Reporting Module

2. Quorum Based Caching module

3. Collaborative Boom filter module.

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered

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.

custom Business Logic

NON FUNCTIONAL REQUIREMENTS

The project non functional requirements include the following.

 Updating Work status.

The entire system was packaged into single package.

2.1 FEASIBILITY STUDY

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

are freely available. Only the customized products had to be purchased.

Estimates(i.e. budget, schedule etc .) become more relistic as work

You might also like