Final Rough

Optimizing the Redundancy Using CHORUS in Wireless Networks
1. INTRODUCTION
1.1 Wireless Network
Wireless networks are computer networks that are not connected by cables of any
kind. The use of a wireless network enables enterprises to avoid the costly process of
introducing cables into buildings or as a connection between different equipment
locations. The basis of wireless systems are radio waves, an implementation that takes
place at the physical layer of OSI model network structure. Wireless networks use radio
waves to connect devices such as laptops to the Internet, the business network and
applications. When laptops are connected to Wi!i hot spots in public places, the
connection is established to that business"s wireless network.
Fig 1.1: Wireless Network
There are four main types of wireless networks
#ept. of $%$, &ITS, 'a(ampet Page 1
Wireless Local Area Network (LAN): )inks two or more devices using a
wireless distribution method, providing a connection through access points to the
wider Internet.
Wireless Wide Area Network (WAN): %overs large areas such as neighboring
towns and cities.
Wireless Metropolita Area Networks (MAN): %onnects several wireless
)&*s.
Wireless !ersoal Area Network (!AN): Interconnects devices in a short span,
generally within a person"s reach.
1.1.1 Wireless LAN:
& wireless local area network +W)&*, links two or more devices using some
wireless distribution method +typically spreadspectrum or O!#-radio,, and usually
providing a connection through an access point to the wider Internet. This gives users the
Fig.1.2: Simple WLAN
-obility to move around within a local coverage area and still be connected to the
network. -ost modern W)&*s are based on I""" #$%.11 standards, marketed under
the Wi&'i brand name.
The technology W)&* I$$$ ./0.11 allows the connection of multiple devices
using systems in radiofrequency +'!,, hence no need for wiring. In the ./0.11 family of
standards most used in the creation of local networks are the standards
#$%.11( and #$%.11) operate in the 0.2 345 band with transmission speed rated
respectively 11 and 62-bps transmission speed The actual single connection is a
function of wireless signal strength received and the number of users simultaneously
using the same access point. The coverage of the W)&* signal varies from a few tens of
meters up to several kilometers, depending on the type of environment +obstacles, height,
angle of transmission, etc., &nd the protocol used. It is thus possible to create local
networks within a single building or point to point connections between different
buildings.
1.1.% Wireless WAN:
& Wide &rea *etwork +W&*, is a network that spans a large geographical area,
the most common e7ample being the Internet the largest known W&* today. Typically, a
W&* consists of two or more )ocal &rea *etworks +)&*s, connected by a
communication subsystem, which usually comprised of &utonomous System +&S,
routers.
Special software protocols have been created to support routing within
communication subsystem of a W&*. These protocols operate with 8smart" algorithms
that can adapt the flow of network traffic when problems occur. 9rotocols such as :order
3ateway 9rotocol +:39, are widely used across the Internet today and this is the primary
protocol used on the &irStream Wireless network. The algorithms employed by this
protocol provide great network stability ensuring that if one network connection is lost,
the router can quickly adapt to send data through an alternate network path.
%onsequently, the greater the number of network connections that are available, the
Fig 1.3: Wireless WAN
3reater the reliability and bandwidth for its users. The wireless connections between
access points are usually point to point microwave links using parabolic dishes on the
0.2 345 band, rather than omnidirectional antennas used with smaller networks. &
typical system contains base station gateways, access points and wireless bridging relays.
Other configurations are mesh systems where each access point acts as a relay also. When
combined with renewable energy systems such as photovoltaic solar panels or wind
systems they can be standalone systems.
1.1.* Wireless MAN:
& -etropolitan &rea *etwork +-&*, is optimi5ed for a larger geographical area
than a )&*, ranging from several blocks of buildings to entire cities. -&*s can also
depend on communications channels of moderatetohigh data rates. & -&* might be
owned and operated by a single organi5ation, but it usually will be used by many
individuals and organi5ations. -&*s might also be owned and operated as public
utilities. They will often provide means for internetworking of local networks. It is
a computer network in which two or more computers or communicating devices or
networks which are geographically separated but in same metropolitan city and are
connected to each other are said to be connected on -&*.The limits of -etropolitan
cities are determined by local municipal corporations and we cannot define them. 4ence,
Fig 1.4: Wireless MAN
the bigger the -etropolitan city the bigger the -&*, smaller a metro city smaller the
-&*.
1.1.+ Wireless !AN:
& 9ersonal &rea *etwork +9&*, is a computer network used
for communication among computeri5ed devices,including telephones and personal
digital assistants. 9&*s can be used for communication among the personal devices
themselves +intrapersonal communication,, or for connecting to a higher level network
and the Internet. & Wireless 9ersonal &rea *etwork +W9&*, is a 9&* carried
over wireless network technologies such as Wireless ;S:, :luetooth, <Wave, <ig:ee,
or even :ody &rea *etwork. The reach of a W9&* varies from a few centimeters to a
few meters. & 9&* may also be carried over wired computer buses such
as ;S: and !ireWire.
Fig 1.5: Wireless Personal Area Network
Wireless personal area networks +W9&*s, cover smaller areas with low power
transmission for network of portable and mobile computing devices such as 9%s and
personal digital assistants +9#&s,. The portable consumer electronics and
communications devices are essentially very small computers designed to consume as
little power as possible in order to increase the lifetime of their batteries.
1.% Di,,erece ,ro- Wireless .esor Network:
& wireless sensor network +WS*, consists of spatially distributed autonomous
sensors to monitor physical or environmental conditions, such as temperature, sound,
pressure, etc. and to cooperatively pass their data through the network to a main location.
The more modern networks are bidirectional, also enabling control of sensor activity.
The development of wireless sensor networks was motivated by military applications
such as battlefield surveillance= today such networks are used in many industrial and
consumer applications, such as industrial process monitoring and control, machine health
monitoring, and so on.
The WS* is built of >nodes> ? from a few to several hundreds or even thousands,
where each node is connected to one +or sometimes several, sensors. $ach such sensor
network node has typically several parts@ a radio transceiver with an internal antenna or
connection to an e7ternal antenna, a microcontroller, an electronic circuit for interfacing
with the sensors and an energy source, usually a battery or an embedded form of energy
harvesting. & sensor node might vary in si5e from that of a shoebo7 down to the si5e of a
grain of dust, although functioning >motes> of genuine microscopic dimensions have yet
to be created. The cost of sensor nodes is similarly variable, ranging from a few to
hundreds of dollars, depending on the comple7ity of the individual sensor nodes. Si5e
and cost constraints on sensor nodes result in corresponding constraints on resources such
as energy, memory, computational speed and communications bandwidth. The topology
of the WS*s can vary from a simple star network to an advanced multihop wireless
mesh network.
Figure 1.: !"pi#al multi$%op wireless Sensor Network &WSN'
1.* Di,,ereces ,ro- Mo(ile ad /oc Networks:
We studied mobile ad hoc networks +-&*$Ts,, It is made up of a number
of wireless mobile nodes. 4owever, there are significant differences between -&*$Ts
and WS*s.
The number of sensor nodes in a sensor network is much more than that in an ad
hoc network. ;sually sensor networks consist of 1,/// to 1/,/// sensor nodes covering
the area. Sensor nodes are generally static and cooperate together to transfer the sensed
data. In mobile ad hoc networks, the numbers of nodes are much less, but their mobility
is very high. Sensor nodes mainly use the broadcast communication paradigm, whereas
most ad hoc networks are based on pointtopoint communication.
&nother difference between the two is that sensor nodes have a much lower power
consumption requirement, of the order of /.A6 mW.
1.% Wireless MAC !rotocols:
In the sevenlayer OSI model of computer networking, Media Access
Cotrol +MAC, data communication protocol is a sub layer of the data link layer, which
itself is layer 0. The -&% sub layer provides addressing and channel access control
mechanisms that make it possible for several terminals or network nodes to communicate
within a multiple access network that incorporates a shared medium, e.g. $thernet. The
hardware that implements the -&% is referred to as a Medium Access Controller.
The -&% sub layer acts as an interface between the logical link control +))%,
sub layer and the networkBs physical layer. The -&% layer emulates a fullduple7 logical
Fig 1.(: MA) in *S+ Mo,el
%ommunication channel in a multipoint network. This channel may provide Uicast,
M0lticast or 1roadcast communication service.
%ommon multiple access protocols that may be used in packet radio wireless
networks are
&)O4&
Slotted &)O4&
%S-&
%S-&C%&
1.%.1 ALO2A !rotocol:
This first version of the protocol +called >9ure &)O4&>, was quite simple@
Step1@ If you have data to send, send the data
Step0@ If the message collides with another transmission, try resending >later>
StepD@ On collision, sender waits random time before trying again
Fig 1.-: Pa#ket !ransmission .sing AL*/A
!ew simplifying assumptions in 9ure &)O4& are
1. &ll frames have the same length
0. Stations cannot generate a frame while transmitting or trying to transmit. +That is,
if a station keeps trying to send a frame, it cannot be allowed to generate more
frames to send.,
D. The population of stations attempts to transmit +both new frames and old frames
that collided, according to a 9oisson distribution.
1.%.% .lotted ALO2A !rotocol:
&n improvement to the original &)O4& protocol was >Slotted &)O4&>, which
introduced discrete timeslots and increased the ma7imum throughput. & station can send
only at the beginning of a timeslot, and thus collisions are reduced. In this case, we only
need to worry about the transmissionattempts within 1 frametime and not 0 consecutive
frametimes, since collisions can only occur during each timeslot.
Fig 1.0: Pa#ket !ransmission .sing Slotte, AL*/A
1.%.* C.MA !rotocol:
Carrier .ese M0ltiple Access +C.MA, is a probabilistic -edia &ccess
%ontrol +-&%, protocol in which a node verifies the absence of
other traffic before transmitting on a shared transmission medium, such as an electrical
bus, or a band of the electromagnetic spectrum. Carrier sense means that
a transmitter uses feedback from a receiver to determine whether another transmission is
in progress before initiating a transmission. That is, it tries to detect the presence of
a carrier wave from another station before attempting to transmit. If a carrier is sensed,
the station waits for the transmission in progress to finish before initiating its own
transmission. In other words, %S-& is based on the principle >sense before transmit> or
>listen before talk>. -ultiple access means that multiple stations send and receive on the
medium. Transmissions by one node are generally received by all other stations
connected to the medium.
1.%.+ C.MA3CA !rotocol:
Carrier sese -0ltiple access wit/ collisio a4oidace +C.MA3CA,
in computer networking, is a network multiple access method in which carrier sensing is
used, but nodes attempt to avoid collisions by transmitting only when the channel is
sensed to be >idle>. It is particularly important for wireless networks, where the collision
detection of the alternative %S-&C%# is unreliable due to the hidden node problem.
%S-&C%& is a protocol that operates in the #ata )ink )ayer +)ayer 0, of the OSI model.
%ollision avoidance is used to improve the performance of the %S-& method by
attempting to divide the channel somewhat equally among all transmitting nodes within
the collision domain.
1. Carrier .ese@ :efore transmitting, a node first listens to the shared medium
+such as listening for wireless signals in a wireless network, to determine whether
another node is transmitting or not. The hidden node problem means another
node may be transmitting which goes undetected at this stage.
Fig 1.11: )SMA2)A Simpli3e, Algorit%m
0. Collisio A4oidace@ If another node was heard, it will wait for a period of time
for the node to stop transmitting before listening again for a free communications
channel.
D. Re50est to .ed3Clear to .ed +'TSC%TS,@ -ay optionally be used at this point
to mediate access to the shared medium. This goes some way to alleviating the
problem of hidden nodes because, for instance, in a wireless network, the &ccess
9oint only issues a Clear to Send to one node at a time. 4owever,
wireless ./0.11 implementations do not typically implement 'TSC%TS for all
transmissions= they may turn it off completely, or at least not use it for small
packets +the overhead of 'TS, %TS and transmission is too great for small data
transfers,.
2. Tras-issio@ If the medium was identified as being clear or the node received a
%TS to e7plicitly indicate it can send, it sends the frame in its entirety.
;nlike %S-&C%#, it is very challenging for a wireless node to listen at the same
time as it transmits. %ontinuing the wireless e7ample, the node awaits receipt of
an acknowledgement packet from the &ccess 9oint to indicate the packet was
received and checksummed correctly. If such acknowledgement does not arrive
after a timely manner, it assumes the packet collided with some other
transmission, causing the node to enter a period of binary e7ponential back
off before attempting to retransmit.
The limitation of %S-&C%& is that it"s finetuned sensing and scheduling reduces
collision but %S-&C%& inevitably misses transmission opportunities thus lowering
channel usage and spatial reuse. This problem becomes acute, especially for network
wide broadcast with latency constraints. !ig. 1.11 illustrates a typical scenario where
%S-&C%& restricts the broadcast efficiency. With %S-&C%&, the delivery of one packet
from source S to all other nodes requires at least three time slots. & and : cannot transmit
concurrently, even if they have to forward the same packet. Suppose node # in a lossy
Fig 1.11: 4roa,#ast wit% tra,itional )SMA2)A
network had already received the packet, while % and $ await its retransmission from &
and :, respectively. &n optimal scheduling protocol would be oblivious of the collision at
#, and allow & and : to transmit the packet concurrently. 4owever, this is not possible in
%S-&C%&, as one of them will defer its transmission immediately upon sensing the
other"s activity.
1.6 .7ste- .t0d7:
1.6.1 'easi(ilit7 .t0d7
The feasibility of the pro(ect is analy5ed in this phase and business proposal is put
forth with a very general plan for the pro(ect and some cost estimates. #uring system
analysis the feasibility study of the proposed system is to be carried out. This is to ensure
that the proposed system is not a burden to the company. !or feasibility analysis, some
understanding of the ma(or requirements for the system is essential.
Three key considerations involved in the feasibility analysis are
$conomic feasibility
Technical feasibility
Social feasibility
1.6.% "coo-ic 'easi(ilit7
This study is carried out to check the economic impact that the system will have
on the organi5ation. The amount of fund that the company can pour into the research and
development of the system is limited. The e7penditures must be (ustified. Thus the
developed system as well within the budget and this was achieved because most of the
technologies used are freely available. Only the customi5ed products had to be purchased.
1.6.* Tec/ical 'easi(ilit7
This study is carried out to check the technical feasibility, that is, the technical
requirements of the system. &ny system developed must not have a high demand
on the available technical resources. This will lead to high demands on the
available technical resources. This will lead to high demands being placed on the
client. The developed system must have a modest requirement, as only minimal or
null changes are required for implementing this system.
1.6.+ .ocial 'easi(ilit7
The aspect of study is to check the level of acceptance of the system by the user.
This includes the process of training the user to use the system efficiently. The user must
not feel threatened by the system, instead must accept it as a necessity. The level of
acceptance by the users solely depends on the methods that are employed to educate the
user about the system and to make him familiar with it. 4is level of confidence must be
raised so that he is also able to make some constructive criticism, which is welcomed, as
he is the final user of the system.
%. LIT"RATUR" .UR"89
%.1. INTRODUCTION
*etworkwide broadcast is a fundamental primitive for many communication
protocols in multihop wireless networks, such as route discovery and information
dissemination. &n efficient broadcast protocol needs to deliver a packet +or a continuous
stream of packets, from the source node to all other nodes in the network, with high
packetdelivery ratio +9#', and low latency. To improve 9#' in a lossy network,
multiple relay nodes can forward and retransmit each packet, thereby creating
retransmission diversity. To reduce latency and resource usage, however, the number of
transmissions must be kept to minimum, since redundant retransmissions waste channel
time, slowing down the packet"s delivery to the edge of the network. Therefore, a delicate
balance needs to be maintained between 9#' and delay.
!or the efficient broadcast support, in the form of practical protocol design has
mostly focused on the %S-&C%& -&%layer scheduling model. %S-&C%& has proven
to be an effective distributed scheduling scheme, especially via the ./0.11 family of
-&% standards. The limitation of %S-&C%&, however, has not been e7amined carefully
in case of networkwide broadcast. While it"s finetuned sensing and scheduling reduces
collision, %S-&C%& inevitably misses transmission opportunities, lowering channel
usage and spatial reuse. This problem becomes acute, especially for networkwide
broadcast with latency constraints.
4ere we introduced a novel broadcast protocol, called %horus, based on a -&%
layer that adopts %S-& with collision resolution +%S-&C%',. %horus is built upon the
key insight that packets carrying the same data can be detected and decoded, even when
they overlap at the receiver with comparable strength. With %horus, collision of the same
packets from different relays can be effectively resolved. The advantage of such a
collisiontolerant protocol is obvious, with collision resolution, & and : can now transmit
packets immediately and independently after receiving them from the source.
%.%. Mod0les Descriptio:
%.%.1 Desi) o, M0lti&/op Wireless Networks
-ultihop wireless networks use two or more wireless hops to convey
information from a source to a destination.
Fig 2.1: Multi%op Wireless Network
In the !ig 0.1 shows a simple multihop wireless network which contains a Source
node S, destination node # and intermediate relay nodes !. The characteristics of
multihop wireless network is shown below. !or each node the transmission range is set to
06/m and the interference range is set to 66/m and the other wireless characters are
shown below.
.
D
'
1 '
%
'
*
'
+
'
6
'
:
Since we are using the Wireless Scenario hence we selected the channel or
medium as Wireless %hannel. The propagation channel used here is a Two'ay3round
propagation. Since it is a wireless network we to set Wireless9hy in the ns0. The -ac
layer protocol in our pro(ect is e7tension for the e7isting -&% ./0.11 %S-&C%&
protocol. 4ence the -&% protocol here we mention as -acC./0.11. The Eueue type here
we consider a Eueue instead of #rop tail and 9reEueue which serves as first come first
serve basis. The antenna type is a Omni #irectional antenna which has the gain equal to
one. The F and G represents the area dimensions we set as 1///H1/// m
0
. -a7imum
9ackets to be sent is set to 16//. The routing protocol here implemented is a new protocol
which is an e7tension to the %S-&C%& called %S-&C%' +%horus,. !inally the
simulation time here we set to 16 minites.
set Ial+%han, Wireless %hannel
set Ial+prop, Two'ay3round
set Ial+netif, Wireless9hy
set Ial+-ac, -acC./0J11
set Ial+ifq, Eueue
set Ial+ll, ))
set Ial+ant, Omni &ntenna
set Ial+7, 1///
set Ial+y, 1///
set Ial+ifqlen, 16//
set Ial+adhoc'outing, %S-&C%'
set Ial+nn, 0/
set Ial+stop, 16./
%.%.% Collisio Resol0tio i C2ORU.:
We introduced the physicallayer collision resolution in %horus, focusing on how
to detect, decode, and combine the collided packets to achieve the diversity gain.
Detecti) Collided !ackets:
In %horus a transmitter attaches a known random sequence to the beginning of
each packet as a preamble. The receiver then uses a matched filter to detect the e7act
arrival time of this preamble. & matched filter is an optimal linear correlator that
ma7imi5es the S*' when correlating unknown signals with a known sequence. It outputs
a peak value whenever the packet preamble is detected, even if the preamble is hidden in
a strong noise. It operates continuously, so that those preambles overlapping with other
packets can still be identified. The number of preambles detected in a run indicates the
number of overlapping packets at the receiver. The peak output grows linearly with the
number of bits in the preamble, and with the 'SS of the packet. Therefore, the detection
threshold is also a linear function of these two factors. It has been observed that using a
D0bit pseudorandom preamble, the collision detection probability is higher than K.
percent under practical wireless settings. 4ence, the preamble introduces negligible
overhead to the packet.
Iterati4e Resol0tio o, Collisio:
Since a packet usually consists of thousands of symbols, the probability of two
collided packets being aligned perfectly is close to /. In practice, the higher layer
operations at transmitters introduce further randomness, resulting in asynchronous
arrivals. We identify the natural offset between the two packets by detecting their
preambles. Within the offset region, no collision occurs. We first decode the clean
symbols therein, and then iteratively subtract such known symbols from the collided
ones, thereby obtaining the desired symbol.
Fig 2.2 +terati5e ,e#o,ing o6 two #olli,e, Pa#kets #arr"ing same ,ata
!ig. 0.0 shows collision of two packets +head packet 91 and tail packet 90, from
different transmitters. We first decode the two clean symbols & and : in 91. Symbol % is
corrupted as it collides with &
1
in 90, resulting in a combined symbol S. To recover %,
note that symbols &
1
and & carry the same bit, but the analog forms are different because
of channel distortion. Therefore, we need to reconstruct an image of &
1
by emulating the
channel distortion over the corresponding bit that is already known via &. &fter
reconstruction, we subtract the emulated &
1
from S, obtaining a decision symbol for %.
Then, the decision symbol is normali5ed using the channel estimation for 91, and a slicer
decides if the bit in % is / or 1. The slicer outputs / if the normali5ed decision symbol has
*egative real part, and 1 otherwise. The decoded bit in % is then used to reconstruct %
1
and decode $. This process iterates until the end of the packet is reached. :esides the
iterative decoding in the forward direction, %horus can also work backward, starting from
the clean symbols in 90 +i.e., symbol G
1
and <
1
,, to its beginning, hence obtaining a
different estimation of the packet.
!acket Co-(iatio:
Since 91 and 90 may have different strengths, their decoding confidence also
differs. The decoding confidence is indicated by the magnitude of the decision symbol.
The farther away it is from the decoding threshold +/ in :9SL,, the higher probability it
can produce the correct bit, since this is equivalent to a higher S*'. %ombining two
decision symbols carrying the same bits +e.g., & and &
1
in !ig.0.0, can increase the
decoding confidence. This is because the useful information is enhanced, while the noise
within the two symbols is not combined coherently. !or those iteratively decoded
packets, we only use Selective combination, i.e., assigning weight 1 to the packet with
the highest S*', and / to all other packets. This is because a weighted combination over
two iteratively decoded packets does not improve S*'. In fact, the iterative collision
resolution in %horus can cause error propagation, due to the correlation between
consecutively decoded symbols. !or e7ample, in !ig.0.0, if symbol & produces an
erroneous bit, then the error propagates to &
1
, which affects subsequent symbols such as
%. !ortunately, such error propagation stops if the actual bits of &
1
and % are the same. In
this case, after subtracting the error image of &
1
, we obtain a strengthened symbol that
indicates the correct bit of %. $rror propagation also stops when symbol % has a much
higher strength than &
1
. :ased on these two observations, we can bound %horus :$',
showing that the probability of error propagation decays e7ponentially with the error
length.
%.%.* Co)iti4e sesi) ad (roadcast sc/ed0li):
%horus physicallayer collision resolution must be integrated with the -&% layer,
in order to reduce unresolvable collisions occurring when packets with different data
collide.
MAC La7er Co)iti4e .esi) ad .c/ed0li):
%horus" -&% layer maintains the carrier sensing and backoff in the ./0.11
based %S-& protocol, but adopts cognitive sensing that e7ploits the collisionresolution
feature, while avoiding unresolvable collisions. The principle of cognitive sensing is to
decode the identity of the packet on the air, and accordingly, make the transmission
decision. To this end, %horus needs to add a new header field into the ./0.11 packet.
C/or0s !acket 'or-at:
!ig. 0.D illustrates the broadcast packet format in %horus. !irst, a known random
sequence is attached to facilitate packet detection and offset identification. Second, a
%horus header field is added, which informs the receiver of the packet"s identity,
including the broadcast source"s I# and the packet"s sequence number. & 1Mbit %yclic
'edundancy %heck +%'%, is included in this header. In case of %'% failure, this packet
is discarded as it conveys wrong identity information. When the headers of two packets
Fig 2.3 Pa#ket 6ormat in )%orus
collide, %horus proceeds with the iterative decoding, assuming they have the same
identity. &fter the decoding, it performs %'% over the header of each packet to ensure
they are identical. If not, a decoding failure occurs, and both packets will be discarded. &
decoding failure also occurs when the %'% check over the payload fails.
.c/ed0li) o, .esi) ad Tras-issios:
With the collisionresolution capability, each transmitter calls a S$*# procedure
to perform cognitive sensing, as shown in !ig.0.2 Transmitters make scheduling decision
following three rules
'ule1@ !orward a packet immediately if the channel is idle.
'ule0@ If the channel is busy, and the packet on the air is e7actly one of the
packets in the transmit queue, then start transmission of the pending packet.
'uleD@ If the channel is busy, but a preamble cannot be detected, or the header
field of the packet on the air cannot be decoded, or a different packet is on the air, then
start the backoff procedure according to the ./0.11
'ule1 is typical of all %S-& protocols. 'ule0 is unique to %horus"s %S-&C%'.
It enforces the principle of %horus, i.e., overlapping packets carrying the same data may
not cause collisions. Instead, by collision resolution, these packets offer transmit diversity
to the receiver. Therefore, a sender node can transmit its pending packet if it has the same
identity as the one on the air. 'D ensures friendliness to alien traffic, and is relevant for
multisource broadcast and coe7istence with %S-&C%&based unicast traffic. To prevent
unresolvable collisions between different packets, %horus starts the normal ./0.11 back
Fig 2.4 MA)$la"er #ontrol 7ow in )%orus
off if it senses that the channel is occupied by such alien traffic. To reduce interference to
coe7isting traffic, it also backs off conservatively if the identity of the packet on the air
cannot be decoded.
The advantages of cognitive sensing and scheduling come at the e7pense of
additional overhead. In ./0.11b, the sensing time slot is 0/ Ns, equivalent to the channel
time of 0/ bits in the broadcast mode. In contrast, %horus needs to sense over the entire
preamble and the header. 4owever, this overhead is negligible compared to the packet
length.
.c/ed0li) Network&Wide 1roadcast:
%ompared to e7isting %S-&C%&based broadcast protocols, %horus has the
following salient features@
1. &nonymity@ The source and relays do not require any topology information or neighbor
identity. &s a result, it is insensitive to node mobility, and incurs no control message
overhead.
0. #ecentrali5ation@ $ach node only needs to maintain local states recording the most
recent packet I# that it forwarded for a broadcast session +corresponding to a source I#,.
D. #iversity@ :y decoding multiple copies of the same packet, %horus gains diversity, and
hence, robustness to link losses
Fig 2.5 )ontrol 7ow 6or s#%e,uling network wi,e 8roa,#ast
!ollowing the S'% procedure in !ig. M, the source node composes a %horus
packet, and transmits it like a normal ./0.11 broadcast packet. &ny neighbor overhearing
this packet will provide besteffort service by forwarding it once, following the
!O'W&'# procedure. 'eceivers with overlapped packets perform collision resolution
before continuing with the packet relaying. &fter each successful reception, a receiver
flushes those pending packets with obsolete seq, in order to prevent unresolvable
collisions between packets with different sequence numbers In case of continuous
broadcast of packets, the source distributes a batch of packets over the network. In such a
scenario, %horus controls the source rate to prevent congestion and avoid collision
between packets with consecutive sequence numbers.
To improve the reliability of continuous broadcast, the source node can
rebroadcast each packet. Intermediate relays need to distinguish rebroadcast packets from
the firstCoriginal version. This is achieved by splitting the seq field into broadcast
sequence and packet sequence. To make a tradeoff between delay and reliability, the
source node limits the ma7imum number of retransmissions for each packet.
When multiple broadcast sessions are running concurrently, their packets are
identified through the sourceid field in the header part. $ach relay maintains a transmit
queue storing the packets to be forwarded. When the channel is idle, it directly transmits
the headofline packet. Otherwise, it follows the -&%layer cognitive scheduling
protocol, which ma7imi5es the spatial reuse opportunity by scheduling the same packets,
while avoiding collision with other broadcast sessions.
%.*. Data 'low Dia)ra-
)evel /@
)evel 1@
)evel 0@
%.+ .e50ece Dia)ra-:
Source *ode
%horus ? decoding
scheme
%ognitive
sensing
%horus ? decoding
scheme
'etransmissio
n
'eceiver
*ode
%ognitive
sensing
%horus
:roadcast
'etransmiss
ion
%ognitive sensing
Sender
'elay 1 'elay 0 'elay D 'eceiver
%ognitive 'adio %ongestion *etwork
%ollision resolution
scheme
%horus ? decoding scheme
'elay 1
*. .O'TWAR" R";UIR"M"NT.
Operating System @ )inu7 ? red hat K./
9rogramming 9ackage @ %OO, T%)
Tool ;sed @ I-ware Work station
CHORUS Protocol
Iersion @ *S0 0.D1
*.1. N.% .tr0ct0re Itrod0ctio
*S0 is an ob(ect oriented simulator, written in %OO, with a Tcl interpreter as a
frontend. The simulator supports a class hierarchy in %OO +also called the compiled
hierarchy,, and a similar class hierarchy within the Tcl interpreter +also called the
interpreted hierarchy,.
Fig 3.1: NS2 internal s#%emati# ,iagram
The two hierarchies are closely related to each other= from the user"s perspective,
there is a onetoone correspondence between a class in the interpreted hierarchy and one
in the compiled hierarchy.
*S0 uses two languages because it has two different kinds of things it needs to
do@ #etailed simulations of protocols require a systems programming language which can
efficiently manipulate bytes, packet headers, and implement algorithms that run over
large data sets. !or these tasks runtime is important and turnaround time +run
simulation, find bug, fi7 bug, recompile, rerun, is less important. %OO is fast to run but
slower to change, making it suitable for detailed protocol implementation.
& large part of network research involves slightly varying parameters or
configurations, or quickly e7ploring a number of scenarios. In these cases, iteration time
+change the model and rerun, is more important. Since configuration runs once +at the
beginning of the simulation,, runtime of this part of the task is less important. Tcl runs
slower than %OO but can be changed very quickly +and interactively,, making it ideal for
simulation configuration.
;sers create new simulator ob(ects through the Tcl interpreter. These ob(ects are
instantiated within the interpreter, and are closely mirrored by a corresponding ob(ect in
the compiled hierarchy. %lass Tcl Ob(ect is the base class for most of the other classes in
the interpreted and compiled hierarchies. $very ob(ect in the class Tcl Ob(ect is created
by the user from within the interpreter. &n equivalent shadow ob(ect is created in the
compiled hierarchy. The two ob(ects are closely associated with each other.
The interpreted class hierarchy is automatically established through methods
defined in the class Tcl %lass. ;ser instantiated ob(ects are mirrored through methods
defined in the class Tcl Ob(ect.
*.%. Tcl 3 C<< 8aria(le 1idi)
%lass Instars defines the methods and mechanisms to bind a %OO member
variable in the compiled shadow ob(ect to a specified Tcl instance variable in the
equivalent interpreted ob(ect. The binding is set up such that the value of the variable can
be set or accessed either from within the interpreter, or from within the compiled code at
all times.
Whenever the variable is read through the interpreter, the trap routine is invoked
(ust prior to the occurrence of the read. The routine invokes the appropriate get function
that returns the current value of the variable. This value is then used to set the value of the
interpreted variable that is then read by the interpreter. )ikewise, whenever the variable is
set through the interpreter, the trap routine is invoked (ust after to the write is completed.
The routine gets the current value set by the interpreter, and invokes the
appropriate set function that sets the value of the compiled member to the current value
set within the interpreter.
The basic primitive for creating a node is@
set ns [new Simulator
!ns node
The instance procedure node constructs a node out of simpler classifier ob(ects +to
be discussed later,. The *ode itself is a standalone class in Tcl. 4owever, most of the
components of the node are themselves TclOb(ects.
Fig 3.2: No,e stru#ture.
This simple structure consists of two TclOb(ects@ an address classifier +classifierJ,
and a port classifier +dmu7J,. The function of these classifiers is to distribute incoming
packets to the correct agent or to correct outgoing link.
*.*. Trace ad Moitori) .0pport
There are a number of ways of collecting output or trace data on a simulation.
3enerally, trace data is either displayed directly during e7ecution of the simulation, or
+more commonly, stored in a file to be postprocessed and analy5ed. There are two
primary but distinct types of monitoring capabilities currently supported by the simulator.
The first, called traces, record each individual packet as it arrives, departs, or is dropped
at a link or queue. Trace ob(ects are configured into a simulation as nodes in the network
topology, usually with a Tcl P%hannelQ ob(ect hooked to them, representing the
destination of collected data +typically a trace file in the current directory,. The other
types of ob(ects, called monitors, record counts of various interesting quantities such as
packet and byte arrivals, departures, etc.
*.+. .i-0lator
The simulator is an eventdriven simulator. The scheduler runs by selecting the
ne7t earliest event, e7ecuting it to completion, and returning to e7ecute the ne7t event.
;nit of time used by scheduler is seconds. 9resently, the simulator is singlethreaded and
only one event in e7ecution at any given time. If more than one event is scheduled to
e7ecute at the same time, their e7ecution is performed on the !I!O manner +first
scheduled ? first dispatched,. *o partial e7ecution of events or preemption is supported.
&n event generally comprises an event time, event id and a handler function. Two
types of ob(ects are derived from the base class $vent packets events and PateventsQ.
9ackets events will be discussed later in detail.
&n >atevent> is a Tcl procedure e7ecution scheduled to occur at a particular time.
This is frequently used in simulation scripts. & simple e7ample of how it is used is as
follows@
set ns [new Simulator
!ns use"scheduler Heap
!ns at #$$.% &'inish&
This Tcl code first creates a simulation ob(ect, then changes the default scheduler
implementation to be heapbased, and finally schedules the function >finish> to be
e7ecuted at time D//.6 +in seconds,.
In communication and computer network research, network simulation is a
technique where a program models the behavior of a network either by calculating the
interaction between the different network entities +hostsCrouters, 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
con(unction with live applications and services in order to observe endtoend
performance to the user desktop, this technique is also referred to as network emulation.
*.6 Network .i-0lator
& network simulator is a software program that imitates the working of a
computer network. In simulators, the computer network is typically modeled with
devices, traffic etc and the performance is analy5ed. Typically, users can then customi5e
the simulator to fulfill their specific analysis needs. Simulators typically come with
support for the most popular protocols in use today, such as W)&*, Wi-a7, ;#9, and
T%9.
*.6.1 W/7 Network .i-0latio=
protocol validation
controlled e7perimental conditions
low cost in R, time, collaboration, comple7ity
o W/7 N.=
9rovides@
9rotocols@ T%9, ;#9, 4TT9, etc.
Traffic -odels@ Web Traffic, %:',
Topology 3eneration tools
Iisuali5ation tools
large validation package +people believe it works,
*.6.%. N. .TRUCTUR"
%OO event scheduler protocols +most,
T%) scripts protocols +mostly e7tensions to %OO core,
T%) ob(ects e7pose an interface to %OO ob(ects +shadow ob(ects, system
configuration +defaults, etc.,
*.6.*. Ad4ata)e
fle7ible and state of the art tool
contains wide classes of internet protocols including
multicasting, S'-,'T9,&T- and wireless networks
widely used ST respectful results O easy to compare
*.6.*. Disad4ata)es
PalphaQ quality
minimal docs
incomplete &9I
*.:. .i-0latios
-ost of the commercial simulators are 3;I driven, while some network
simulators require input scripts or commands +network parameters,. The network
parameters describe the state of the network +node placement, e7isting 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. %ertain 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, worstcase, and bestcase conditions.
*etwork simulators can also provide other tools to facilitate visual analysis of trends and
potential trouble spots.
-ost 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 queueing theory, are
well suited to -arkov 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. -arkov chain simulation is typically faster but less accurate and fle7ible
than detailed discrete event simulation. Some simulations are cyclic based simulations
and these are faster as compared to event based simulations.
Simulation of networks can be a difficult task. !or e7ample, if congestion is high,
then estimation of the average occupancy is challenging because of high variance. To
estimate the likelihood of a buffer overflow in a network, the time required for an
accurate answer can be e7tremely large. Speciali5ed techniques such as >control variates>
and >importance sampling> have been developed to speed simulation.
*.>. 8alidatio Tests
*.>.1. Classes o, N. !rotocols
The program UUvalidateBB in the root directory of the ns distribution runs all current
standard tests. 9rotocols 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,.
$ven though we consider these protocols UUvalidatedBB, our test suite coverage is
not complete. Gou are advised to look at what aspects of the protocols are tested in the
test suite before drawing research conclusions from these protocols.
9rotocols and modules covered at least in part by validate include the following@
Applicatio&le4el@
4TT9, web caching and invalidation, Tcp&pp
telnet and ftp sources
%onstant:it'ate +%:', sources ,OnCOff sources
Trasport protocols +;#9, T%9, 'T9, S'-,@
:asic T%9 behavior
Tahoe, 'eno, *ew'eno, and S&%L T%9 under different losses
!&%L T%9
T%9 vegas
*ew'eno T%9
S&%L T%9
!ull T%9 partial validation only.
T%9 initial window behavior
'atebased pacing T%9
'!%0//1 +'eno, T%9 behavior
'T9
S'-
Ro0ti):
&lgorithmic routing
4ierarchical routing
)&* routing and broadcast
-anual routing
%entrali5ed multicast, #- multicast, not detailed#-, not multicast over
)&*
'outing dynamics
#etailed simulation using virtual classifier
-i7edmode sessionlevels simulation
Sessionlevel simulation
Ro0ter Mec/ais-s +scheduling, queue management, admissions control, etc.,@
Several queue scheduling algorithms@ !E +!air Eueuing,, S!E +Stochastic !air
Eueuing,, #'' +#eficit 'ound 'obin,, !I!O +with droptail and '$# queue
management,
%:E +both in v1 and v0 mode,
'$# queue management
$%* behavior +and T%9 interactions,
&dmission control algorithms@ -S, 4:, &%T9, &%TO, parameterbased
Lik&la7er -ec/ais-s:
)&*s, with %S-&C%# -&% protocols
snoop
Ot/er:
$rror -odules
In addition there are a number of protocols in the standard ns distribution which
are not covered by validating. :ecause they cannot be automatically tested, bitrot
sometimes breaks these protocols.
We attempt to keep nonvalidated protocols working and welcome bug reports.
:ecause of difficulties maintaining code that we did not write and for which we may not
know UUground truthBB, we cannot promise that these protocols will remain working. We
strongly encourage people using these protocols in their research to e7amine their output
carefully and implement test suites for them so that we can move them into the
UUvalidatedBB category.
9rotocols and modules in the core but not validated include@
!ack and &sym T%9
'T%9
'T9
)&*s with %S-&C%& -&% protocols +tclCe7Cmactest.tcl,, with -ultihop-ac with
./0.11@
')- +'eceiver )ayered -ulticast,
Token bucket filters
Tracegenerated sources
#elayadaptive receivers
#elay modules
IIS
$mulation mode
*.>.% Co,i)0re
%onfigure will try to autodetect the packages ns needs to build. &utodetection
searches sensible places +like CusrClocal, and the directory above current directory. If you
have packages installed elsewhere you can e7plicitly tell ns where something is with
options like withtclSCyourCpathCtoCtcl. 'un .Cconfigure help for a complete list of
options. %ode
& simple configure will try to autodetect the packages ns needs to build &uto
detection search"s sensible places +likeCusrClocal, and the directory above current
directory. If you have packages installed elsewhere you can e7plicitly tell ns where
something is with options like withtclSCyourCpathCtoCtcl. 'un. Cconfigure help for a
complete list of options
To make this even easier, the make utility has a set of builtin rules so you only
need to tell it what new things it needs to know to build your particular utility. !or
e7ample, if you typed in make love, make would first look for some new rules from you
if you didnBt supply it and then it would look at its builtin rules. One of those builtin
rules tells make that it can run the linker +ld, on a program name ending in .o to produce
the e7ecutable program.
So, make would look for a file named love.o. :ut, it wouldnBt stop there. $ven 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 )inu7
systems is written in % and its file name ends in .c.
If make finds the .c file +love.c in our e7ample, 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
e7ist, it would use another builtin rule to build a new .o from the .c +using the %
compiler,. This same type of situation e7ists for other programming languages. The end
result, in any case, is that when make is done, assuming it can find the right pieces, the
e7ecutable program will be built and up to date.
3etting back to the task at hand, the default file for additional rules in -ake file
in the current directory If you have some source files for a program and there is a -ake
file there, take a look. It is (ust te7t. 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 (ust type make with no target, the first target will be e7ecuted.
What you will likely see at the beginning of most -ake file 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 set internal variables in make %ommon
things to set are the location of the % compiler +yes, there is a default,, version numbers
of the program and such.
This now being up back to configure On different systems, the % compiler might
be in a different place, you might be using <S4 instead of :&S4 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. Gou used to do
this configuring by editing -ake file. &nother 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.
&s more and more software became available and more and more 9OSIF
compliant platforms appeared, this got harder and harder. This is where configure comes
in. It is a shell script +generally written by 3*; &utoconf, that goes up and looks for
software and even tries various things to see what works. It then takes its instructions
from -ake file.in and builds -ake file +and possibly some other files, that work on the
current system.
:ackground work done, let me put the pieces together.
Gou run configure +you usually have to type .Cconfigure as most people donBt
have the current directory in their search path,. This builds a new -ake file.
Type make This builds the program. That is, make would be e7ecuted, it
would look for the first target in -ake file and do what the instructions said.
The e7pected end result would be to build an e7ecutable program.
*ow, as root, type make install. This again invokes make, make finds the
target install in -ake file and files the directions to install the program.
This is a very simplified e7planation but, in most cases, this is what you need to
know. With most programs, there will be a file named I*ST&)) that contains installation
instructions that will fill you in on other considerations. !or e7ample, it is common to
supply some options to the configure command to change the final location of the
e7ecutable 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.
+. R".ULT. AND DI.CU..ION.
It is assumed that different number of nodes +6, 1/, 16, 0/, 06, D/, D6, and 2/,
over a square area of 1/// ( 1///m
0
. $ach simulation has been run for K// seconds of
simulation time. The propagation channel of two"ray ground re'lection model is assumed
with a data rate of 1 -bps. The environment noise level of .D or K/ d:m is modeled as
a 3aussian random variable with the standard deviation of 1 d:. *oise level of K/ d:m
is considered ignorable and interference from other transmitters dominates. On the other
hand, noise level of .D d:m is used to simulate a harsh communication environment.
+.1. .i-0latio "4iro-et:
!irst all the nodes are deployed within the area if 1/// H 1/// m
0
.$ach node have
the same interference range.
Fig 4.1: Multi%op Wireless Network
4ere each and every node broadcast in order to find the neighbor node which are
in the interference range of that particular node.
Fig 4.2: 4roa,#asting 6or 3n,ing Sour#e an, 9estination No,es
Fig 4.3 Sour#e an, 9estination No,es sele#te,
Fig 4.4: !ransmitting Pa#kets 4" sele#ting nearest neig%8or no,e
Fig 4.5: Little Pa#ket loss )ompare, to 9)4&)SMA2)A'
+.%. ?@RA!2.:
+.%.1 !acket Deli4er7 Ratio:
*o.Of
*odes
%horus
+:ytesCmsec,
#%:
+:ytesCmsec,
6 D/ 1/
1/ 6/ 12
0/ .6 0/
D/ .K 6D
2/ K/ A/
Fig 4.: )omparison :rap% 16 P9; 6or )%orus < 9)4
+.%.% Dela7:
*o.Of
*odes
%horus
+msec,
#%:
+msec,
6 /.16 /.60
1/ /.D. /.K1
0/ /.M6 1.DK
D/ /.AD 1.6/
2/ /..6 1.MD
Fig 4.(: )omparison :rap% 6or 9=LA> o6 )%orus < 9)4
+.%.* T/ro0p0t@
Time
+msec,
%horus
+:ytesCmsec,
#%:
+:ytesCmsec,
/ ////// //////
6 01/D2/ 1./D26
1/ 2D//6M D.26M/
16 66K/M2 61//M2
Fig 4.-: )omparison :rap% o6 !/;*.P.! 6or )%orus < 9)4
6. CONCLU.ION
In this pro(ect we provided practical results that demonstrate the feasibility
and advantages of a collisionresolution protocol for wireless broadcast. We introduce
%horus, which allows forwarding nodes which are having same outgoing packets to
transmit at the same time, and then allows physicallayer iterative decoding scheme to
resolve collisions at the receiver. :y decoding multiple versions of a packet at once,
%horus achieves transmit diversity and improves 9#' without any retransmission. -ost
importantly, with its cognitive sensing scheme in -&% layer, %horus significantly
simplifies the %S-& scheduling and improves its spatial reuse.
1I1LIO@RA!29
V1W '. 3andhi, S. 9arthasarathy, and &. -ishra, P-inimi5ing :roadcast )atency and
'edundancy in &d 4oc *etworks,Q 9roc. &%- -obi4oc, 0//D.
V0W I$$$ ./0.11 Standard@ Wireless )&* -edium &ccess %ontrol +-&%, and 9hysical
)ayer +94G, Specifications, I$$$, 0//A.
VDW S. 4uang, 9.X. Wan, X. #eng, and G. 4an, P:roadcast Scheduling in Interference
$nvironment,Q I$$$ Trans. -obile %omputing, vol. A, no. 11, pp. 1DD.1D2., *ov. 0//..
V2W S. 3ollakota and #. Latabi, P<ig<ag #ecoding@ %ombating 4idden Terminals in
Wireless *etworks,Q 9roc. &%- SI3%O--, 0//..
V6W :. Sklar, #igital %ommunications@ !undamentals and &pplications. 9rentice 4all,
0//1.
VMW 9. %hat5imisios, &. %. :oucouvalas, I. Iitsas, &. Iafiadis, &. $conomidis and 9.
4uang1Q& simple and effective backoff scheme for the I$$$ ./0.11 -&% protocol P
VAW #. 4alperin, T. &nderson, and #. Wetherall, PTaking the Sting Out of %arrier Sense@
Interference %ancellation for Wireless )&*s,Q 9roc. &%- -obi%om, 0//..
V.W %. !ragouli, X. Widmer, and ).:. XeanGves, P$fficient :roadcasting ;sing *etwork
%oding,Q I$$$C&%- Trans. *etworking, vol. 1M, no. 0, pp. 26/2MD, &pr. 0//..
VKW X. Gang and '.W. :rodersen, PTime #omain Interference %ancellation for %ognitive
'adios and !uture Wireless Systems,Q 9h# thesis, $lectrical $ngineering and %omputer
Science #ept., ;niv. of %alifornia, :erkeley, -ay 0/1/.
V1/W X. :icket, #. &guayo, S. :iswas, and '. -orris, P&rchitecture and $valuation of an
;nplanned ./0.11b -esh *etwork,Q 9roc. &%- -obi%om, 0//6.

Final Rough

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Rough

Uploaded by

Copyright:

Available Formats

Optimizing the Redundancy Using CHORUS in Wireless Networks

You might also like