1. 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
2. • 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
3. 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
4. 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
5. 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
6. • 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.
7. 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.
8. * 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.
9. 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
10. 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;
11. • 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.
12. 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
13. • 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
14. 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
15. 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.
16. 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
17. 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
18. 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
19. Level 2:
Source Relay Node Destination
One hop neighbor
Traffic Monitoring IEEE802.11
protocol
5.5 Use case Diagram
20. Intermediate
Source Relay Destination
Station
Request
One hop neighbor
Response
IEEE802.11
Routing
Traffic Monitoring
6. System Testing
21. 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)
22. 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)
23. • 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)
24. 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:
25. 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
26. 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
27. 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.
28. • 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.
29. 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.
30. 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
31. 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
32. 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.
33. 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,
34. 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
35. 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
36. 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
37. 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)
38. -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
39. 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
for {set i 0} {$i < $val(nn) } {incr i} {
$node_($i) set X_ $X1($i)
$node_($i) set Y_ $Y1($i)
$node_($i) set Z_ 0.0
}
puts "Loading scenario file..."
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ initial_node_pos $node_($i) 30
40. }
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 i 0} {$i < $val(nn) } {incr i} {
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]
41. 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)
42. $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.0 "$node_(1) setdest 294 670 5"
$ns_ at 0.0 "$node_(2) setdest 395 726 5"
$ns_ at 0.0 "$node_(3) setdest 405 765 5"
$ns_ at 0.0 "$node_(4) setdest 147 649 5"
$ns_ at 0.0 "$node_(5) setdest 733 537 5"
$ns_ at 0.0 "$node_(6) setdest 605 758 5"
$ns_ at 0.0 "$node_(7) setdest 426 520 5"
$ns_ at 0.0 "$node_(8) setdest 378 647 5"
$ns_ at 0.0 "$node_(9) setdest 490 612 5"
$ns_ at 0.05 "$node_(0) label M0"
$ns_ at 0.05 "$node_(1) label M1"
$ns_ at 0.05 "$node_(2) label M2"
$ns_ at 0.05 "$node_(3) label M3"
$ns_ at 0.05 "$node_(4) label M4"
$ns_ at 0.05 "$node_(5) label M5"
$ns_ at 0.05 "$node_(6) label M6"
$ns_ at 0.05 "$node_(7) label M7"
$ns_ at 0.05 "$node_(8) label M8"
43. $ns_ at 0.05 "$node_(9) label M9"
$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_(2) add-mark m gray circle"
$ns_ at 0.05 "$node_(3) add-mark m gray circle"
$ns_ at 0.05 "$node_(4) add-mark m green circle"
$ns_ at 0.05 "$node_(5) add-mark m gray circle"
$ns_ at 0.05 "$node_(6) add-mark m gray circle"
$ns_ at 0.05 "$node_(7) add-mark m gray circle"
$ns_ at 0.05 "$node_(8) add-mark m gray circle"
$ns_ at 0.05 "$node_(9) add-mark m gray 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
}
52. 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.
53. [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