首页资源分类应用技术射频与通信技术 > opnet仿真zigbee实例.pdf

opnet仿真zigbee实例.pdf

已有 445122个资源

下载专区

上传者其他资源

    文档信息举报收藏

    标    签:opnetzigbee

    分    享:

    文档简介

    opnet仿真zigbee实例是一篇相应论文

    文档预览

    
 
 
 ENSC
427:
COMMUNICATION
NETWORKS

 
 
 ZIGBEE
MESH
NETWORK
SIMULATION
USING
OPNET
AND
STUDY
 OF
ROUTING
SELECTION
 Spring
2009
 
 
 FINAL
PROJECT
 
 Sam
Leung
 Wil
Gomez
 Jung
Jun
Kim
 http://www.sfu.ca/~mingl/
 mingl@sfu.ca
 wgomez@sfu.ca
 jkimd@sfu.ca
 
 
 
 ABSTRACT
 
 ZigBee,
formally
known
as
IEEE
802.15.4‐2006
standard,
is
becoming
a
popular
way
to
 create
wireless
personal
area
network
(WPAN)
due
to
its
low
power
consumption
and
 scalability.
ZigBee
ad‐hoc
mesh
networks
are
designed
to
support
a
large
number
of
 nodes
(>64,000)
with
dynamic
routing
in
case
of
a
node
failure.
This
project
will
simulate
 and
explore
the
performance
of
ZigBee
WPAN’s
under
various
conditions
using
OPNET.
 TABLE
OF
CONTENTS
 
 ABSTRACT ............................................................................................................................. i
 TABLE
OF
CONTENTS ........................................................................................................... ii
 LIST
OF
FIGURES .................................................................................................................iii
 LIST
OF
TABLES ...................................................................................................................iii
 ACRONYMS
AND
ABBREVIATIONS ..................................................................................... iv
 1
 Introduction ................................................................................................................ 1
 1.1
 Project
Scope...................................................................................................... 1
 2
 ZigBee
Overview.......................................................................................................... 2
 2.1
 ZigBee
Specifications ......................................................................................... 2
 2.2
 ZigBee
Layers...................................................................................................... 2
 2.2.1
 Application
Layer................................................................................... 3
 2.2.2
 Network
Layer ....................................................................................... 3
 2.2.4
 Medium
Access
Control
Sub‐Layer ....................................................... 3
 2.2.5
 Physical
Layer ........................................................................................ 4
 2.3
 Network
Topologies........................................................................................... 4
 2.3.1
 Star
Topology......................................................................................... 5
 2.3.2
 Tree
Topology........................................................................................ 5
 2.3.3
 Mesh
Topology ...................................................................................... 6
 3
 ZigBee
Simulation
Using
OPNET.................................................................................. 6
 3.1
 Traffic
with
Single
Router .................................................................................. 6
 3.2
 Verification
of
ZigBee’s
Self‐Healing
Mechanism
upon
Router
Failure......... 10
 3.3
 Traffic
Stability
in
Presence
of
Moving
End‐Devices
–
CBR............................ 15
 3.4
 Assessing
Network
Performance
with
Stationary
End‐Devices
–
VBR .......... 17
 3.5
 Testing
the
ZigBee
OPNET
Model
Limits
–
Adding
Additional
End
Devices .. 20
 4
 DISCUSSIONS
AND
CONCLUSION .............................................................................. 23
 4.1
 OPNET
ZigBee
Model
Limitations.................................................................... 23
 4.2
 What
We
Learned ............................................................................................ 23
 5
 REFERENCES .............................................................................................................. 24
 
 ii LIST
OF
FIGURES
 Figure
1
–
Overview
of
ZigBee
Layers
[7]............................................................ 2
 Figure
2
‐
Legend
for
ZigBee
Devices .................................................................. 5
 Figure 3 – Star Topology [6]............................................................................... 5
 Figure 4 – Tree Topology [6].............................................................................. 5
 Figure 5 – Mesh Topology [6] ............................................................................ 6
 Figure
6
‐
Single
Router
Available
Scenario ........................................................ 7
 Figure
7
–
Traffic
from
end
devices
to
destination
coordinator ......................... 8
 Figure
8
–
Traffic
sent
and
received
by
the
two
routers..................................... 8
 Figure
9
‐
End
to
End
delay
from
end
devices
to
coordinator
(As
Is) ................. 9
 Figure
10
–
End
to
End
delay
from
end
devices
to
coordinator
(Average)......... 9
 Figure
11
–
Traffic
path
prior
router
failure...................................................... 10
 Figure
12
‐
Traffic
path
after
router
failure....................................................... 11
 Figure
13
–
Traffic
Sent
by
end
devices
and
received
by
routers ..................... 12
 Figure
14
–
Traffic
from
routers
to
coordinator
(overlaid
view)....................... 13
 Figure
15
–
Traffic
from
routers
to
coordinator
(stacked
view) ....................... 13
 Figure
16
–
End
to
End
delay
from
end
devices
to
coordinator
(As
Is)............. 14
 Figure
17
–
End
to
End
delay
from
end
devices
to
coordinator
(Average)....... 14
 Figure
18
‐
Traffic
and
Trajectory
Path.............................................................. 15
 Figure
19
‐
Traffic
Sent
From
End
Devices
&
Routers
to
Coordinator .............. 16
 Figure
20
‐
Traffic
Sent
From
End
Devices
&
Routers
to
Coordinator .............. 16
 Figure
21
–
End‐to‐end
delay
showing
packet
drop
around
5minute
simulated
 time
(As
Is)................................................................................................. 16
 Figure
22
–
Same
layout
as
scenario
3.1
using
variable
packet
rate ................ 17
 Figure
23
–
Traffic
sent
by
end
devices
to
destination
coordinator
with
route
 traffic ......................................................................................................... 18
 Figure
24
–
Traffic
Sent
From
End
Devices
to
Coordinator............................... 19
 Figure
25
–
End
to
End
delay
from
End
Devices
to
Coordinator
(As
Is) ............ 19
 Figure
26
–
End
to
End
delay
from
End
Devices
to
Coordinator
(Time
Average) ................................................................................................................... 20
 Figure
27
–
Case
of
two
routers
and
three
end
devices ................................... 20
 Figure
28
–
Traffic
sent
by
the
end
devices
and
received
by
the
coordinator . 21
 Figure
29
–
Case
of
single
router
and
three
end
devices.................................. 21
 Figure
30
–
Traffic
from
three
end
devices
dropped
en
route ......................... 22
 LIST
OF
TABLES
 Table
1
–
General
ZigBee
Specifications ............................................................. 2
 Table
2:
Frequency
Bands
used
in
802.15.4[1] ................................................... 4
 iii ACRONYMS
AND
ABBREVIATIONS
 
 ACL
 AES
 CBR
 CSMA/CA
 ETE
 HVAC
 IEEE
 ISM
 LR‐WPAN
 MAC
 PAN
 PER
 VBR
 ZDO
 
 
 
 
 
 
 
 Access
Control
List
 Advanced
Encryption
Standard
 Constant
Bit
Rate
 Carrier
Sense
Multiple
Access/Collision
Avoidance
 End‐to‐End
 Heating,
Ventilation
and
Air
Conditioning
 Institute
of
Electrical
and
Electronics
Engineers
 Industrial,
Scientific
and
Medical
 Low
Rate
–
Wireless
Personal
Area
Network
 Medium
Access
Control
 Personal
Area
Network
 Packet
Error
Rate
 Variable
Bit
Rate
 ZigBee
Device
Object
 
 
 
 
 
 
 
 iv 1 Introduction
 
 Use
of
Wireless
Personal
Area
Networks
(WPAN)
has
steadily
grown
in
recent
years.
Its
 popularity
comes
from
the
convenience
of
using
wireless
signals
in
open
areas
such
as
 office
space
or
home
rather
than
having
to
lay
out
wires.
Removing
the
constraints
of
 length
and
troublesome
physical
installation
of
wires,
wireless
solutions
provide
much
 more
diversity
and
potentially
reduced
cost.
 
ZigBee
(IEEE
802.15.4‐2006
standard)
is
a
category
in
the
IEEE
802
family,
along
with
 some
of
the
well‐known
protocols
such
as
Wi‐Fi,
Bluetooth
which
uses
the
2.4
GHz
 industrial,
and
scientific
and
medical
(ISM)
radio
band.
ZigBee
also
utilizes
868
MHz
and
 915
MHz
in
different
parts
of
the
world
according
to
local
standards
[1].
Unlike
Wi‐Fi
 and
Bluetooth,
ZigBee
was
developed
for
low‐rate
WPAN
(LR‐WPAN)
which
feature
long
 battery
life
by
having
low
date
rates.
 The
ZigBee
protocol
was
designed
to
provide
static,
dynamic,
or
mesh
network
 topologies
supporting
up
to
65,000
nodes
across
large
areas
for
industrial
use.
In
order
 to
handle
faults
caused
by
various
environmental
effects,
the
ZigBee
protocol
provides
a
 self‐healing
ability
for
the
network
to
detect
and
recover
from
network
or
 communication
link
faults
without
human
intervention
[1].
This
is
done
through
certain
 features
of
the
ZigBee
protocol
such
as
clear
channel
assessment,
retries
and
 acknowledgments,
and
collision
avoidance.
 
 1.1 Project
Scope
 
 The
primary
goal
of
this
project
is
to
better
understand
the
use
of
OPNET
simulation
tool
 as
well
as
to
study
the
protocol
of
interest,
ZigBee.
In
order
to
achieve
these
goals
this
 project
will
provide
a
brief
overview
of
what
ZigBee
protocol
contains,
and
simulate
 several
simple
ZigBee
WPAN
networks
while
altering
certain
parameters
using
OPNET.
 
 
 
 
 
 
 
 
 1 2 ZigBee
Overview
 
 2.1 ZigBee
Specifications
 
 
 
 ZigBee
802.15.4
 Transmission
Range
(meters)
 1
–
100
 Battery
Life
(days)
 100
–
1,000
 Network
Size
(#
of
nodes)
 >
64,000
 Throughput
(kb/s)
 20
‐
250
 Table
1
–
General
ZigBee
Specifications
 
 
 2.2 ZigBee
Layers
 
 ZigBee
consists
of
four
layers.
The
top
two
(Application
and
Network)
layers
 specifications
are
provided
by
the
ZigBee
Alliance
to
provide
manufacturing
standards.
 The
bottom
two
(Medium
Access
Control
and
Physical)
layers
specifications
are
 provided
by
the
IEEE
802.15.4‐2006
standard
to
ensure
coexistence
without
 interference
with
other
wireless
protocols
such
as
Wi‐Fi.
 
 
 Figure
1
–
Overview
of
ZigBee
Layers
[7]
 2 2.2.1 Application
Layer
 
 Applications
running
on
the
ZigBee
network
are
contained
here.
For
example,
 applications
to
monitor
temperature,
humidity,
or
any
other
desirable
atmospheric
 parameters
can
be
placed
on
this
layer
for
agricultural
use.
This
is
the
layer
that
makes
 the
device
useful
to
the
user.
A
single
node
can
run
more
than
one
application.
 Applications
are
referenced
with
a
number
ranging
from
1‐240.
Meaning
there
is
a
 maximum
of
240
applications
on
a
ZigBee
device.
Application
number
0
is
reserved
for
a
 unique
application
that
exists
on
all
ZigBee
devices.
Another
application
number,
255,
is
 also
reserved.
This
number
is
used
to
broadcast
a
message
to
all
applications
on
a
node.

 
 2.2.1.1 ZigBee
Device
Object
(ZDO)
 
 A
special
application
is
on
every
ZigBee
device,
and
this
is
the
ZigBee
Device
Object,
or
 ZDO.
This
application
provides
key
functions
such
as
defining
the
type
of
ZigBee
device
 (end
device,
router,
and
coordinator)
a
particular
node
is,
initializing
the
network,
and
to
 also
participate
in
forming
a
network.
 
 2.2.2 Network
Layer
 
 A
feature
of
ZigBee
such
as
the
self‐healing
mechanism
is
acquired
through
this
layer.
As
 Figure
1
shows,
this
layer
provides
network
management,
routing
management,
 network
message
broker,
and
network
security
management.
This
layer
is
defined
by
 the
ZigBee
Alliance,
which
is
an
association
of
companies
united
to
work
for
a
better
 ZigBee
standard.
 
 2.2.3 Security
Plane
 
 The
security
plane
spans
across
both
the
network
layer
and
the
application
layer.
It
is
 here,
that
security
measures
such
as
AES‐based
encryption
is
implemented.
Another
 security
feature
is
message
timeouts,
which
adds
a
frame
counter
on
to
each
frame.
 Using
this
frame
counter,
the
device
can
determine
the
age
of
the
message
it
receives,
 and
detect
the
possibility
that
an
old
message
was
recorded
and
is
played
back
to
the
 device
(replay
attack).
 
 2.2.4 Medium
Access
Control
Sub‐Layer
 
 This
layer
extracted
from
the
IEEE
802.15.4
standard
provides
services
to
the
network
 layer
above,
which
is
part
of
the
ZigBee
stack
level.
The
MAC
layer
is
responsible
for
the
 addressing
of
data
to
determine
either
where
the
frame
is
going,
or
coming
from.
It
is
 also
this
layer
that
provides
multiple
access
control
such
as
CSMA/CA
allowing
for
 reliable
transfer
of
data.
Beaconing
is
another
feature
implemented
through
this
layer.
 Finally,
the
MAC
sub‐layer
can
be
exploited
by
higher
layers
to
achieve
secure
 communication
(by
measures
such
as
an
ACL).
 3 
 2.2.5 Physical
Layer
 
 The
physical
layer
is
provided
by
the
IEEE
802.15.4
standard.
This
standard
manages
the
 physical
transmission
of
radio
waves
in
different
unlicensed
frequency
bands
around
the
 world
to
provide
communication
between
devices
within
a
WPAN.
The
bands
are
 specified
in
the
table
below,
pairing
it
with
the
area
that
the
band
is
used
in.
 
 Frequency
Range
(MHz)
 Numbers
of
Channels
Available
 Region
used
 868‐868.6
 1
 Europe
 902‐928
 10
 North
America
 2400‐2483.5
 16
 Worldwide
 Table
2:
Frequency
Bands
used
in
802.15.4[1]
 
 This
layer
allows
for
channel
selection
to
avoid
radio
interference,
as
well
as
data
 exchange
with
the
layer
above
(MAC
sub‐layer)
to
provide
it
with
service.
 
 
 2.3 Network
Topologies
 
 ZigBee
networks
can
contain
a
mixture
of
three
potential
components.
These
 components
are
a
ZigBee
coordinator,
a
ZigBee
router,
and
a
ZigBee
end
device.
 Different
types
of
nodes
will
have
different
roles
within
the
network
layer,
but
all
 various
types
can
have
the
same
applications.
 
 ZigBee
coordinator
–
For
every
ZigBee
network,
there
can
be
only
one
coordinator.
This
 node
is
responsible
for
initializing
the
network,
selecting
the
appropriate
channel,
and
 permitting
other
devices
to
connect
to
its
network.
It
can
also
be
responsible
for
routing
 traffic
in
a
ZigBee
network.
In
a
star
topology,
the
coordinator
is
at
the
center
of
the
star,
 and
all
traffic
from
any
end
device
must
travel
to
this
node.
It
is
still
possible
for
end
 devices
to
talk
to
another
end
device,
but
the
message
must
be
routed
through
the
 coordinator.
In
a
tree
topology,
the
coordinator
is
at
the
top
of
the
tree,
and
in
a
mesh
 network,
it
is
the
root
node
of
the
mesh.
A
ZigBee
coordinator
can
also
take
part
in
 providing
security
services.
 
 ZigBee
Router
–
A
router
is
able
to
pass
on
messages
in
a
network,
and
is
also
able
to
 have
child
nodes
connect
to
it,
whether
it
be
another
router,
or
an
end
device.
Router
 functions
are
only
used
in
a
tree
or
mesh
topology,
because
in
a
star
topology,
all
traffic
 is
routed
through
the
center
node,
which
is
the
coordinator.
Routers
can
take
place
of
 end
devices,
but
the
routing
functions
would
be
useless
in
such
cases.
If
the
network
 supports
beaconing,
then
a
router
can
sleep
when
inactive,
periodically
waking
up
to
 notify
the
network
of
its
presence.

 
 4 ZigBee
End
Device
–
The
power
saving
features
of
a
ZigBee
network
can
be
mainly
 credited
to
the
end
devices.
Because
these
nodes
are
not
used
for
routing
traffic,
they
 can
be
sleeping
for
the
majority
of
the
time,
expanding
battery
life
of
such
devices.
 These
nodes
carry
just
enough
function
to
talk
to
parent
nodes,
which
can
be
either
a
 router
or
a
coordinator.
An
end
device
does
not
have
the
ability
to
have
other
nodes
 connect
to
its
network
through
the
end
device,
as
it
must
be
connected
to
the
network
 through
either
a
router,
or
directly
to
the
coordinator.
 
 In
the
following
sections,
we
go
into
detail
about
the
three
different
types
of
topology
 possible
for
a
ZigBee
network.
The
legend
to
all
topology
figures
are
shown
below,
and
 each
type
of
device
is
given
a
color
code
for
easy
viewing.
 
 
 
 2.3.1 Star
Topology
 
 Figure
2
‐
Legend
for
ZigBee
Devices
 
 In
this
simple
topology,
a
coordinator
is
surrounded
by
a
group
of
either
end
devices
or
 routers.
Even
though
routers
are
connected
to
the
coordinator,
their
message
relaying
 functions
are
not
used.
This
type
of
topology
is
attractive
 because
of
its
simplicity,
but
at
the
same
time
presents
some
 key
disadvantages.
In
the
event
that
the
coordinator
stops
 functioning,
the
entire
network
is
functionless
because
all
 traffic
must
travel
through
the
center
of
the
star.
For
the
 same
reason,
the
coordinator
could
easily
be
a
bottleneck
to
 traffic
within
the
network,
especially
since
a
ZigBee
network
 can
have
more
than
60000
nodes.
 
 Figure 3 – Star Topology [6] 2.3.2 Tree
Topology
 
 In
a
tree
network,
a
coordinator
initializes
the
network,
and
is
the
top
(root)
of
the
tree.
 The
coordinator
can
now
have
either
routers
or
end
 devices
connected
to
it.
For
every
router
connected,
 more
child
nodes
can
connect
to
the
router.
Child
 nodes
cannot
connect
to
an
end
device
because
it
does
 not
have
the
ability
to
relay
messages.
This
topology
 allows
for
different
levels
of
nodes,
with
the
 coordinator
being
at
the
highest
level.
For
messages
to
 be
passed
to
other
nodes
in
the
same
network,
the
 source
node
must
pass
the
message
to
its
parent,
which
 Figure 4 – Tree Topology [6] 5 is
the
node
higher
up
by
one
level
of
the
source
node,
and
the
message
is
continually
 relayed
higher
up
in
the
tree
until
it
can
be
passed
back
down
to
the
destination
node.
 Because
the
number
of
potential
paths
a
message
can
take
is
only
one,
this
type
of
 topology
is
not
the
most
reliable
topology.
If
a
router
fails,
then
all
of
that
router’s
 children
are
cut
off
from
communicating
with
the
rest
of
the
network.
 
 2.3.3 Mesh
Topology
 
 
A
mesh
topology
is
the
most
flexible
topology
of
the
 three.
Flexibility
is
present
because
a
message
can
take
 multiple
paths
from
source
to
destination.
If
a
particular
 router
fails,
then
ZigBee’s
self
healing
mechanism
(aka
 route
discovery)
will
allow
the
network
to
search
for
an
 alternate
path
for
the
message
to
take.
In
our
project,
 one
of
the
scenarios
is
to
investigate
this
feature
by
 removing
a
router
from
the
network
during
operation,
 and
seeing
the
end
devices
find
an
alternate
path
to
 communicate
with
the
coordinator.
 
 Figure 5 – Mesh Topology [6] 3 ZigBee
Simulation
Using
OPNET
 
 The
ZigBee
library
for
OPNET
is
new
to
OPNET
v14.0.
Unfortunately,
the
ZigBee
model
is
 incomplete
and
lacks
some
functions
of
ZigBee
(will
be
discussed
in
the
Discussions
and
 Conclusion
section).
 
 ZigBee
performs
route
discovery
to
determine
the
optimal
path
for
messages
to
take
to
 its
destination.
This
section
will
discuss
the
results
of
various
cases
simulated
on
OPNET;
 Steady
case
with
single
router,
router
failure
leading
to
self‐healing,
stability
in
the
 presence
of
moving
end
devices,
case
of
variable
bit
rate
transmitted,
and
some
 limitations
observed
possibly
due
to
an
incomplete
ZigBee
library
model.
 
 3.1 Traffic
with
Single
Router
 
 This
scenario
is
a
general
and
simple
case
to
observe
the
behaviour
of
a
ZigBee
network
 in
OPNET.
Here,
we
have
a
coordinator
on
the
far
right,
with
a
single
router
in
the
 middle
(router
in
the
figure
that’s
circled,
has
a
small
red
cross
in
the
middle
signifying
 that
the
router
is
disabled,
leaving
ROUTER_1
the
only
functional
router
in
the
scenario),
 and
a
pair
of
end
devices.
The
end
devices
will
be
sending
data
with
a
constant
bit
rate
 to
the
coordinator
by
first
sending
to
the
router,
and
then
allowing
the
router
to
relay
 the
message
to
the
destination.
 
 6 
 Figure
6
‐
Single
Router
Available
Scenario
 
 Figure7
below
shows
the
traffic
being
sent
by
the
two
end
devices
and
received
by
the
 destination
coordinator.
The
bottom
red
line
(overlapping
with
green)
is
the
traffic
being
 sent
by
the
end
devices,
where
the
blue
line
shows
the
traffic
being
received
by
the
 destination
coordinator.
It
can
be
seen
that
steady
stream
of
traffic
is
sent
without
 disruption.
Small
spikes
in
at
the
beginning
of
the
simulation
are
indications
of
 management
and
control
traffic
sent
and
received
to
determine
the
presence
of
devices
 as
well
as
the
optimal
route.
 
 7 
 Figure
7
–
Traffic
from
end
devices
to
destination
coordinator
 
 Figure
8
(below)
shows
the
traffic
being
received
and
sent
(routed)
by
the
two
routers.
 The
disabled
router
does
not
receive
or
send
any
traffic
as
expected.
The
amount
of
 traffic
being
routed
is
equivalent
to
the
traffic
received
by
the
coordinator
as
seen
in
the
 previous
figure.

 
 
 Figure
8
–
Traffic
sent
and
received
by
the
two
routers
 8 
 Next
two
figures
show
the
end‐to‐end
(ETE)
delay
of
traffic
from
the
end
devices.
The
 average
delay
shows
consistency
in
the
amount
of
ETE
delay.
It
shows
that
 END_DEVICE_0
(blue
line)
initially
connects
with
the
router,
showing
much
less
delay
 compared
to
END_DEVICE_1
(red
line)
as
it
is
using
up
the
channel
resource.
It
is
worth
 noting
the
average
ETE
delay
is
0.016s
to
0.017s.
 
 
 Figure
9
‐
End
to
End
delay
from
end
devices
to
coordinator
(As
Is)
 
 
 Figure
10
–
End
to
End
delay
from
end
devices
to
coordinator
(Average)
 
 The
results
from
this
general
scenario
serve
as
a
good
starting
point
for
comparison
for
 the
following
scenarios
where
slightly
more
interesting
cases
will
be
observed.
Also,
it
 will
help
understand
the
variation
in
the
results
in
the
preceding
scenarios.
 
 
 
 
 
 9 3.2 Verification
of
ZigBee’s
Self‐Healing
Mechanism
upon
Router
Failure
 
 One
method
of
simulating
a
failure
in
the
router
is
to
modify
the
code
to
add
in
a
failure
 condition.
However,
this
was
deemed
to
be
beyond
scope
of
this
project1
and
an
 alternative
method
was
used.
 
 The
alternate
method
was
to
provide
a
trajectory
to
the
router
to
move
it
out
of
range
 to
trigger
self‐healing.
This
can
be
analogous
to
a
case
of
router
being
blown
away
in
the
 agricultural
application
due
to
extreme
winds.
 
 Two
key
features
required
for
this
case
scenarios
are
the
ACK
enable
and
understanding
 the
range
capability
of
ZigBee.
Placing
the
end
devices
too
close
to
the
destination
 coordinator
will
result
in
traffic
being
sent
directly,
rather
than
through
the
router,
 preventing
observations
for
the
self‐healing
feature.
Also
the
ACK
enable
was
required
 for
the
end
devices
to
recognize
that
the
failure
in
the
router
has
occurred,
no
longer
 receiving
and
routing
traffic,
in
order
to
trigger
route
discovery.

 
 Figure
11
below
illustrates
the
traffic
path
from
end
devices
to
the
coordinator
prior
to
 the
failure,
where
Figure
12
illustrates
the
traffic
path
after
the
failure
in
the
bottom
 router,
triggering
the
self‐healing
to
find
an
alternate
path
to
the
destination.
 
 
 Figure
11
–
Traffic
path
prior
router
failure
 1 OPNET did not disclose all the information for given library. Only the MAC layer Function Block and Header Block were provided (as well as packet formats and generic dra_power model). Rest of the code/implementation was hidden from view possibly due to work in progress. 10 
 
 Figure
12
‐
Traffic
path
after
router
failure
 
 Figures
13
to
17
below
shows
the
statistics
collected
to
observe
the
behaviour
of
self‐ healing.
The
failure
in
the
router
occurs
at
the
five
minute
mark
of
simulated
time.
 Figure
13
shows
the
traffic
sent
by
the
two
end
devices
(blue
line
overlapping
with
red)
 and
traffic
received
by
the
two
routers.
The
green
line
shows
a
sharp
drop
at
five
 minutes
due
to
it
being
moved
out
of
range
of
the
end
devices
and
stops
receiving
 traffic.
The
light
blue
line
along
the
top
is
the
stationary
router.
It
shows
that
router
is
 receiving
traffic
from
all
neighbouring
devices
initially.
This
is
due
to
the
lack
of
a
 beaconing
feature
of
ZigBee
in
this
model,
where
non‐active
devices
are
able
to
go
into
 sleep
mode,
occasionally
waking
up
to
notify
its
presence
to
the
network.
Despite
the
 heavy
traffic
received
by
the
stationary
router,
it
does
not
transmit
(route
the
traffic)
to
 the
destination
coordinator
as
it
will
be
described
in
the
figure
14
and
15.
 
 The
sharp
spike
near
the
five
minute
time
is
similar
to
the
spike
observed
near
the
start
 of
simulation.
This
is
in
part
due
to
the
management
and
control
traffic
transmitted
by
 the
devices
to
perform
route
discovery.
The
spike
at
the
five
minute
is
caused
by
the
 self‐healing
feature
of
ZigBee,
it
simply
recognizes
absence
of
the
original
path
and
 performs
route
discovery
once
again
to
find
the
next
optimal
path
to
its
destination.
 
 It
can
be
seen
that
stationary
router
picks
up
the
end
device
traffic
and
continues
to
 route
the
traffic
to
the
destination.
 
 11 
 Figure
13
–
Traffic
Sent
by
end
devices
and
received
by
routers
 
 
 Figures
14
and
15
show
the
traffic
between
the
two
routers
and
the
coordinator
 (destination).
The
blue
line
shows
the
traffic
received
by
the
coordinator
while
the
red
 and
green
shows
the
traffic
sent
by
the
routers
(to
the
coordinator).
In
the
first
five
 minutes,
it
can
be
seen
that
stationary
router
does
not
send
(route)
any
traffic
despite
 receiving
large
amounts
(seen
in
figure
8
light
blue
line).
 
 The
coordinator
continuously
receives
the
traffic
with
one
instance
of
a
gap
at
the
five
 minute
simulated
time.
This
is
when
the
self‐healing
route
discovery
occurs.
The
mobile
 router
attempts
to
find
its
place
in
the
network
(red
spike).
Once
the
initial
router
fails,
 the
stationary
router
picks
up
the
traffic
and
routes
it
to
the
destination.
 
 12 
 Figure
14
–
Traffic
from
routers
to
coordinator
(overlaid
view)
 
 
 Figure
15
–
Traffic
from
routers
to
coordinator
(stacked
view)
 
 Figures
16
and
17
shows
the
end‐to‐end
(ETE)
delay
seen
from
the
end
devices
to
the
 coordinator.
This
is
a
measure
of
time
from
generating
the
application
packet
to
the
 time
received
by
the
destination.
Figure
16
shows
the
“as
is”
ETE
where
the
small
gap
at
 the
five
minute
simulated
time
shows
packets
dropped
while
the
router
failure
occurred.
 However,
the
average
ETE
delay
is
constant
throughout
as
seen
in
Figure
17
 demonstrating
the
consistency
maintained
in
network
traffic
despite
a
router
failure.
 13 
 
 Figure
16
–
End
to
End
delay
from
end
devices
to
coordinator
(As
Is)
 
 
 Figure
17
–
End
to
End
delay
from
end
devices
to
coordinator
(Average)
 
 The
results
indicate
that
the
overall
performance
of
ZigBee’s
self‐healing
does
quite
well.
 The
traffic
generated
from
end
devices
were
successfully
received
by
the
destination
 coordinator
aside
from
small
gap
of
simulated
time
window
showing
packets
dropped.
 Also,
the
average
ETE
delay
is
very
similar
to
that
of
simple
single
router
scenario
from
 before.
 
 14 3.3 Traffic
Stability
in
Presence
of
Moving
End‐Devices
–
CBR
 Because
ZigBee
networks
can
be
used
as
a
sensor
network
in
such
environments
as
 hospitals,
and
agricultural
(livestock)
environments,
it
is
important
for
ZigBee
to
perform
 well
even
when
end
devices
are
not
stationary.
In
this
scenario,
we
set
an
end
device
on
 a
path
that
travels
in
different
directions
in
range
of
~300
to
~3000
meters.
In
theory,
 the
fact
that
the
end
device
is
moving
should
not
make
a
difference
in
the
amount
of
 traffic
that
the
router
successfully
receives
even
if
it
leaves
the
PAN
momentarily
and
 then
comes
back
in
range.
Below
is
a
figure
showing
how
the
simulation
was
configured
 including
the
trajectory
path
for
the
mobile
end
device.


 
 
 Figure
18
‐
Traffic
and
Trajectory
Path
 
 The
mobile
end
device
moves
around
the
network
in
a
counter‐clock
wise
motion
within
 the
network.
After
4
minutes
and
22
seconds
the
mobile
node
moves
out
of
range
 temporarily,
and
then
it
re‐enters
the
network.

 
 15 The
two
figures
below
show
the
traffic
received
by
the
coordinator,
and
the
traffic
sent
 by
the
router
and
end
devices.
 
 
 Figure
19
‐
Traffic
Sent
From
End
Devices
&
Routers
to
 
 Figure
20
‐
Traffic
Sent
From
End
Devices
&
Routers
to
Coordinator
 Coordinator
 
 Looking
at
the
graphs
above
we
take
note
on
some
interesting
things.
At
about
1m30s
 the
coordinator
traffic
increases
by
644
bits/second
because
the
mobile
node
comes
in
 range
and
sends
traffic
to
both
the
router
and
coordinator.
Next
at
4:22
the
router
and
 coordinator
data
rates
decrease
by
644
bits/second
because
End_Device_2
is
out
of
 range.
Then
at
about
5:04
End_Device_2
comes
back
in
range
increasing
the
router
and
 coordinator
traffic
by
644
bits/second.
Below
in
figure
21
the
end
to
end
traffic
is
shown
 for
each
of
the
end
devices.

 
 
 Figure
21
–
End‐to‐end
delay
showing
packet
drop
around
5minute
simulated
time
(As
Is)
 
 16 Notice
that
between
4:22
–
5:04,
the
end
to
end
delay
is
undefined
for
END_DEVICE_2
 because
the
packets
are
being
dropped
when
it’s
out
of
range.
From
these
results
we
 see
that
Zigbee’s
performance
is
not
affected
by
having
mobile
devises.
The
network
is
 able
to
release
a
device
and
let
it
re‐enter
the
network
without
any
slips.

 
 3.4 Assessing
Network
Performance
with
Stationary
End‐Devices
–
VBR
 
 In
the
event
that
the
traffic
being
sent
is
not
constant,
it
is
important
for
the
network
to
 still
be
able
to
perceive
all
information
being
sent.
In
this
scenario,
we
configure
the
end
 devices
to
send
data
at
a
variable
bit
rate
(VBR)
instead
of
a
constant
bit
rate
used
in
the
 other
scenarios.
The
parameter
to
be
compared
is
the
end‐to‐end
(ETE)
delay,
and
we
 will
compare
this
scenario’s
delay
with
our
first
scenario’s
delay,
which
is
a
simple
2
end
 device,
1
router,
1
coordinator
network
with
constant
bit
rate
transfer.
The
topology
of
 the
network
can
be
seen
in
figure
below.
 
 
 Figure
22
–
Same
layout
as
scenario
3.1
using
variable
packet
rate
 
 In
the
figure
below,
we
see
the
average
traffic
being
sent
over
the
network.
As
expected,
 the
traffic
being
sent
by
the
pair
of
end
devices
is
successfully
received
by
the
router,
 which
is
then
successfully
forwarded
to
the
coordinator.
The
discrepancy
in
the
 beginning
of
the
graph
between
the
router
(light
blue)
and
the
coordinator
(blue)
can
be
 accounted
for
by
the
second
router
(yellow),
which
was
left
on,
but
had
no
end
devices
 attached
to
it.
The
initial
spike
of
data
is
due
to
the
network
setup
(route
discovery).
The
 second
router
(yellow)
flat
lines
because
no
data
is
being
relayed
by
the
router,
and
the
 router
itself
is
not
sending
any
data
either.
 17 
 Figure
23
–
Traffic
sent
by
end
devices
to
destination
coordinator
with
route
traffic
 
 The
graph
below
shows
that
the
data
being
sent
from
the
end
devices
are
indeed
not
a
 constant
rate,
but
a
variable
bit
rate.
The
data
received
by
the
coordinator
(blue)
the
 addition
of
the
data
being
sent
by
the
two
end
devices
(red
and
green).
For
this
 simulation,
we
decided
to
send
data
with
variable
packet
sizes
varying
from
500
‐1524
 bytes,
at
a
constant
packet
rate
of
1
packet
for
every
2
seconds.
 
 18 
 Figure
24
–
Traffic
Sent
From
End
Devices
to
Coordinator
 
 Even
though
the
above
screenshots
prove
the
success
of
packets
arriving
at
their
 destination,
it
is
important
that
the
data
arrives
promptly,
or
else
the
data
could
be
 useless
by
the
time
it
arrives
at
the
destination.
For
this
reason,
we
must
check
the
end‐ to‐end
delay
of
the
packets
being
sent.
Below,
are
two
graphs,
that
show
an
“as
is”
and
 average
end‐to‐end
delay.
Because
of
the
varying
size
of
packets
being
sent,
the
delay
is
 not
a
constant,
and
in
figure
x
we
see
the
varying
delay,
which
can
be
accounted
for
by
 the
packet
sizes.
On
figure
25,
we
can
see
the
average
delay
for
the
packets
being
sent.
 The
initial
spike
can
be
attributed
to
the
setup
of
the
network.
After
approximately
3
 minutes,
we
see
the
ETE
delay
calm
to
a
steady
state
of
approximately
16
milliseconds.
 
 
 Figure
25
–
End
to
End
delay
from
End
Devices
to
Coordinator
(As
Is)
 
 19 
 Figure
26
–
End
to
End
delay
from
End
Devices
to
Coordinator
(Time
Average)
 
 
 These
results
show
that
sending
data
with
a
VBR
does
not
decrease
the
performance
of
 a
ZigBee
network.
The
latency
of
the
network
is
still
steady
even
at
the
presence
of
 varying
packet
sizes.
 
 
 3.5 Testing
the
ZigBee
OPNET
Model
Limits
–
Adding
Additional
End
 Devices
 
 During
our
simulations
of
various
scenarios,
we
noticed
that
the
ZigBee
model
in
OPNET
 has
some
limitations
and
unfinished
features.
One
of
these
limitations
is
connecting
only
 up
to
two
end
devices
per
router.
We
know
from
the
ZigBee
specifications
that
a
ZigBee
 network
can
have
more
than
64000
nodes,
so
for
this
scenario,
we
simply
tried
to
 connect
3
end
devices
to
a
single
router,
and
see
if
the
router
can
handle
the
incoming
 traffic.
 
 Figure
27
below
shows
the
traffic
path
in
the
case
of
two
routers
with
three
end
devices.
 All
the
end
devices
manage
to
connect
to
a
router
to
send
traffic
to
the
destination
 coordinator.
 
 
 Figure
27
–
Case
of
two
routers
and
three
end
devices
 20 
 
 The
graph
below
shows
the
traffic
being
received
by
the
coordinator
(blue)
and
the
 traffic
being
sent
by
the
three
end
devices
(red
overlaps
with
green
and
light
blue).
This
 graph
indicates
that
the
coordinator
has
sufficient
bandwidth
in
the
channel
to
receive
 the
level
of
traffic
coming
from
three
end
devices.
 
 
 Figure
28
–
Traffic
sent
by
the
end
devices
and
received
by
the
coordinator
 
 Next
figure
shows
the
traffic
path
when
the
bottom
router
is
disabled.
It
can
be
seen
 that
END_DEVICE_1
(middle
end
device)
fails
to
establish
a
traffic
path
to
the
router.
 This
is
a
result
of
lacking
the
slotted
CSMA/CA
with
beaconing
feature
along
with
 Guaranteed
Time
Slot.
Once
two
of
the
end
devices
connect
to
a
router,
it
shares
the
 connection
(during
intermitting
traffic
send
times)
but
does
not
allow
for
the
third
end
 device
to
join.
Also,
the
router
is
not
capable
of
assigning
the
time‐slot
to
schedule
in
 the
third
end
device.
 
 Figure
29
–
Case
of
single
router
and
three
end
devices
 
 21 
 The
result
indicates
that
the
end
device
in
the
middle
(END_DEVICE_1)
was
unable
to
 deliver
any
of
the
packets
as
they
were
all
dropped
en
route
(red
line)
while
the
other
 two
end
devices
(blue
overlap
with
green)
experienced
no
dropped
packets.
 
 
 Figure
30
–
Traffic
from
three
end
devices
dropped
en
route
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 22 4 DISCUSSIONS
AND
CONCLUSION
 
 4.1 OPNET
ZigBee
Model
Limitations
 
 Through
this
project,
we
have
learned
some
of
the
limitations
about
the
ZigBee
model
in
 OPNET.
The
most
noticeable
limitation
of
the
ZigBee
model
is
the
incomplete
 implementation
of
the
beaconing2
capability
(“Note:
Beacon
Enabled
mode
is
not
 currently
supported.
This
attribute
is
a
placeholder”).
 
 Also
lacking,
is
support
for
slotted
CSMA/CA
mode
and
contention
–
free
operation
 mode.
This
seemed
to
prevent
the
devices
from
having
“fair”
use
of
the
resource
by
 scheduling
the
end
devices
to
gain
access
to
the
channel.
 
 One
of
the
difficulties
at
the
early
stages
of
this
project
was
the
lack
of
mention
in
the
 range
capability
of
ZigBee.
Since
the
OPNET
ZigBee
model
was
incomplete
we
expected
 an
earlier
version
of
ZigBee
with
specified
range
of
~100meters.
However,
the
OPNET
 ZigBee
model
was
capable
of
handling
ranges
beyond
1200meters
at
default
settings
for
 transmission
power
and
reception
power.
This
initially
caused
the
end
devices
to
skip
 over
the
routers
and
communicate
directly
with
the
coordinators
(showing
no
variation
 in
the
results
for
3.2).
 
 
 4.2 What
We
Learned
 
 Through
this
project
we
were
given
the
opportunity
to
learn
not
just
any
protocol
and
 OPNET
but
a
technology
of
interest.
Switching
over
to
ZigBee
from
Bluetooth
part
way
 due
to
limited
availability
of
a
Bluetooth
library
from
OPNET
required
some
catching
up,
 possibly
limiting
our
opportunity
to
do
a
little
more,
but
this
provided
us
with
an
 opportunity
to
learn
a
lot
about
ZigBee,
a
growing
technology,
in
terms
of
general
 application
and
technical
aspects.
Through
simplified
scenarios
with
an
assortment
of
 variations,
we
were
able
to
better
understand
the
results
in
reasonable
time
compared
 to
having
complex
scenarios
and
results,
then
having
to
spend
a
lot
of
the
project
time
 trying
to
make
sense
of
things.
 
 We
also
learned
the
various
functionalities
and
models
OPNET
is
capable
of,
despite
the
 ZigBee
model
being
only
a
small
portion
of
OPNET,
as
well
as
some
of
the
limitations
in
 using
OPNET.
We
experienced
a
bit
of
disappointment
with
the
incomplete
ZigBee
 model
library
and
hidden
implementation
of
layers
(except
the
MAC
layer).
 
 2 Beacon enabled network allows for much longer battery life by allowing the device to go to sleep periodically only to wake to notify the network of its presence when not in use 23 5 REFERENCES
 
 [1]
IEEE
Standard
for
Information
technology‐
Telecommunications
and
information
 exchange
between
systems‐
Local
and
metropolitan
area
networks‐
Specific
 requirements
Part
15.4:
Wireless
Medium
Access
Control
(MAC)
and
Physical
Layer
 (PHY)
Specifications
for
Low‐Rate
Wireless
Personal
Area
Networks
(WPANs),
IEEE
 Standard
802.15.4,
2006.
[Online].
Available:
 http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1700009&isnumber=35824
 
 [2]
N.
Liang,
P.
Chen,
T.
Sun,
G.
Yang,
L.
Chen,
and
M.
Gerla,
“Impact
of
Node
 Heterogeneity
in
ZigBee
Mesh
Network
Routing,”
in
IEEE
Int.
Conf.
Systems,
Man
and
 Cybernetics,
vol.
1,
Taipei,
Taiwan,
2006,
pp.
187‐191.
[Online].
Available:
 http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4273827&isnumber=4273788
 
 [3]
J.
Sun,
Z.
Wang,
H.
Wang,
and
X.
Zhang,
“Research
on
Routing
Protocols
Based
on
 ZigBee
Network,”
in
Thrid
Int.
Conf.,
Intelligent
Information
Hiding
and
Multimedia
 Signal
Processing,
vol.
1,
Kaohsiung,
Taiwan,
2007,
pp.
639‐642.
[Online].
Available:
 http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4457629&isnumber=4457471
 
 [4]
X.
Xu,
D.
Yuan,
and
J.
Wan,
“An
Enhanced
Routing
Protocol
for
ZigBee/IEEE
802.15.4
 Wireless
Networks,”
in
Second
Int.
Conf.,
Future
Generation
Communication
and
 Networking,
Hainan,
China,
2008,
pp.
294‐298.
[Online].
Available:
 http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4734107&isnumber=4734039
 
 [5]
Digi
International,
“ZigBee
Wireless
Standard,”
Digi
Making
Wireless
M2M
Easy.
 [Online].
Available:
http://www.digi.com/technology/rf‐articles/wireless‐ZigBee.jsp.
 [Accessed:
2009‐02‐28].
 
 [6]
Jennic,
“Welcome
to
Jennic’s
ZigBee
e‐learing
Course,”
2007.
[Online].
Available:
 http://www.jennic.com/elearning/zigbee/files/content_frame.htm
 
 [7]
Mesh‐Matrix
Inc.,
“What
is
ZigBee,”
2007.
[Online].
Available:
http://mesh‐ matrix.com/en/technology/tech_zigbee.aspx
 
 [8]
P.
Jurčík,
A.
Koubâa,
M.
Alves,
E.
Tovar,
and
Z.
Hanzálek3,
“A
Simulation
Model
for
 the
IEEE
802.15.4
Protocol:
Delay/Throughput
Evaluation
of
the
GTS
Mechanism,”
 [Online].
Available:
http://dce.felk.cvut.cz/hanzalek/publications/Hanzalek07g.pdf
 24

    Top_arrow
    回到顶部
    EEWORLD下载中心所有资源均来自网友分享,如有侵权,请发送举报邮件到客服邮箱bbs_service@eeworld.com.cn 或通过站内短信息或QQ:273568022联系管理员 高进,我们会尽快处理。