Cloud data management

Abstract:
A significant challenge in cloud data management is ensuring that all query processing is

carried out securely within a cloud infrastructure. To be secure, query processing must

(1) authenticate users and machines involved in query processing, (2) secure the transfer

of data across machines in the cloud, and (3) ensure the integrity of all query results. All

three requirements can be directly applied to mitigate potential threats at the

infrastructure, network, and user levels

2. System Analysis:

2.1 Existing System :

Efforts at each layer of network systems

Mesh network between STAs

Ad hoc mode in IEEE 802.11 standard

2.2 Proposed System:
• IEEE 802.11 protocol under unsaturated traffic conditions for multi-hop

networks

• Bandwidth reservation

• QoS Routing

• Congestion Control

• MAC protocol : DCF(CP) / PCF(CFP)

• Decision making

• two-dimensional Markov chain model to analyze the performance of the

IEEE 802.11 protocol in single hop wireless networks

2.3 Feasibility Study:

A feasibility study is an evaluation of a proposal designed to

determine the difficulty in carrying out a designated task. Generally, It

precedes technical development and project implementation. Its an

evaluation or analysis of the potential impact of a proposed project.

2.3.1 Economical Feasibility

Economic analysis is the most frequently used method for evaluating

the effectiveness of a new system, benefits outweigh costs, then the decision

is made to design and implement the system.

2.3.2 Operational Feasibility

Operational feasibility is a measure of how well a proposed system

solves the problems, and takes advantage of the opportunities identified

during scope definition and how it satisfies the requirements identified in the

requirements analysis phase of system development

2.3.3 Technical Feasibility

An outline design of system requirements in terms of Input, Processes,

Output, Fields, Programs, and Procedures. This can be quantified in terms of

volumes of data, trends, frequency of updating, etc. in order to estimate

whether the new system will perform adequately or not. Technological

feasibility is carried out to determine whether the company has the

capability, in terms of software, hardware, personnel and expertise, to handle

the completion of the project

3. SYSTEM REQUIREMENTS:

3.1 Hardware Requirements:

Processor Type : Pentium -IV

Speed : 2.4GHZ

Ram : 256 MB RAM

Hard disk : 20 GB HD

3.2 Software Requirements:

Operating System : Linux

Programming Package : Tcl Scripting , C++

Tools : VMware

4 Software Descriptions

Network simulation is a technique where a program models the

behavior of a network either by calculating the interaction between the

different network entities (hosts/routers, data links, packets, etc) using

mathematical formulas, or actually capturing and playing back observations

from a production network. The behavior of the network and the various

applications and services it supports can then be observed in a test lab;

various attributes of the environment can also be modified in a controlled

manner to assess how the network would behave under different conditions.

When a simulation program is used in conjunction with live applications and

services in order to observe end-to-end performance to the user desktop, this

technique is also referred to as network emulation.

Motivation for Simulations

• Cheap -- does not require costly equipment

• Complex scenarios can be easily tested

• Results can be quickly obtained – more ideas can

• be tested in a smaller timeframe

• The real thing isn't yet available

• Controlled experimental conditions

• Repeatability helps aid debugging

• Disadvantages: Real systems too complex to model

Most of the commercial simulators are GUI driven, while some network

simulators require input scripts or commands (network parameters). The

network parameters describe the state of the network (node placement,

existing links) and the events (data transmissions, link failures, etc).

Important outputs of simulations are the trace files. Trace files can document

every event that occurred in the simulation and are used for analysis. Certain

simulators have added functionality of capturing this type of data directly

from a functioning production environment, at various times of the day,

week, or month, in order to reflect average, worst-case, and best-case

conditions

Most network simulators use discrete event simulation, in which a list

of pending "events" is stored, and those events are processed in order, with

some events triggering future events -- such as the event of the arrival of a

packet at one node triggering the event of the arrival of that packet at a

downstream node.

Some network simulation problems, notably those relying on queuing

theory, are well suited to Markov chain simulations, in which no list of

future events is maintained and the simulation consists of transiting between

different system "states" in a memory less fashion. Markov chain simulation

is typically faster but less accurate and flexible than detailed discrete event

simulation. Some simulations are cyclic based simulations and these are

faster as compared to event based simulations.

Advantages of simulation

* Normal analytical techniques make use of extensive mathematical

models which require assumptions and restrictions to be placed on the

model. This can result in an avoidable inaccuracy in the output data.

Simulations avoid placing restrictions on the system and also take random

processes into account; in fact in some cases simulation is the only practical

modeling technique applicable

* Analysts can study the relationships between components in detail and

can simulate the projected consequences of multiple design options before

having to implement the outcome in the real-world.

* It is possible to easily compare alternative designs so as to select the

optimal system.

* The actual process of developing the simulation can itself provide

valuable insights into the inner workings of the network which can in turn be

used at a later stage.

Disadvantages of simulation

* Accurate simulation model development requires extensive resources.

* The simulation results are only as good as the model and as such are

still only estimates / projected outcomes.

* Optimization can only be performed involving a few alternatives as the

model is usually developed using a limited number of variables.

* Simulations cost a lot of money to build and are very expensive to make

Input data

Simulation models are generated from a set of data taken from a

stochastic system. It is necessary to check that the data is statistically valid

by fitting a statistical distribution and then testing the significance of such a

fit. Further, as with any modelling process, the input data’s accuracy must be

checked and any outliers must be removed.

Output data

When a simulation has been completed, the data needs to be analysed.

The simulation's output data will only produce a likely estimate of real-

world events. Methods to increase the accuracy of output data include:

repeatedly performing simulations and comparing results, dividing events

into batches and processing them individually, and checking that the results

of simulations conducted in adjacent time periods “connect” to produce a

coherent holistic view of the system

The main idea is to partly implement HTTP, FTP and TCP protocols.

Routing is the process of selecting paths in a network along which to send

network traffic. Routing is performed for many kinds of networks, including

the telephone network (Circuit switching) , electronic data networks (such as

the Internet), and transportation networks. This article is concerned primarily

with routing in electronic data networks using packet switching technology.

In packet switching networks, routing directs packet forwarding, the transit

of logically addressed packets from their source toward their ultimate

destination through intermediate nodes, typically hardware devices called

routers, bridges, gateways, firewalls, or switches. General-purpose

computers can also forward packets and perform routing, though they are

not specialized hardware and may suffer from limited performance. The

routing process usually directs forwarding on the basis of routing tables

which maintain a record of the routes to various network destinations. Thus,

constructing routing tables, which are held in the router's memory, is very

important for efficient routing. Most routing algorithms use only one

network path at a time, but multipath routing techniques enable the use of

multiple alternative paths.

Routing, in a more narrow sense of the term, is often contrasted with

bridging in its assumption that network addresses are structured and that

similar addresses imply proximity within the network. Because structured

addresses allow a single routing table entry to represent the route to a group

of devices, structured addressing (routing, in the narrow sense) outperforms

unstructured addressing (bridging) in large networks, and has become the

dominant form of addressing on the Internet, though bridging is still widely

used within localized environments.

Routing schemes differ in their delivery semantics:

• unicast delivers a message to a single specified node;

• broadcast delivers a message to all nodes in the network;

• multicast delivers a message to a group of nodes that have

expressed interest in receiving the message;

• anycast delivers a message to any one out of a group of nodes,

typically the one nearest to the source.

Path selection

Path selection involves applying a routing metric to multiple routes, in order

to select (or predict) the best route.

In the case of computer networking, the metric is computed by a

routing algorithm, and can cover such information as bandwidth, network

delay, hop count, path cost, load, MTU, reliability, and communication cost

(see e.g. this survey for a list of proposed routing metrics). The routing table

stores only the best possible routes, while link-state or topological databases

may store all other information as well.

Because a routing metric is specific to a given routing protocol, multi-

protocol routers must use some external heuristic in order to select between

routes learned from different routing protocols. Cisco's routers. A local

network administrator, in special cases, can set up host-specific routes to a

particular machine which provides more control over network usage, permits

testing and better overall security. This can come in handy when required to

debug network connections or routing tables.

As the Internet and IP networks become mission critical business

tools, there has been increased interest in techniques and methods to monitor

the routing posture of networks. Incorrect routing or routing issues cause

undesirable performance degradation, flapping and/or downtime. Monitoring

routing in a network is achieved using Route analytics tools and techniques.

Protocols: TCP, UDP, HTTP, Routing algorithms etc

• Traffic Models: CBR, VBR, Web etc

• Error Models: Uniform, bursty etc

• Radio propagation, Mobility models

• Energy Models

• Topology Generation tools

• Visualization tools

• Extensibility

Simulators help in easy verification of protocols in less time, money

• NS offers support for simulating a variety of

• protocol suites and scenarios

• Front end is oTCL, back end is C++

• NS is an on-going effort of research and development

5 Project Descriptions

5.1 Problem Definition

• Error-free retransmission

• No delay bound under bad link

• Resource fluctuation due to wireless medium

• Delay for adaptation

5.2 Overview of the Project

Single hop IEEE 802.11 networks under saturated traffic conditions.

A model that describe the behavior of IEEE 802.11 under different offered

traffic loads. This model shows the effect of the offered load on the

transmission probability. We also propose a three dimensional model to

attempt to describe the behavior of multi-hop 802.11 networks. The 3D

model allows the modeling of not only data sources but also relay stations

that forward traffic. The IEEE 802.11 DCF scheme, stressing key elements

related to this paper. The protocol under unsaturated traffic loads is

discussed.

5.3 Module Description

1. Multi-hop Wireless Network

A wireless network adopting multihop wireless technology without

deployment of wired backhaul links Similar to Mobile Ad hoc Networks

(MANET), but nodes in MWN is relative ‘fixed’ , it may introduce

‘hierarchy’ network architecture. every station is assumed to be a data

source that sends out saturated traffic. In a multi-hop wireless network, each

station in the whole network is not necessarily a data source. A station may

act as a data source for a period of time when it has original data to send,

while at other times it may act as a relay station that simply forwards other

stations’ data

2. IEEE 802.11 MAC protocol

Recently, the IEEE has standardized the 802.11 protocol for Wireless

Local Area Networks. The primary medium access control (MAC) technique

of 802.11 is called distributed coordination function (DCF). DCF is a carrier

sense multiple access with collision avoidance (CSMA/CA) scheme with

binary slotted exponential back off. We provides a simple, but nevertheless

extremely accurate, analytical model to compute the 802.11 DCF

throughput, in the assumption of finite number of terminals and ideal

channel conditions. The proposed analysis applies to both the packet

transmission schemes employed by DCF, namely, the basic access and the

RTS/CTS access mechanisms. In addition, it also applies to a combination

of the two schemes, in which packets longer than a given threshold are

transmitted according to the RTS/CTS mechanism.

Media Access Scheme: CSMA/CA

Avoidance by RTS/CTS

ACK mechanism

Exponential Back off

3. Implementation of saturated traffic in relay

station

Stations are statistically identical, each station has idle periods that are

exponentially distributed, and packet length is constant. At any given time,

statistically, a certain number of stations within a given station’s

transmission range act as data sources that inject data traffic. These are

called source stations. Other stations act as data relays that forward traffic

within the network. These are called relay stations. A relay station listens to

the medium, gets packets from it and forwards the packets it receives. The

number of packets a relay station receives and accepts to forward depends

on the upper layer routing protocol. the analysis of the MAC protocol, we

need to find a way to isolate or take into account the upper layer protocol.

The different routing protocols distribute the traffic load among the stations

in different ways

4. Performance Analysis

• Energy Conception

• Packet delay

• Flow of traffic

5.3.1 Modules

1. Multi-hop Wireless Network

2. IEEE 802.11 MAC protocol

3. Implementation of saturated traffic in relay station

4. Performance analysis

5.4 Data Flow Diagram

Level 0:

Multi-hop
Node Ad-Hoc Single hop
Networks neighbor
creation

Level 1:

Source Node Destination
Node

Response
IEEE802.11
protocol

Level 2:

Source Relay Node Destination

One hop neighbor

Traffic Monitoring IEEE802.11
protocol

5.5 Use case Diagram

Intermediate
Source Relay Destination
Station

Request

One hop neighbor

Response

IEEE802.11
Routing

Traffic Monitoring

6. System Testing

The program ``validate'' in the root directory of the ns distribution runs all

current standard tests. Protocols covered in validate represent the most stable

core of ns. We insure that validate passes on several different systems for

each ns release, and we run it over the daily snapshot (see below).

We encourage you to report problems with validated protocols to us. We try

to resolve these problems rapidly (as resources allow).

Even though we consider these protocols ``validated'', our test suite coverage

is not complete. You are advised to look at what aspects of the protocols are

tested in the test suite before drawing research conclusions from these

protocols.

Protocols and modules covered at least in part by validate include the

following:

Application-level:

• HTTP, web caching and invalidation, TcpApp (test-suite-

webcache.tcl)

• telnet and ftp sources (test-suite-simple.tcl)

• Constant-Bit-Rate (CBR) sources (e.g., in test-suite-cbq.tcl)

• On/Off sources (in test-suite-intserv.tcl)

Transport protocols (UDP, TCP, RTP, SRM):

• basic TCP behavior (test-suite-simple.tcl, test-suite-v1{,a}.tcl)

• Tahoe, Reno, New-Reno, and SACK TCP under different losses (test-

suite-tcpVariants.tcl)

• FACK TCP (limited validation in test-suite-tcpVariants.tcl)

• TCP vegas (test-suite-vegas-v1.tcl)

• New-Reno TCP (test-suite-newreno.tcl)

• SACK TCP (test-suite-sack{,-v1,v1a})

• full TCP (test-suite-full.tcl), partial validation only.

• TCP initial window behavior (test-suite-tcp.tcl)

• rate-based pacing TCP (test-suite-rbp.tcl)

• RFC-2001 (Reno) TCP behavior (test-suite-rfc2001.tcl)

• RTP (in test-suite-friendly.tcl, not yet added to "validate")

• SRM (in test-suite-srm.tcl)

Routing:

• algorithmic routing (test-suite-algo-routing)

• hierarchical routing (test-suite-hier-routing.tcl)

• lan routing and broadcast (test-suite-lan.tcl)

• manual routing (test-suite-manual-routing.tcl)

• centralized multicast, DM multicast, not detailedDM, not multicast

over LAN (test-suite-mcast.tcl)

• routing dynamics (test-suite-routed.tcl)

• detailed simulation using virtual classifier (test-suite-vc.tcl)

• mixed-mode session-levels simulation (test-suite-mixmode.tcl)

• session-level simulation (test-suite-session.tcl)

Router Mechanisms (scheduling, queue management, admissions

control, etc.):

• several queue scheduling algorithms: FQ (Fair Queueing), SFQ

(Stochastic Fair Queuing), DRR (Deficit Round Robin), FIFO (with

drop-tail and RED queue management) (test-suite-schedule.tcl)

• CBQ (both in v1 and v2 mode) (test-stuite-cbq{,-v1,-v1a})

• RED queue management (test-suite-red{,-v1,-v1a})

• ECN behavior (and TCP interactions) (test-suite-ecn.tcl)

• admission control algorithms: MS, HB, ACTP, ACTO, parameter-

based (in test-suite-intserv.tcl)

Link-layer mechanisms:

• LANs, with CSMA/CD MAC protocols (in test-suite-lan.tcl)

• snoop

Other:

• Error Modules (e.g., in test-suite-ecn.tcl, test-suite-tcp-init-win.tcl,

test-suite-session.tcl, and test-suite-srm.tcl)

In addition there are a number of protocols in the standard ns distribution

which are not covered by validate. Because they cannot be automatically

tested, bit-rot sometimes breaks these protocols.

We attempt to keep non-validated protocols working and welcome

bug reports. Becuase of difficulties maintaining code that we did not write

and for which we may not know ``ground truth'', we cannot promise that

these protocols will remain working. We strongly encourage people using

these protocols in their research to examine their output carefully and

implement test suites for them so that we can move them into the

``validated'' category.

Configure:

A simple ./configure will try to auto-detect the packages ns needs to build.

Auto-detection searchs sensible places (like /usr/local) and the directory

above current direcory. If you have packages installed elsewhere you can

explicitly tell ns where something is with options like --with-

tcl=/your/path/to/tcl. Run ./configure --help for a complete list of options

To make this even easier, the make utility has a set of built-in rules so you

only need to tell it what new things it needs to know to build your particular

utility. For example, if you typed in make love, make would first look for

some new rules from you. If you didn't supply it any then it would look at its

built-in rules. One of those built-in rules tells make that it can run the linker

(ld) on a program name ending in .o to produce the executable program.

So, make would look for a file named love.o. But, it wouldn't stop there.

Even if it found the .o file, it has some other rules that tell it to make sure the

.o file is up to date. In other words, newer than the source program. The

most common source program on Linux systems is written in C and its file

name ends in .c.

If make finds the .c file (love.c in our example) as well as the .o file, it

would check their timestamps to make sure the .o was newer. If it was not

newer or did not exist, it would use another built-in rule to build a new .o

from the .c (using the C compiler). This same type of situation exists for

other programming languages. The end result, in any case, is that when

make is done, assuming it can find the right pieces, the executable program

will be built and up to date.

The old UNIX joke, by the way, is what early versions of make said when it

could not find the necessary files. In the example above, if there was no

love.o, love.c or any other source format, the program would have said:

make: don't know how to make love. Stop.

Getting back to the task at hand, the default file for additional rules in

Makefile in the current directory. If you have some source files for a

program and there is a Makefile file there, take a look. It is just text. The

lines that have a word followed by a colon are targets. That is, these are

words you can type following the make command name to do various

things. If you just type make with no target, the first target will be executed.

What you will likely see at the beginning of most Makefile files are what

look like some assignment statements. That is, lines with a couple of fields

with an equal sign between them. Surprise, that is what they are. They set

internal variables in make. Common things to set are the location of the C

compiler (yes, there is a default), version numbers of the program and such.

This now beings up back to configure. On different systems, the C compiler

might be in a different place, you might be using ZSH instead of BASH as

your shell, the program might need to know your host name, it might use a

dbm library and need to know if the system had gdbm or ndbm and a whole

bunch of other things. You used to do this configuring by editing Makefile.

Another pain for the programmer and it also meant that any time you wanted

to install software on a new system you needed to do a complete inventory

of what was where.

As more and more software became available and more and more POSIX-

compliant platforms appeared, this got harder and harder. This is where

configure comes in. It is a shell script (generally written by GNU Autoconf)

that goes up and looks for software and even tries various things to see what

works. It then takes its instructions from Makefile.in and builds Makefile

(and possibly some other files) that work on the current system.

Background work done, let me put the pieces together.

• You run configure (you usually have to type ./configure as most

people don't have the current directory in their search path). This

builds a new Makefile.

• Type make This builds the program. That is, make would be executed,

it would look for the first target in Makefile and do what the

instructions said. The expected end result would be to build an

executable program.

• Now, as root, type make install. This again invokes make, make finds

the target install in Makefile and files the directions to install the

program.

This is a very simplified explanation but, in most cases, this is what you

need to know. With most programs, there will be a file named INSTALL

that contains installation instructions that will fill you in on other

considerations. For example, it is common to supply some options to the

configure command to change the final location of the executable program.

There are also other make targets such as clean that remove unneeded files

after an install and, in some cases test which allows you to test the software

between the make and make install steps.

7. Literature review

1. Achieving higher throughput in ieee 802.11 wireless local area

networks with burst transmission methods : As extensions in the

emerging 802.11e for quality-of-service provisioning, burst transmission and

the acknowledgment aggregation are the two important operations to

improve the channel efficiency of IEEE 802.11-based wireless local area

networks (WLANs). However, only a few works have been done on these

operations, and usually assumed the networks to be operated under saturated

traffic conditions and error-free channels. In practice, the assumptions may

not be valid because real-time traffic with proper rate control will not

saturate the networks and the channel is generally error-prone. Thus, the

authors consider two new methods resulted from these operations and

analyse their performance under unsaturated and error-prone WLANs, with

a Markov chain model. The results show that the new methods generally

have better throughput than the conventional IEEE 802.11 medium access

control (MAC) in the WLANs.

2. On the throughput performance of multirate IEEE 802.11 networks

with variable-loaded stations: analysis, modeling, and a novel proportional

fairness criterion: This paper focuses on multirate IEEE 802.11 Wireless

LAN employing the mandatory Distributed Coordination Function (DCF)

option. Its aim is threefold. Upon starting from the multi-dimensional

Markovian state transition model proposed by Malone et.al. for

characterizing the behavior of the IEEE 802.11 protocol at the Medium

Access Control layer, it presents an extension accounting for packet

transmission failures due to channel errors. Second, it establishes the

conditions under which a network constituted by N stations, each station

transmitting with its own bit rate, Rd(s), and packet rate, λs, can be assumed

loaded. Finally, it proposes a modified Proportional Fairness (PF) criterion,

suitable for mitigating the rate anomaly problem of multirate loaded IEEE

802.11 Wireless LANs, employing the mandatory DCF option. Compared to

the widely adopted assumption of saturated network, the proposed fairness

criterion can be applied to general loaded networks. The throughput

allocation resulting from the proposed algorithm is able to greatly increase

the aggregate throughput of the DCF, while ensuring fairness levels among

the stations of the same order as the ones guaranteed by the classical PF

criterion. Simulation results are presented for some sample scenarios,

confirming the effectiveness of the proposed criterion for optimized

throughput allocation.

3. Enhancing quality of service in MANETS by effective routing :

This paper evaluates the performance evaluation by combining Network

layer and MAC layer protocols with Transport layer congestion control

mechanisms operating in a mobile adhoc network. In Adhoc networks,

certain QoS parameters like error rate, delay and packet loss are increased

and certain parameters like throughput and delivery ratio are decreased in

Transport layer is due to MAC problems and disconnection is also possible

due to mobility because the network layer is not able to detect the path to

deliver the packets. So, combine the mechanisms of these three layers to

improve the QoS drastically. We examine the effects of two different MAC

protocols - IEEE 802.11and IEEE802.11e with AODV and DSR of routing

algorithms with Slow start and Arithmetic Increase and Multiplicative

Decrease (AIMD) mechanism of TCP.IEEE802.11 uses distributed

coordination function (DCF) where IEEE802.11e uses enhanced distributed

coordination function (EDCF). Specifically, we access the impact of

multiple wireless hops and node mobility on the throughput performance of

TCP on each MAC protocol with two routing algorithms. Additionally the

other QoS parameters of delay, Bandwidth delay product, delivery ratio and

packet loss is also investigated. Results show that in all instances, the QoS

parameters 15-20% improvement in throughput, 40-45% improvement in

bandwidth-delay product, 10-15% improvement in delivery ratio, packet loss

is reduced drastically to 40-50% in IEEE802.11e with AODV algorithm in

network layer and slow start mechanism in transport layer. Similarly Results

shows, the QoS parameters 35-40% improvement in throughput, 25-30%

improvement in bandwidth-delay product, 15-20% improvement in delivery

ratio, packet loss is reduced drastically to 20-25% in IEEE802.11e with

AODV algorithm in network layer and AIMD mechanism in transport layer.

But if DSR algorithm is used in the network layer instead of AODV it

affects the QoS parameters. In both cases DSR algorithm increases the -

packet loss which in turn affects the throughput and packet delivery ratio.

The reason is analyzed and suggests the suitable mechanisms implemented

in each layer to enhance QoS parameters.

5. A distributed contention control mechanism for power saving in

random-access Ad-hoc wireless local area networks: The power

consumption of mobile computers connected to wireless networks is

negatively affected by the congestion level of the channel, and

significantly depends on the medium access control (MAC) protocol

policy. This paper illustrates the design and the performance evaluation

of a new mechanism for the distributed contention control of the

random accesses to the shared transmission channel of a wireless LAN

(WLAN). The aim is the design of a distributed access scheme where

each frame transmission leads to an optimal power consumption level,

from the network interface (NI) viewpoint. To achieve this goal, we

present a new analytical model to define the optimal average power

consumption required by the NI for a frame transmission, and for a

given random-access scheme. Specifically, we considered the Standard

IEEE 802.11 Distributed Coordination Function (DCF) access scheme

for WLANs. By exploiting the optimal values analytically derived, we

define a parametric and adaptive power-save, distributed contention

control (PS-DCC) mechanism. The proposed mechanism has been

investigated via simulation. The power consumption of the proposed

mechanism approximates the analytically defined optimal level,

outperforming the Standard 802.11 DCF access scheme. To confirm

the absence of overheads introduced, the channel utilization still results

closely approximating the optimal values

6. A Protocol Enhancement for IEEE 802.11 Distributed Power Saving

Mechanisms No Data Acknowledgement: Mobile devices including

wireless LAN functionality are becoming increasingly popular in society.

The wide range of products available in the market target different customer

needs but most of them should meet two main requirements: QoS support

for differentiating real-time services from non real-time and power saving

functionality to achieve an operating time according to users' expectations.

The devices presenting the most challenging technical issues to meet these

two requirements are dual-mode handsets (cellular/WLAN) because of their

mandatory support of a strict QoS demanding application, VoIP, and their

small device size which severely limits the battery capacity. The focus of our

work in this paper is the design and evaluation of an enhancement of the

distributed wireless LAN power saving mechanisms defined in the IEEE

802.11 and 802.11e standards, no data acknowledgment (NDACK). The

objective of NDAck is to increase the battery lifetime of wireless LAN

mobile devices while providing the required QoS. The protocol

improvement designed has been implemented in OPNET to evaluate the

performance enhancements obtained. Our results show that (i) NDAck

significantly reduces the power consumption of stations running real-time

applications, (ii) the larger the power consumption due to the congestion in

the wireless channel the larger the power consumption reduction with

NDAck and (iii) NDAck results in a considerable QoS improvement for

real-time applications.

8 Conclusion & Future Enhancements

8.1 Conclusion

The performance analysis with saturated traffic does not apply to nodes that

do not originate traffic but may forward it in on behalf of others. Sometimes,

these relay stations may not have any packet to forward. Another challenge

is the fact that not all relay stations receive the same amount of data to

forward. This amount is determined by the upper layer routing protocol.

8.2 Future Enhancements

Enhancing the protocol from IEEE802.11 from IEEE802.11 e /

IEEE802.16

9 Appendix

9.1 Source Code
set val(chan) Channel/WirelessChannel

set val(prop) Propagation/TwoRayGround

set val(netif) Phy/WirelessPhy

set val(mac) Mac/802_11

set val(ifq) Queue/DropTail/PriQueue

set val(ll) LL

set val(ant) Antenna/OmniAntenna

set val(x) 800

set val(y) 800

set val(ifqlen) 1500

set val(seed) 1.0

set val(adhocRouting) AODV

set val(nn) 10

set val(stop) 15.0

set val(energymodel) EnergyModel ;

set val(radiomodel) RadioModel ;

set val(initialenergy) 1000 ;# Initial energy in Joules

set ns_ [new Simulator]

set topo [new Topography]

set tracefd [open out.tr w]

set namtrace [open out.nam w]

$ns_ trace-all $tracefd

$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)

$topo load_flatgrid $val(x) $val(y)

set god_ [create-god $val(nn)]

$ns_ node-config -adhocRouting AODV

-llType $val(ll)

-macType $val(mac)

-ifqType $val(ifq)

-ifqLen $val(ifqlen)

-antType $val(ant)

-propType $val(prop)

-phyType $val(netif)

-channelType $val(chan)

-topoInstance $topo

-agentTrace ON

-routerTrace ON

-macTrace ON

for {set i 0} {$i < $val(nn) } {incr i} {

set node_($i) [$ns_ node]

}

set X1(0) 130.32

set X1(1) 235.55

set X1(2) 336.499

set X1(3) 147

set X1(4) 488.23

set X1(5) 374.881

set X1(6) 246.766

set X1(7) 167.161

set X1(8) 419.979

set X1(9) 532.0

set Y1(0) 539.172

set Y1(1) 476.86

set Y1(2) 532.92

set Y1(3) 774.801

set Y1(4) 455.623

set Y1(5) 344.034

set Y1(6) 664.992

set Y1(7) 326.676

set Y1(8) 754.081

set Y1(9) 619.0


$node_($i) set X_ $X1($i)

$node_($i) set Y_ $Y1($i)

$node_($i) set Z_ 0.0

}

puts "Loading scenario file..."


$ns_ initial_node_pos $node_($i) 30

}

for {set i k} {$i < $val(nn) } {incr i} {

$ns_ at $val(stop).0 "$node_($i) reset";

}

puts "-----------------------------------------------"

puts "Routing table"

puts "-----------------------------------------"

puts "|Node | one hop neighbour|"

puts "-----------------------------------------"


for {set j 0} {$j < $val(nn) } {incr j} {

set a [ expr $X1($j)-$X1($i)]

set b [ expr $a*$a]

set c [ expr $Y1($j)-$Y1($i)]

set d [ expr $c*$c]

set e [ expr $b+$d]

set f 0.5

set g [expr pow($e,$f)]

if {$g <= 200 && $i != $j} {

puts "| Node($i) | ($j) |"

}

}

puts "-----------------------------------------"

}

set udp_(0) [new Agent/UDP]

$ns_ attach-agent $node_(0) $udp_(0)

set null1_(0) [new Agent/Null]

$ns_ attach-agent $node_(4) $null1_(0)

set cbr1_(0) [new Application/Traffic/CBR]

$cbr1_(0) set packetSize_ 1000

$cbr1_(0) set interval_ 0.01

$cbr1_(0) set random_ 1

$cbr1_(0) set maxpkts_ 1000

$cbr1_(0) attach-agent $udp_(0)

$ns_ connect $udp_(0) $null1_(0)

$ns_ at 1.00 "$cbr1_(0) start"

$ns_ at 5.3 "$cbr1_(0) stop"

$ns_ at 0.0 "$node_(0) setdest 589 732 5"










$ns_ at 0.05 "$node_(0) label M0"










$ns_ at 0.05 "$node_(0) add-mark m blue circle"

$ns_ at 0.05 "$node_(1) add-mark m gray circle"



$ns_ at 0.05 "$node_(4) add-mark m green circle"






$ns_ at 15.0 "finish"

$ns_ at $val(stop).0002 "puts "NS EXITING..." ; $ns_ halt"

puts $tracefd "M 0.0 nn $val(nn) x $val(x) y $val(y) rp $val(adhocRouting)"

puts $tracefd "M 0.0 prop $val(prop) ant $val(ant)"

puts "Starting Simulation..."

proc finish {} {

#exec nam out.nam &

exit 0

}

REFERENCES

[1] Y. D. Barowski and S. Biaz, “The performance analysis of ieee-802.11

under unsaturated traffic conditions,” Tech. Rep. CSSE04-09, Auburn

University, Aug. 2004.

[2] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, “MACAW: A

media access protocol for wireless LANs,” in ACM SIGCOMM, London,

U.K, pp. 212–225, Oct. 1994.

[3] G. Bianchi, “Performance analysis of the IEEE802.11 distributed

coordination function,” IEEE Journal in Selected Areas: Communication,

vol. 18, pp. 535–547, March 2000.

[4] L. Bononi, M. Conti, and L. Donatiello, “A distributed mechanism for

power saving in IEEE 802.11 wireless lans,” Mobile Networks and

Applications, vol. 6, no. 3, pp. 211–222, 2001.

[5] F. Cali, M. Conti, and Gregori, “IEEE802.11 wireless lan: Capacity

analysis and protocol enhancement,” in INFOCOM ’98 Seventeenth Annual

Joint Conference of the IEEE Computer and Communications Societies.

Proceedings. IEEE, 1998.

[6] M. M. Carvalho and J. J. Garcia-Luna-Aceves, “Delay analysis of the

IEEE802.11 in single-hop networks,” in 11th IEEE International Conference

on Network Protocols (ICNP’03), Atlanta, Georgia, USA, Nov. 2003.

[7] H. S. Chhaya and S. Gupta, “Performance modeling of asynchronous

data transfer methods of IEEE802.11 mac protocol,” Wirel. Netw., vol. 3,

no. 3, pp. 217–234, 1997.

[8] D. S. J. De Couto, D. Aguayo, B. A. Chambers, and R. Morris,

“Performance of multihop wireless networks: Shortest path is not enough,”

in Proceedings of the First Workshop on Hot Topics in Networks (HotNets-

I), (Princeton, New Jersey), ACM SIGCOMM, October 2002.

[9] L. M. Feeney and M. Nilsson, “Investigating the energy consumption

of a wireless network interface in an ad hoc networking environment,” in

IEEE INFOCOM, Anchorage, AK, USA, 2001.

[10] L. Huang and T.-H. Lai, “On the scalability of IEEE802.11 ad hoc

networks,” in Proceedings of the 3rd ACM international symposium on

Mobile ad hoc networking & computing, pp. 173–182, ACM Press, 2002

Cloud data management

More Related Content

What's hot

Viewers also liked

Similar to Cloud data management

More from ambitlick

Recently uploaded

Cloud data management