report recovered)

Rate Allocation And Network LifeTime Problem For Wireless Sensor Networks 2009-10

Chapter 1

INRODUCTION

Wireless sensor networks consist of battery-powered nodes that are

endowed with a multitude of sensing modalities including multi-media

(e.g., video, audio) and scalar data (e.g., temperature, pressure, light,

magnetometer, infrared).Although there have been significant

improvements in processor design and computing, advances in battery

technology still lag behind, making energy resource considerations the

fundamental challenge in wireless sensor networks. Consequently, there

have been active research efforts on performance limits of wireless

sensor networks. These performance limits include, among others,

network capacity and network lifetime. Network capacity typically

refers to the maximum amount of bit volume that can be successfully

delivered to the base station (“sink node”) by all the nodes in the

network, while network lifetime refers to the maximum time limit that

nodes in the network remain alive until one or more nodes drain up their

energy.

Here user considers an overarching problem that encompasses both

performance metrics. In particular, user studies the network capacity

problem under a given network lifetime requirement. Specifically, for a

wireless sensor network where each node is provisioned with an initial

energy, if all nodes are required to live up to a certain lifetime criterion,

what is the maximum amount of bit volume that can be generated by the

entire network? At first glance, it appears desirable to maximize the sum

of rates from all the nodes in the network, subject to the condition that

each node can meet the network lifetime requirement. Mathematically,

this problem can be formulated as a linear programming (LP) problem

within which the objective function is defined as the sum of rates over all

Dept of CSE, KIT, Tiptur 1


the nodes in the network and the constraints are: 1) flow balance is

preserved at each node, and 2) the energy constraint at each node is met

for the given network lifetime requirement. However, the solution to this

problem shows that although the network capacity (i.e., the sum of bit

rates over all nodes) is maximized, there exists a severe bias in rate

allocation among the nodes. In particular, those nodes that consume the

least amount of power on their data path toward the base station are

allocated with much more bit rates than other nodes in the network.

Consequently, the data collection behavior for the entire network only

favors certain nodes that have this property, while other nodes will be

unfavorably penalized with much smaller bit rates.

The fairness issue associated with the network capacity

maximization objective calls for a careful consideration in rate allocation

among the nodes. Hence investigate the rate allocation problem in an

energy-constrained sensor network for a given network lifetime

requirement. Here the objective is to achieve a certain measure of

optimality in the rate allocation that takes into account both fairness and

bit rate maximization. User advocate to use the so-called

Lexicographic Max-Min (LMM) criterion , which maximizes the bit rates

for all the nodes for the given energy constraint and network lifetime

requirement. At first level, the smallest rate among all the nodes is

maximized. Then, user continue to maximize the second level of smallest

rate and so forth. The LMM rate allocation criterion is appealing since it

addresses both fairness and efficiency (i.e., bit rate maximization) in an

energy-constrained network.

A naive approach to the LMM rate allocation problem would be to

apply a max-min-like iterative procedure. Under this approach, successive

LPs are employed to calculate the maximum rate at each level based on

the available energy for the remaining nodes, until all nodes use up their



energy. User calls this approach as “serial LP with energy reservation”

(SLP-ER). Hence although SLP appears intuitive, unfortunately it usually

gives an incorrect solution. To understand how this the least amount of

power on their data path toward the base station are allocated with much

more bit rates than other nodes in the network. Consequently, the data

collection behavior for the entire network only favors certain nodes that

have this property, while other nodes will be unfavorably penalized with

much smaller bit rates .could happen, user must understand a

fundamental difference between the LMM rate allocation problem

described here and the classical max-min rate allocation . Under the LMM

rate allocation problem, the rate allocation problem is implicitly coupled

with a flow routing problem, while under the classical max-min rate

allocation, there is no routing problem involved since the routes for all

flows are given. As it turns out, for the LMM rate allocation problem, any

iterative rate allocation approach that requires energy reservation at each

iteration is incorrect.

It is because, unlike max-min, which addresses only the rate

allocation problem with fixed routes and yields a unique solution at each

iteration, for the LMM rate allocation problem, there usually exist non-

unique flow routing solutions corresponding to the same rate allocation at

each level. Consequently, each of these flow routing solutions will yield

different available energy levels on the remaining nodes for future

iterations and so forth, leading to a different rate allocation vector, which

usually does not coincide with the optimal LMM rate allocation vector.

Here user develops an efficient polynomial-time algorithm to solve

the LMM rate allocation problem. User exploit the so-called parametric

analysis (PA) technique at each rate level to determine the minimum set

of nodes that must deplete their energy. User call this approach serial LP

with PA (SLP-PA). In most cases when the problem is non-degenerate, the



SLP-PA algorithm is extremely efficient and only requires time complexity

to determine whether or not a node is in the minimum node set for each

rate level. Even for the rare case when the problem is degenerate, the

SLP-PA algorithm is still much more efficient than the state-of-the-art

slack variable (SV)-based approach proposed, due to fewer number of LPs

involved at each rate level.

Here it extends the PA technique for the LMM rate allocation

problem to address the so-called maximum node lifetime curve problem,

which is called as LMM node lifetime problem. Hence the SLP-PA approach

is much more efficient than the slack variable (SV)-based approach (SLP-

SV). More importantly, there exists a simple and elegant duality

relationship between the LMM rate allocation problem and the LMM node

lifetime problem. As a result, it is sufficient to solve only one of these two

problems. Important insights can be obtained by inferring duality results

for the other problem.

Chapter 2

LITERATURE SURVEY

Visual Studio .Net has flexibility, Microsoft Visual Studio dot Net used as front end and

back end tool. The reason for selecting Visual Studio dot Net as front end and back end

tool as follows:

Allowing one or more languages to interoperate to provide the solution. This Cross

Language Compatibility allows to do project as faster rate.



Visual Studio .Net has Common Language Runtime which allows the entire component to

converge into one intermediate format and then can interact.

Visual Studio .Net has provided excellent security when the application is executed in the

system.

Visual Studio .Net has flexibility, allowing to configure the working environment to best

suit the individual style. Single and multiple document interfaces can be chosen, to adjust

the size and position of various IDE elements.

Visual Studio .Net has intelligence feature that makes the coding easy and also dynamic

help provides very less coding time

The working environment in Visual Studio .Net is often referred to as Integrated

Development Environment because it integrates many different functions such as design,

editing, compiling and debugging within a common environment. In most traditional

development tools, each of separate program, each with its own interface.

After creating a Visual Studio .Net application, if it has to be distributed to others it can be

freely distribute any application to anyone who uses Microsoft windows. The applications

can be distributed on disks, on CDs, across networks, or over an intranet or the internet.

Toolbars provide quick access to commonly used commands in the programming

environment. Once a button is clicked on the toolbar it carries out action represented by

that button.



By default, the standard toolbar is displayed when the application is started. Additional

toolbars for editing, form designing, and debugging can be toggled on or off from the

toolbars command on the view menu.

Many parts of Visual Studio are context sensitive. Context sensitive allows to get the help

on these parts directly without having to go through the help menu. For example, to get

help on any keyword, place the insertion point on the keyword in the code window.

Visual Studio interprets the code that has been entered, catching and

highlighting most syntax or spelling errors. It is almost like having an expert watching over

the shoulder as the code is entered.

2.1 LITERATURE REVIEW

Due to energy constraints in wireless sensor networks, there has been active research

on exploring the performance limits of such networks. These performance limits include,

among others, network capacity and network lifetime. Network capacity typically refers to

the maximum amount of bit volume that can be successfully delivered to the base station

(“sink node”) by all the nodes in the network, where network lifetime refers to the maximum



time that the nodes in the network remain alive before one or more nodes deplete their

energy.

In this project, we study the important overarching problem that considers both

network capacity and network lifetime. Under the LMM rate allocation problem, we studied

how to maximize rate allocations for all the nodes in the network under a given network

lifetime requirement. Under the LMM node lifetime problem, we studied how to maximize

the lifetime for all nodes when the local bit rate for each node is given a priori. The LMM

rate allocation criterion effectively mitigates the unfairness issue when the objective is to

maximize the total bit volume generated by the network. Although the LMM rate allocation

is somewhat similar to the classical max-min strategy, there is a fundamental difference

between the two. In particular, the LMM rate allocation problem implicitly embeds (or

couples) a flow routing problem within rate allocation, while under the classical max-min

rate allocation, there is no routing problem involved since the routes for all flows are given.

Due to this coupling of flow routing and rate allocation, a solution approach (i.e., SLP-PA) to

the LMM rate allocation problem is much more challenging than that for the classical max-

min.

One Scientist applied game theory and Nash equilibrium among the

nodes to forward packets such that the total throughput (capacity) can

achieve an optimal operating point subject to a common lifetime

requirement on all nodes. However, the fairness issue in information

collection was not considered. The most relevant work to the LMM node

lifetime problem was by Brown.

Chapter 3

SYSTEM ANALYSIS

3.1 NEED FOR PROPOSED SYSTEM



Hence consider an overarching problem that encompasses both performance metrics.

In particular, we study the network capacity problem under a given network lifetime

requirement. Specifically, for a wireless sensor network where each node is provisioned with

an initial energy, if all nodes are required to live up to a certain lifetime criterion, Since the

objective of maximizing the sum of rates of all the nodes in the network can lead to a severe

bias in rate allocation among the nodes, we advocate the use of lexicographical max-min

(LMM) rate allocation. To calculate the LMM rate allocation vector, we develop a

polynomial-time algorithm by exploiting the parametric analysis (PA) technique from linear

program (LP), which we call serial LP with Parametric Analysis (SLP-PA). We show that the

SLP-PA can be also employed to address the LMM node lifetime problem much more

efficiently than a state-of-the-art algorithm proposed in the literature. More important, we

show that there exists an elegant duality relationship between the LMM rate allocation

problem and the LMM node lifetime problem. Therefore, it is sufficient to solve only one of

the two problems. Important insights can be obtained by inferring duality results for the other

problem.

3.2 EXISTING SYSTEM

Here main focus is on the communication energy consumption. A naive

approach to the LMM rate allocation problem would be to apply a max-min-like iterative

procedure. Under this approach, successive LPs are employed to calculate the maximum rate

at each level based on the available energy for the remaining nodes, until all nodes use up

their energy.

As it turns out, for the LMM rate allocation problem, any iterative rate allocation

approach that requires energy reservation at each iteration is incorrect the LMM rate

allocation problem, there usually exist non-unique flow routing solutions corresponding to

the same rate allocation at each level. Consequently, each of these flow routing solutions will



yield different available energy levels on the remaining nodes for future iterations and so

forth, leading to a different rate allocation vector, which usually does not coincide with the

optimal LMM rate allocation vector.

3.3 PROPOSED SYSTEM

Here we develop an efficient polynomial-time algorithm to solve the LMM rate

allocation problem. It exploits the so-called parametric analysis (PA) technique at each rate

level to determine the minimum set of nodes that must deplete their energy. It is called as

serial LP with PA (SLP-PA). In most cases when the problem is non-degenerate, the SLP-PA

algorithm is extremely efficient and only requires time complexity to determine whether or

not a node is in the minimum node set for each rate level. Even for the rare case when the

problem is degenerate, the SLP-PA algorithm is still much more efficient than the state-of-

the-art slack variable (SV)-based approach proposed in, due to fewer numbers of LPs

involved at each rate level. Calculate the LMM-optimal rate vector, we developed a

polynomial-time algorithm by exploiting the parametric analysis (PA) technique from linear

programming (LP), which is called serial LP with Parametric Analysis (SLP-PA).

Furthermore, it showed that the SLP-PA algorithm can also be employed to address the

maximum node lifetime curve problem and that the SLP-PA algorithm is much more

efficient than an state-of the-Art algorithm.

3.4 ADVANTAGES OF PROPOSED SYSTEM



Network will be energy constraint.

Reduce all kind of network lifetime problems.

Gets updated network condition by graph simulation

3.5 APPLICATIONS

All the networks where sensor plays a main role.

Typical applications of Wireless Sensor Networks include monitoring, tracking,

and controlling. Some of the specific applications are habitat monitoring, object

tracking, nuclear reactor controlling, fire detection, traffic monitoring, etc.

In a typical application, a WSN is scattered in a region where it is meant to collect

data through its sensor nodes.

3.6 REQUIREMENT SPECIFICATION

3.6.1 Hardware Requirements

• SYSTEM : Pentium IV 2.4 GHz



• HARD DISK : 40 GB

• FLOPPY DRIVE : 1.44 MB

• MONITOR : 15 VGA colour

• MOUSE : Logitech.

• RAM : 256 MB

3.6.2 Software Requirements

• Operating system :- Windows XP Professional

• Front End : - VS.NET 2005

• Coding Language :- Visual C# .Net

Chapter 4

SYSTEM DESIGN

4.1 DESIGN TECHNIQUES



4.1.1 Internal Design

1. Node Creation

2. Node Connection

3. Calls

4. Graph

Node Creation

In this module, creates the nodes (sensors) according to the

network capacity. Here it will show in a draw panel. While the creation

itself, all the nodes shows their associated calls and initially it will be zero.

Node Connection

After the creation of the nodes, connection between the nodes will establish.

Connections are based on two conditions, by finding nearest neighbors and by connecting to

the isolated nodes.

Calls

Each node should connect to the calls made by the devices,

according to the node capacity and call duration. If network capacity is

less, there will be failed calls. User can see the list of total calls made.

Graph

Graph module is the important one to see the network capacity and to know what the

network condition is. Graph draws according to the average number of hops and number of

completed calls. Hence it shows which nodes are currently in the sleep state.



Module I/O

Node Creation

Given Input-Giving the network capacity

Expected Output-Creates nodes according to network capacity.

Node Connection

Given Input- Number of nodes and their position.

Expected Output- Make connections between nodes according to the conditions.

Calls

Given Input- Total calls, call duration and concurrent calls.

Expected Output-Shows total calls made, how many calls are assigned to each node,

and gets number of failed calls.

Graph

Given Input-Network conditions (How many nodes are active), and assigned calls.

Expected Output- Draws a graph according to average number of hops and number of

completed calls.

Module diagram



Figure :1

4.2 UML DIAGRAMS

Use case diagram


STOP

START

Creation of Nodes

Connection of Nodes

Add Calls

Draw graph


Figure: 2

Class diagram



Network Capacity

No.of NodesNode CapacityNode Connections

Create Network()

Calls

Total callsCall durationConcurrent Calls

Make Call()

Network

NodesTotal callsFailed CallsCurrent Avg

AssignCall()

Network_Graph

Average HopsCompletedCalls

Create_Graph()

Figure: 3

Object diagram


Network Details

Assign Calls

Node Creation

Node Connection

Makes Call

Network Simulation


Figure: 4

State diagram

Figure: 5

Collaboration Diagram


Network

Nodes

CreateNodes ()

Node Connection

Connect_nodes

Node Capacity ( )

Calls

Make Calls

AssignCalls ( )

Graph

Network Condition

Draw Graph ( )


Make Calls

Admin

Check NighboursAssign Calls

Graph

1: CreateNodes 3: Nework Details

2: Connections

4: Calls

5: Show Network Condition

Figure: 6



Component Diagram

Call

Node

Creation

Capacity

Connection

Assigning Calls

Network

Figure: 7

E-R diagram



Figure: 8

Dataflow diagram


Assigned Nodes

Connection

HAS

Neighbour

Call Duration

Individual

Nodes

HAS

HAS

Calls

Total Calls

NetworkDetails


Figure: 9

Project Flow Diagram



Figure: 10

System Architecture

Figure: 11


Create Connection

Calls

Calculate Average

Creates NodeUser

Show Simulation Graph

Assign Calls

User

Nodeetails

Create Node

Connection

Connection

Make Calls

Calls

Assign Calls


4.3 Data dictionary

LMM—Lexographical Max-Min

SLP-PA—Serial Linear Program-Parametric Analysis

SV—State-of-the-art Slack Variable

AFN—Aggregation And Forwarding Node

MSN—Micro Sensor Node

BS—Base Station

IDE—Integrated Development Environment

ASP—Active Server Pages

CLR—Common Language Runtime

CLS—Common Language Specification

ADO—Active X Data Objects

SDK—Software Development Kit

API—Application Program Interface



Chapter 5

SYSTEM IMPLEMENTATION

5.1 IMPLEMENTATION PLAN

Implementation literally means to put into effect or to carry out. The system

implementation phase of the software deals with the translation of the design

specifications into the source code. The ultimate goal of the implementation is to write

the source code and the internal documentation so that it can be verified easily. The code

and documentation should be written in a manner that eases debugging, testing and

modification. System flowcharts, sample run on packages, sample output etc. Is part of

the implementation?

An effort was made to satisfy the following goals in order specified :

Minimization of Response Time.

Clarity and Simplicity of the Code.

Minimization of Hard-Coding.

Minimization of the Amount of Memory Used.

Various types of bugs were discovered while debugging the modules. These ranged

from logical errors to failure on account of various processing cases.



5.2 EDUCATION AND TRAINING

Microsoft announced the .NET framework in July 2000, its biggest initiative since the

launch of WINDOWS in 1991. .NET (pronounced dot net) is a revolutionary multi-language

platform that knits various aspects of application developed together with internet. The

framework covers all layers of software development above the operating system. Several

software will be developed by Microsoft to achieve this goal. It is expected that every player

in the industry be it a software developer or a device manager, adopt .NET so that they can

be integrated. The .NET initiative is all about enabling data transfer between networks, PCs

and devices seamlessly independent of the platforms, architecture and solutions. Microsoft

has taken many of the best ideas in the industries, combined in some great ideas of their own,

and brought them all into one coherent package.

Visual Studio .net

VISUAL STUDIO .net is complete set of development tools for building ASP web

applications, XML web services, desktop applications, and mobile applications. Visual Basic

.NET, Visual C++.NET, and Visual C#.NET all use the same Integrated Development

Environment(IDE), which allows them to share tools and facilities in the creation of mixed-

language solutions. In addition, these languages leverage the functionality of the .NET

framework, which provides access to key technologies that simplify the development of ASP

web applications and XML web services.

Language Enhancement

Microsoft Visual Basic, Microsoft C++, and Microsoft Jscript have all been updated

to meet your development needs. Additionally, a new language, Microsoft C#, has been

introduced. These languages leverage the functionality .NET framework, which provides

access to key technologies that simplify the development of ASP web applications and XML

web services.



Visual C#

Visual C#, pronounced C sharp, is a new object-oriented programming is just some of

the enhancements made to the Visual C++, providing a simple and type-safe language for

developing application.

5.3 POST IMPLEMENTATION REVIEW

A post-implementation review is an evaluation of the extent to which the system

accomplishes stated objectives and actual project costs exceed initial estimates. It is usually a

review of major problems that need converting and those that surfaced during the

implementation phase.

After the system is implemented and conversion is complete, a review should be

conducted to determine whether the system is meeting expectations and where improvements

are needed. A post implementation review measures the systems performance against pre-

determined requirements. It determines how well the system continues to meet performance

specifications. It also provides information to determine whether major re-design or

modification is required.

The post implementation study begins with the review team, which gathers and

reviews requests for evaluation. Unexpected change in the system that affects the user or

system performance is a primary factor that system reviews. Once request is filed, the user is

asked how well the system is functioning to specifications or how well the measured benefits

have been realized. Suggestions regarding changes and improvements are also asked for.

There are five things in consideration when the project is developed. They are as follows:-

Correction

Adaptation/ Enhancement

Prevention/Integrity

Maintenance



Correction:

The project is corrective to its end and all the validation has been incorporated to

software developed so that no further corrective action can be thought of.

Adaptation/Enhancement:

The project should adapt the day-today scenario and should be up-to-date. The

flexibility is this project, allows the application to be modified, enhanced and adapted as and

when needed. The modularity and place for extending the code, therefore, the project has

been left so that it may adapt any changes of that the clinic is to be reflected on the project

that may result in the enhancement of the project.

Prevention/Integrity :

Security has been the major aspect in the prevailing system and is to be considered

the primary key for any successful of the project. This project has been given a full security

providing each TESTERS with their access. We know that:

Integrity= [1-(security*(1-threat)]

Every measure is employed to secure the system from any types of threats. Integrity has been

tried to maintain to its accuracy.

Maintenance:

The project is to be maintained in the way its accuracy, versatility, working, integrity,

correctiveness, etc. are as was proposed and will be as it was made with possibility of

enhancement to these properties. It also has the property that makes it truly maintainable.

NOTE:

The software has been developed keeping in mind the requirements of the Share

Investors to share application. One of the most important factors in developing any

application is experience. Due to lack of experience, We might have overlooked some things

that should be put into consideration.



Maintenance activities involve making enhancements to software products, adapting

products to new environments, and correcting problems. Software product enhancement may

involve providing new functional capabilities, improving user displays and modes of

interaction, upgrading external documents and internal documentation, or upgrading external

documents and internal documentation, or upgrading the performance characteristics of a

system. Adaptation of software to a new environment may involve moving the software to a

different machine. Problem correction involves modification and revalidation of software to

correct errors.

Maintenance activities consume a large portion of the total life cycle budget.

Software Maintenance accounts for 70 percent of total software life-cycle costs. Maintenance

includes 60 percent of maintenance budget for enhancement, and 20 percent each for

adaptation and correction. The primary product attributes that contribute to software

maintainability are clarity, modularity, and good internal documentation of the source code,

as well as appropriate supporting documents.

Analysis activities during software maintenance involve understanding the scope and

effect of a desired change, as well as the constraints on making the change.

Design during maintenance involves redesigning the product to incorporate the desired

changes. The changes must then be implemented, Internal documentation of the code must be

updated, and new test cases must be designed to access the adequacy of the modification.

Also the supporting documents must be updated to reflect the changes. Updated versions of

the software must then be distributed to various customer sites, and configuration control

records for each site must be updated.

Failure to recognize the true cost of a small change in the source code is one of the

most significant problems in software maintenance.



Chapter 6SYSTEM TESTING

6.1 UNIT TESTING

After designing phase there is the coding phase. In this phase, every module

identified and specified in the design document is independently Coded and Unit tested .Unit

testing (or module testing) is the testing of different units or modules of a system. In this

phase, the physical design of the system is converted into the logical programming language.

We have tried to follow some coding standards and Guidelines.

The coding standards are :

Naming standards for the .Net Classes, pages and variables etc.

Screen design standards.

Validation and checks that need to be implemented.

The Guidelines are :

Code should be well document.

Coding style should be simple.

Length of function should short.

Here the programs that made up the system were tested. Hence it is called as program

testing. This level of testing focuses on the modules, independently of one another. The

purpose of unit testing is to determine the correct working of the individual modules. For unit

testing, we first adopted the code testing strategy, which examined the logic of program.

During the development process itself all the syntax errors etc. got rooted out. For this we

developed test case that result in executing every instruction in the program or module i.e.

every path through program was tested. (Test cases are data chosen at random to check every

possible branch after all the loops.).

Unit testing involves a precise definition of test cases, testing criteria, and management of

test cases.



The main purpose behind testing is to find errors. This level of testing focuses on the

modules, independently of one another.

Testing means to check weather system meets user requirements about:

Error handling

In this system we have tried to handle all the errors that are occurred while running

the Window forms. The common errors we saw are reading the empty record and displaying

a compiler message, etc.

For Testing we used Top-Down design a decomposition process which focuses as the

flow of control, at latter strategies concern itself with code production. The first step is to

study the overall aspects of the tasks at hand and break it into a number of independent

modules. The second step is to break one of these modules further into independent sub

modules. One of the important features is that at each level the details at lower levels are

hidden. So, we performed unit testing first and then system testing.

6.2 INTEGRATION TESTING

In this the different modules of a system are integrated using an integration plan. The

integration plan specifies the steps and the order in which modules are combined to realize

the full system. After each integration step, the partially integrated system is tested. The

primary objective of integration testing is to test the module interface.

An important factor that guides the integration plan is the module dependency graph.

The module dependency graph denotes the order in which different modules call each other.

A structure chart is a form of a module dependency graph. Thus, by examining the

structure chart the integration plan can be developed based on any of the following

approaches:



Big-bang approach.

Top-down approach.

Bottom-up approach.

Mixed approach.

Bottom-up Integration Testing

Here each subsystem is tested separately and then the full system is tested. A

subsystem might consist of many modules, which communicate among each other through

well-defined interfaces. The primary purpose of testing each subsystem is to test the

interfaces among various modules making up the subsystem. Both control and data interface

is tested. A principal advantage of bottom-up integration testing is that several disjoint

subsystems can be tested simultaneously. A disadvantage of bottom-up testing is the

complexity that occurs when the system is made up of large number of small subsystems.

In Main module, we have tested all the individual programs first and after having

successful results in the individual program testing we moved further for the integration.

Some programs have been combined and then tested , after having good results; we

have combined all the programs together and started for system testing.

6.3 SYSTEM TESTING

Once satisfied that all the modules work well in themselves and there are no

problems, we do in to how the system will work or perform once all the modules are put

together. The main objective is to find discrepancies between the system and its original

objective, current specifications, and system documentation. Analysts try to find modules

that have been designed with different specifications, which could cause incompatibility.



At this stage the system is used experimentally to ensure that all the requirements of

the user are fulfilled. At this point of the testing takes place at different levels so as to ensure

that the system is free from failure.

Testing is vital to success of the system. System testing makes a logical assumption

that whether all parts of the system are correct. Initially the system was given to the user for

entry validation was provided at each and every stage. Therefore the user is not allowed to

enter unrelated data. The training is given to user about how to make an entry. While

implementing the system it was observed that the user was initially resisting the change,

however the system being the need of the hour and user friendly, the fear was overcome.

Entering live data of the past months records was little tedious, prior to the actual day to day

transaction

The best test made on the system was whether it produces the correct outputs. All the

outputs were checked out and were found to be correct. Feedback sessions were conducted

and the suggested changes given by the user were made before the acceptance test. Finally

the system is being accepted and made to run with live data.

System tests are designed to validate a fully developed system with a view to assuring

that it meets its requirements.

There are three main kinds of system testing:

Alpha Testing.

Beta Testing.

Acceptance Testing.

Alpha Testing: This refers to the system testing that is carried out by the test team

with the organization.



Beta Testing: This refers to the system testing that is performed by a select group of friendly

customers.

Acceptance Testing: This refers to the system testing that is performed by the customer to

determine whether or not to accept t the delivery of the system.

6.4 USER ACCEPTANCE TESTING

Acceptance testing involves planning and execution of functional test, performance

tests and stress tests to verify that the Company details satisfies its requirements.

Acceptance tests are typically performed by the quality assurance and or customer

organizations. Depending on local circumstances, the development group may or may not be

involved in acceptance testing.

In addition to, functional and performance tests, stress tests are performed to

determine the limitations of the system. Acceptance tests will incorporate test cases

developed during unit testing and integration testing. Additional test cases are added to

achieve the desired level of functional, performance, and stress testing of the entire system.



Chapter 7

RESULTS AND CONCLUSION

7.1 SCREEN LAYOUTS

Screen Shots

Node Creation



Node Connection

-



Graph



7.2 CONCLUSION OF DOCUMENTATION

Documentation is a method of communication. A satisfactory documentation of the

system should be objective, factual and complete. Thus format, length, volume or complexity

does not determine its adequacy. In documentation, there are no uniform standards that are

applicable to all system projects. Documentation is essential to the development,

implementation and operation of any system. Documentation is necessary as it helps in

maintaining the system and also acts as a reference for the user.

Embedding Comments in the executable portion of the code did proper

documentation of each module. To enhance the readability of the comments, indentation,

parenthesis, blank lines and spaces, proper lining of the loops were used around the block of

comments. Care was also taken to use descriptive names of tables, fields, modules, forms etc.

The proper use of indentation, parenthesis, blank lines and spaces were also ensured during

coding to enhance the readability of the code.



Time Allocation Chart

1. ANALYSIS AND DESIGN

2. TESTING AND DEBUGGING

3. PROGRAM CODING

4. DOCUMENTATION



7.3 CONCLUSION OF PROJECT

Here it has been investigated that the important problem of rate allocation for wireless

sensor networks under a given network lifetime requirement. Since the objective of

maximizing the sum of rates of all nodes can lead to a severe bias in rate allocation among

the nodes, we advocate the use of lexicographical max-min (LMM) rate allocation for all

nodes in the network. To calculate the LMM-optimal rate vector, we developed a

polynomial- time algorithm by exploiting the parametric analysis (PA) technique from linear

programming (LP), which we called serial LP with Parametric Analysis (SLP-PA).

Furthermore, showed that the SLP-PA algorithm can also be employed to address the

maximum node lifetime curve problem and that the SLP-PA algorithm is much more

efficient than an state-of-the-art algorithm. More important, we discovered a simple and

elegant duality relationship between the LMM rate allocation problem and the LMM node

lifetime problem, which enables us to develop solutions and insights on both problems by

solving one of the two problems. Our results in this paper offer some important

understanding on network capacity and network lifetime problems for energy-constrained

wireless sensor networks



7.4 SCOPE FOR FUTURE DEVELOPMENT

In this Sensor based system all the requirements have been added and implemented

successfully. All the functionalities of the system have been working properly. Through the

system has been implemented still there may be some more requirements that may come

from the user. So for further improvement of the system we can perform the following

functionalities:

The developed and previously tested functionalities can be modified later with more

user-friendly functions to make the system more useful.

Now the application is working for sensor network. Maintaining Share price details as

a localized system and accessing the details anywhere in the world. Later we can

implement some telecom concepts, so that the user will get the information about the

activities of the company in a sensor network. As the technology and requirements is

changing day by day, we can add more functionality and we can implement the

system with new requirements. The system is designed in such a way that it is flexible

to change any further requirements Prescribed by the user.



BIBLIOGRAPHY

Andrew Troelsen - C# and .NET concepts

Steve Babin – Developing s/w for symbian OS

Richard Harrison – Symbian OS C++ for Mobile phones

Jesse Liberty - OReilly.Learning.ASP.NET.3.5

On-line Resources

http://www.symbian .com

http://www.wikipedia.com

http://code.google.com/apis/maps

http://www.ieee.org.com


http://www.ieee.org.com/

http://code.google.com/apis/maps


APPENDIXES

A. Pseudo Code

(i) Calls.cs

using System;

using System.Collections;

namespace RateAllocation

{

/// <summary>

/// A call represents an call placed on the network

/// </summary>

public class Call

{

#region properties

// the maximum length of the call

public int Duration;

// unique identifier

public int CallID;

// the starting node of the call

public int SourceNodeID;

// the final desitination of the call

public int DestinationNodeID;

// the current node the call is on

public int CurrentNodeID;



// an array of all visited node ids

public ArrayList VisitedNodes= new ArrayList();

// an array of final visted arrays after xxxx

public ArrayList FinalVisitedNodes= new ArrayList();

// has the call finished

public bool Finished=false;

// has the call failed

public bool HasFailed=false;

// which direction is the ant agent moving in

public eAntDirection AntDirection;

// the new value of the node

public double NewValue=-1;

// the final count for visited nodes

public int finalVisitedNodeCount=0;

// total wait time for the call

public int waitTime=0;

// if the call was successful

public bool Successful=false;

// create a new call with a source and destination node

public Call(int src, int dest)

{

this.CallID = Global.CallID;

this.SourceNodeID = src;

this.DestinationNodeID = dest;

this.CurrentNodeID = src;

this.VisitedNodes.Add(this.SourceNodeID);

this.Duration=Global.CallDuration;

}



(ii) Mainform.cs

using System;

using System.Threading;

using System.Drawing;


using System.ComponentModel;

using System.Windows.Forms;

using dotnetCHARTING.WinForms;


{

/// <summary>

/// The Main form of the application

/// </summary>

public class MainForm : System.Windows.Forms.Form

{

#region properties

private RateAllocation.DrawPanel pnlGraph;

// total time for this simulation

private double totaltime=0;

// the current simultation

private Simulation sim;

// number of completed calls

private double complete=0;

// number of failed calls

private double failed = 0;



private Chart TheChart;

private PictureBox pictureBox1;

private Panel panel2;

private System.Windows.Forms.Label label13;

// if antnet was actuavated on the last iteration (used for labelling charts)

private bool AntNetOnLastIteration=true;

#endregion

[STAThread]

static void Main()

{

Application.Run(new MainForm());

}

public MainForm()

{

InitializeComponent();

cmbSpeed.SelectedIndex=5;

cmbAlgorithm.SelectedIndex=0;

lbNodes.Items.AddRange(Global.Nodes);

for(int i=0;i<lbNodes.Items.Count;i++)

lbNodes.SetItemChecked(i,true);

this.lbNodes.ItemCheck += new ItemCheckEventHandler(this.lbNodes_OnClick);

}

private void btnStart_Click(object sender, System.EventArgs e)

{

Ticker.Stop();

#region textbox input validation

// set the timer speed

if(cmbSpeed.SelectedIndex==0)

Ticker.Interval = 1000;



else if(cmbSpeed.SelectedIndex==1)










}

#endregion

TableEntry t;

double total=0;

for(int j=0;j<tableEntry.Length;j++)

{

t = tableEntry[j];

total += t.Probablilty;

if(EntryTableNodeID==t.NodeID)

{

total += newVal;

t = tableEntry[j];

t.Probablilty += newVal;

}

}



double ratio = 100/total;

for(int j=0;j<tableEntry.Length;j++)

{

tableEntry[j].Probablilty *= ratio;

}

}

public PheromoneTable(Node n, int[] conns)

{

this.NodeID = n.ID;

this.tableEntry = new TableEntry[conns.Length];

for(int i=0;i<conns.Length;i++)

tableEntry[i] = new TableEntry(conns[i]);

for(int i=0;i<conns.Length;i++)

tableEntry[i].Probablilty = (100 / (double)conns.Length);

}

}

public class TableEntry

{

public int NodeID;

public double Probablilty;

public TableEntry(int nodeID)

{

this.NodeID = nodeID;

}

}

}



(vii) Simulation.cs

using System;



{

public class Simulation

{

public ArrayList Calls = new ArrayList();

public ArrayList NetworkUtilisation = new ArrayList();

public ArrayList AnnoText=new ArrayList();

}

}



B. TECHNIQUES AND ALGORITHMS USED

Here consider two-tier architecture for wireless sensor networks. This shows the

physical and hierarchical network topology for such a network, respectively. There are three

types of nodes in the network, namely, micro-sensor nodes (MSNs), aggregation and

forwarding nodes (AFNs), and a base station (BS). The MSNs can be application-specific

sensor nodes (e.g., temperature sensor nodes (TSNs), pressure sensor nodes (PSNs), and

video sensor nodes (VSNs)) and they constitute the lower tier of the network. They are

deployed in groups (or clusters) at strategic locations for surveillance and monitoring

applications. The MSNs are small and low-cost. The objective of an MSN is very simple:

Once triggered by an event, it starts to capture sensing date and sends it directly to the local

AFN.

For each cluster of MSNs, there is one AFN, which is different from an MSN in terms

of physical properties and functions. The primary functions of an AFN are: 1) data

aggregation (or “fusion”) for data flows from the local cluster of MSNs, and 2) forwarding

(or relaying) the aggregated information to the next hop AFN (toward the base station). For

data fusion, an AFN analyzes the content of each data stream it receives and exploits the

correlation among the data streams. An AFN also serves as a relay node for other AFNs to

carry traffic toward the base station. Although an AFN is expected to be provisioned with

much more energy than an MSN, it also consumes energy at a substantially higher rate (due

to wireless communication over large distances). Consequently, an AFN has a limited

lifetime. Upon depletion of energy at an AFN, we expect that the coverage for the particular

area under surveillance is lost, despite the fact that some of the MSNs within the cluster may

still have remaining energy.



The third component in the two-tier architecture is the base station. The base station

is, essentially, the sink node for data streams from all the AFNs in the network. In this

investigation, we assume that there is sufficient energy resource available at the base station

and thus there is no energy constraint at the base station. In summary, the main functions of

the lower tier MSNs are data acquisition and compression while the upper-tier AFNs are used

for data fusion and relaying information to the base station.


report recovered)

Documents