Transcript Autonomic Wireless Sensor Networks: Intelligent Ubiquitous

PART I: IEEE 802.15.4, a novel MAC/Phy
layer for the Zigbee stack
A.G. Ruzzelli
Adaptive Information Cluster (AIC) Group,
University College Dublin,
Ireland.
Summary
Wireless Sensor networks (WSNs)




Zigbee generality




Overview of the stack
The components
The primitives
Zigbee NWK layer




The NWK layer architecture and services
The address assignment
The AODV protocol
IEEE 802.15.4






Generality
Prototypes
Application Requirements
Generality
Superframe structure
Transmission modes
Association phase
Conclusion
Energy-Efficient Wireless Sensor Networks
(WSNs)
• A large number of tiny wireless devices to sense the environment:
– Sensor nodes
Sensing unit
(temp,pressur
e, vibration,
sound, etc.)
Small
Short range
processing radio unit
unit
Small
power
unit
(battery)
• Few more powerful devices to collect the data:
– Gateways (or sinks or PAN coordinators)
Wireless comm. unit
High processing
unit
Wired comm. unit
PDA, laptop, PC etc.
High power
unit
Some WSN applications
•
Remote area monitoring
•
Object location
•
•
Industry machinery monitoring
Disaster prevention
•
Wireless medical systems
Wind Response
Of Golden Gate Bridge
environmental data collection:
temperature light, humidity, pressure,
solar radiation.
Monitoring nesting
patterns of Storm Petrels.
medical systems
Wireless sensor characteristics
•
•
Sensors are of :
• Low cost
• Low processing capability
 System strength based on sensor
collaboration
•
Large scale networks
 Multihop communication
Sensors are battery operated for long unattended period:
 Saving energy is a primary objective
WSN manager
WSN issues
•
Large number of nodes
Scalability issues
•
High dynamic condition (number and position of nodes might change)
 Network Reactivity and Self-organization
•
Power management
The network needs to be connected as long as possible
•
System reliability
The wireless signal needs to cope with interference
Coordination among node communication
•
Node synchronization (clock skew and offset)
To avoid sending to a sleeping node
•
Robustness
Subject to environmental variability (harsh condition)
Complex interoperability of network devices
Sensor node prototypes
Mica2 mote
Tyndall sensor
Eyes node prototype
Philips sand nodes
General sensor node architecture:
Sensing
devices
Application
Data interpolation
Sensing coverage
Localization
Routing
MAC
Physical
Antenna
Cross layer interaction
• Any layer try to achieve the task
using the smallest amount of
energy possible
The need of the Zigbee standard
• An exponential increase of the interest on WSNs
• No communication systems that addressed:
–
–
–
–
–
Energy efficiency;
Low cost devices;
Low data rate per node;
Very low duty cycle;
Scalability (e.g. issues with Bluetooth);
• WSN proprietary systems cause interoperability problems
Stack Reference Model
End developer applications, designed
using application profiles
Application interface designed using
general profile
Topology management, MAC
management, routing, discovery
protocol, security management
Channel access, PAN maintenance,
reliable data transport
Transmission & reception on the
physical radio channel
ZA1
ZA2
…
ZAn
IA1
API
IAn
UDP
IP
ZigBee NWK
802.2 LLC
MAC (SSCS)
IEEE 802.15.4 MAC (CPS)
IEEE 802.15.4 PHY
LLC= logical link control
SSCS = Service specific convergence sublayer
Protocol Stack Features
• 8-bit microcontroller
• Full protocol stack <32 KB
• Simple node-only
stack ~4KB
• Coordinators
require extra RAM
– Node device database
– Transaction table
– Table of neighbours
APPLICATION
Customer
APPLICATION INTERFACE
NETWORK LAYER
DATA LINK LAYER
MAC LAYER
MAC LAYER
PHY LAYER
Silicon
ZigBee Stack
Application
ZigBee
Alliance
IEEE
Z-NWK layer: The components
Zigbee coordinator (ZC)
•Only one ZC present in the network
• Initiates the network formation
(PAN ID, channel stack etc.)
•It acts as PAN coordinator with FFD
capability
•It can act as a router to other nodes
•It acts as interface between the user
and the network
Z-NWK layer: The components
Zigbee router (ZR)
• Responsible for tree/mesh
packet routing
•Associates/disassociates node to
the network
•Coordinates communication to
children nodes
•It is in RX mode when idle
(no sleep mode implemeted)
•Maintains a table of neighbours
Z-NWK layer: The components
Zigbee end device (ZED)
•It has reduced functionalities
• It has reduced duty cycle
regulated by the parent ZR
•It can talk with the parent ZR only
•It cannot associate other nodes
Zigbee primitives and services
•
•
•
Zigbee primitives are used to
communicate between layers
4 primitive types are present:
– Request/confirm
– Indication/response
Layers communicate through the
entitities of the Service Access Point
(SAP)
e.g. NLDE-SAP = network layer
data entity-SAP
Upper layer
Request
Confirm
Indication
Lower layer
Response
Architecture of the Z-NWK layer
•
•
•
•
•
•
ZigBee Device Types
Stack Profile, Network Rules
Network Management and Addressing
Message Routing
Route Discovery and Maintenance
Security
Network formation modalities
Star topology
Mesh topology
PAN coordinator
Tree topology
Coordinator FFD
End device RFD
NWK Layer services
•Layer management entity LME
allow requesting services and interfacing to other layers
Layer data entity LDE
Allow transmitting data
SAP= Service access point
Network Initiation by ZCoordinator
•
NLME_NETWORK_DISCOVERY.request
– Performs an Active Scan
– Looks for other ZigBee networks on the channel
– Selects a compatible network Stack Profile
Network Association: ZR & ZED
•
NLME_JOIN.request
–
–
–
–
–
•
Selects the highest acceptable router
Link Quality, with capacity
Associates with the router
Allocated an address on the network
Device authenticates with network
NLME_START_ROUTER.request
–
–
–
–
Updates Beacon Payload
Depth, Capacity
Starts a router
Updates Association Permit Status
Transmitting data
•
NLDE-DATA.request
–
–
–
–
–
–
•
Used by NHL for all data transmissions
Uni-casts and broadcasts
Accepts the following parameters
Destination Address
Radius
Discover Route
NLDE-DATA.indication
– Reports the receipt of a data transmission
– Includes the following parameters
– Source Address
IEEE addressing
• IEEE provides unique long address of 64bits for nodes that uses
802.15.4
• Long addresses cause high data overhead if used for node
communication
• Communication relies on not-unique short address of 16bits
(65536 devices)
• Short adrresses are forged by the Zigbee address assignment
procedure
Zigbee Tree-structure address assignment
Router (FFD) at depth d+1
Cskip(d) = [1 + Cm-Rm-Cm*Rm^(Lm-d-1)]/(1-Rm)
N-th end device (RFD)
An = Aparent + Cskip(d)Rm+n
Note: In order to assign addresses, it is
necessary to know a priori maxDepth,
maxRouter numbers and
maxNumbChildren
Ad-Hoc on demand vector (AODV) routing
Route discovery
• Find or update route between specific source and destination
• Started if no active route present in routing table
• Broadcast routing request (RREQ) packets
• Generates routing table entries for hops to source
• Endpoint router responds with Routing response (RREP) packet
• Routes generated for hops to destination
• Routing table entry generated in source device
The ADOV protocol
• Route discovery
• A routing table is required if a route already exists
2
1
5
RREQ
RREP
3
2
1
4
picture taken from “ZigBee” presentation by Jan Dohl et al.
THE IEEE 802.15.4
• Defined by the IEEE for low-rate, wireless personal area
networks (WPANs).
• Defines the physical layer “Phy” and the medium access
control layer “MAC”.
• low-power spread spectrum signal at:
Operating Frequency Bands
868MHz / 915MHz
PHY
2.4 GHz
PHY
2.4 GHz
Channel 0
Channels 1-10
868.3 MHz
902 MHz
Channels 11-26
2 MHz
928 MHz
5 MHz
2.4835 GHz
Concurrent channel allocation
• An example of Frequency Channel allocation for device classes
IEEE 802.11b channel
Bluetooth cannels
in North America and Europe
IEEE 802.11b channel
in Europe
2400
2401
2402
2403
2480
2481
2482
2483
picture taken from ZigBee Specifications v1.0
IEEE 802.15.4: PHY layer
2400MHz Band specs
•
4 Bits per symbol
•
DSSS with 32 Bit chips
•
O-QPSK modulation
•
Sine halfwave impulses
Binary Data
Bit
to
Symbol
Medium
Symbol
to
Chip
QPSK
Mod.
picture taken from IEEE 802.15.4 Specification
PHY layer contd.
• General specs and services
•
•
•
•
•
•
Error Vector Magnitude (EVM) < 35%
-3dBm minimum transmit power (500µW)
Receiver Energy Detection (ED)
Link Quality Indication (LQI)
Use ED & LQI to reduce TX-power
Clear Channel Assessment (CCA) with 3 modes
– Energy above threshold
– Carrier sense only
– Carrier sense with energy above threshold
Device types
• In conformity with Zigbee devices, IEEE802.15.4 are of 3
types:
– PAN coordinator
• Act as network initiator
• Only one allowed in the network
– Full functional devices FFDs
• That have all access control functionalities implemented
(channel scan, beacon transmission, association etc.)
– Reduced functional devices RFDs
• That can only talk to the FFD that associated them
IEEE 802.15.4: MAC layer
• Managing PANs
•
•
•
•
•
•
•
•
Channel scanning (ED, active, passive, orphan)
PAN ID conflict detection and resolution (in progress)
Starting a PAN
Sending beacons
Device discovery
Device association/disassociation
Synchronization (beacon mode)
Orphaned device realignment
Beacon/nonbeacon-enable modes
•Beacon-enabled mode:
•Beacons are broadcasted periodically by the FDD
•Beacons do not employ CSMA prior transmission
•Beacons contain info related to superframe length
and GTS allocation details
•ACK is optional
•Nonbeacon-enabled mode:
•The MAC reduces to a simple unslotted CSMA-CA
•No Superframe
•No GTS
•ACK is optional
The superframe structure
•Becons, transmitted by FFDs, contain a superframe specification
IEEE 802.15.4 association phase
Coordinator FFD
RFD
RFD: Broadcast Beacon request
FFD: Superframe spec.
RFD: Association req..
FFD: ACK with seq#.
FFD: Broadcast standard
timezone packet
FFD: Broadcast
standard data packet
RFD: Data request
FFD: ACK with seq#.
FFD: Association response with short ID.
RFD: ACK with seq#.
The IEEE802.15.4 chip
•
IEEE802.15.4 is coded onto the chip
CC2420 (partially hard coded)
•
Zigbee licence must be bought separately
•
Zigbee compliancy might be lost if some
change to the code is made
 NOT very suitable for research
purposes
End of PART I
PART II: MERLIN over IEEE 802.15.4:
routing capabilities without Zigbee
A.G. Ruzzelli
Adaptive Information Cluster (AIC) Group,
University College Dublin,
Ireland.
Network formation by the IEEE 802.15.4 MAC
•
•
•
One PAN coordinator
Zero or more coordinators
Zero or more end devices
•
First device starts the network as PAN
coordinator
A new device can detect all coordinators
(both the PAN coordinator and
coordinators)
A device can join the network by
associating with any coordinator in range
After joining a device can volunteer as
coordinator
•
•
•
PAN coordinator
Coordinator
End device
Step 1: Starting a new network
•
Device starts network scan
(MLME_SCAN)
•
Detects no network
•
Starts new network as PAN
coordinator (MLME_START with
PANCoordinator=TRUE)
•
If PANCoord then other devices in
range can discover device 1 by
means of a network scan
1
PAN coordinator
Coordinator FFD
End device RFD
Step 2: Second device joins the network
•
Device 2 starts network scan
(MLME_SCAN)
•
Detects PAN coordinator device 1
•
Sends association request to device 1
(MLME_ASSOCIATE)
•
1
2
Node2 is now and End device 
Other devices cannot discover device
2 by means of a network scan
PAN coordinator
Coordinator FFD
End device RFD
Step 3: Device 2 becomes a coordinator
•
•
Device 2 starts serving as a coordinator
of the existing network (MLME_START
with PANCoordinator=FALSE, PANId &
channel parameters are ignored)
Node2 is now Other devices in range can
now discover device 2 by means of a
network scan
1
2
PAN coordinator
Coordinator FFD
End device RFD
Step 4: Device 3 joins the network
•
Device 3 starts network scan
(MLME_SCAN)
•
Detects coordinator device 2
(assuming device 1 is not in range of
device 3)
•
Sends association request to device 2
(MLME_ASSOCIATE)
•
Note: Other devices cannot discover
device 3 by means of a network scan
1
2
3
PAN coordinator
Coordinator FFD
End device RFD
Step 5: Device 4 joins the network
•
Device 4 starts network scan
(MLME_SCAN)
•
Detects two coordinators: device 1 and
device 2
(assuming device 1 and device 2 are in
range of device 4)
1
4
2
•
Sends association request to device 1
(MLME_ASSOCIATE)
(alternatively it could join the network also
through device 2)
3
PAN coordinator
•
Note: Other devices cannot discover device
4 by means of a network scan
Coordinator FFD
End device RFD
Step 6: Device 4 becomes a coordinator
•
Device 4 starts serving as a
coordinator of the existing network
(MLME_START with
PANCoordinator=FALSE, PANId &
channel parameters are ignored)
1
4
•
Note: Other devices in range can now
discover device 4 by means of a
network scan
2
3
PAN coordinator
Coordinator FFD
End device RFD
Other devices can join in the same way
•
•
•
IEEE 802.15.4 allows only direct (single
hop) communication between two devices
that are in range of each other.
5
6
IEEE 802.15.4 leaves it to the higher
layers to define how network-wide unique
short MAC addresses are assigned by
coordinators.
Extended MAC addresses can be used
instead of short addresses  High
packet overhead
1
4
2
7
8
3
PAN coordinator
Coordinator FFD
End device RFD
Other devices can join in the same way
A networking protocol (e.g. ZigBee) on top of
IEEE 802.15.4 is required to allow
communication between nodes that are
not in range of each other by routing of
packets via intermediate nodes (multi
hop).
•
•
ZigBee defines how short NWK
addresses are assigned to devices.
The short NWK addresses are used also
as short MAC addresses.
5
6
1
4
2
7
8
3
PAN coordinator
Coordinator FFD
End device
Issue 1: The hidden association problem
•
•
The IEEE 802.15.4 does NOT provide
coordination between coordinators
End devices (RFDs) can talk to its
coordinator only
5
6
1
 packet collisions might occur
•
•
4
1) Eg. Node9 transmitting to node2
might generate collision at node8 that
is receiving from node11.
2) Eg. Either node10 and node7
transmission might prevent correct
neighbouring node reception
9
2
8
11
3
7
10
PAN coordinator
Coordinator FFD
End device RFD
Issue 2: Beacons are weak
•
Beacons are more prone to collide as
transmitted without CSMA
•
If a beacon collides then no children
RFD devices can transmit or receive.
1
4
9
8
11
Tx
Beacon
2
Beacon
Beacon
3
10
7
Question
• Q.1 How can we avoid packet collisions?
• A.1 By using RTS/CTS/ACK
– Cons1 We lose the 802.15.4 compliancy
– Cons2: Results show a very long delay when associated to low node duty
cycle
1
9
RTS
11
8
CTS ACK
2
PAN coordinator
Coordinator FFD
End device RFD
Can we at least mitigate collisions without lose the
compliancy?
• YES
5
– 1)You let all nodes become full
functional devices (FFDs)
6
1
4
• PROS:
– FFDs can perform carrier sensing
before transmitting a packet
– Any node is free to talk to any other
node  peer-to-peer communication
9
8
• CONS:
– IEEE 802.15.4 does not define any
sleeping mode for FDDs
 High energy consumption
2
11
3
7
10
PAN coordinator
A sleeping scheduling for FFD devices is needed!
Coordinator
End device
How all nodes can become FFDs
void mlmeAssociateIndication(ADDRESS deviceAddress, BYTE capabilityInformation, BOOL
securityUse, UINT8 aclEntry)
{ // We accept all association requests here.
if( gAF_ApplInfo.appCoordinator == IAM_COORDINATOR ||
gAF_ApplInfo.appCoordinator == IAM_COORD_W_BEACON ||
gAF_ApplInfo.appCoordinator == IAM_ASSOCIATED_COORD )
//By Ruzzelli
…
…
void mlmeAssociateConfirm(WORD assocShortAddress, MAC_ENUM status)
{
if( status != SUCCESS ) return;
if( assocShortAddress == 0xFFFD ) return;
gAF_MyShortAddr = assocShortAddress;
gAF_ApplInfo.appCoordinator = IAM_ASSOCIATED_COORD;
//by Ruzzelli
TICOSS: TImezone COOrdinated Sleeping
Scheduling for FFDs
– We organize nodes in timezones
(TZ) based on the number of hops
to the PAN coordinator
5
TZ 2
1
–We address nodes either
–solely based on their TZ
–using the short address
provided by the Zigbee address
procedure
–We inject a sleeping scheduling
table to coordinate FDDs’ activitiy
TZ 1
6
TZ 1
4
TZ 1
9
8
TZ 2
11
2
TZ 1
TZ 2
7
TZ 1
TZ 1
3
10
PAN coordinator
Coordinator
End device
The origin of TICOSS
• TICOSS is derived from the routing characteristic of
MERLIN [1] adapted to the IEEE 802.15.4
•DESIGN goals:
•MAC+Routing integration into a simple architecture;
•No usage of handshake mechanisms;
•No specific node addressing  Upstream/downstream
Multicast;
•Reduced latency along a very low energy consumption
•Increasing communication reliability while limiting packet
overhead;
[1] Ruzzelli, A.G., O’Hare, G.M.P., O’Grady, M.J., Tynan, R., MERLIN: A synergetic integration of MAC and routing
protocol for distributed sensor networks, In SECON06, Third Annual IEEE Communication Society Conference on
Sensor, Mesh and Ad Hoc Communications and Networks Reston, VA, USA, September 25-28, 2006
Timezone data traffic scheduling
Zone 3
Zone 2
Zone 1
Downstream multicast:
Packets transmitted to
higher zones
Sleeping
Upstream multicast:
Packets are forwarded
to lower zones
Local broadcast:
Packets reach all
neighbours. No
forwarding performed
Global allocation
Frame
Frame
Zone 1
Zone 2
Zone 3
Zone 4
Zone 5
Zone 6
Zone 7
Zone 8
The allocation of further zones can be obtained by appending the same table.
The allocation of further frames is obtained by flanking the same table.
Accessing the table
NZONE = 4
NSLOT =9
To access the current slot in the table:
SLOT# = GlobalTime/SLOTTIME
currentSlot = Mod(SLOT#, NSLOT)
Nodes in the same timezone contend the slot for local broadcast only once
each 4 frametimes
If Mod(FRAME#, NZONE) = Mod(myZone,NZONE)
TICOSS over 802.15.4
PAN coord
• Nodes in the same zone share the same slot for activity
• Intra-zone transmission is regulated by IEEE 802.15.4
• Inter-zone transmission is regulated by the scheduling
The network-wide unique address
•
Recall that with TICOSS as a routing protocol, we can
1. Address nodes solely based on their TZ
(MULTICAST)
a node transmits data packets only specifying the
timezone of the receiver
•
PROS:
–
–
–
•
Avoid problems of address conflicts
Avoid issues of running out short addresses
Reduce the actual byte transmitted (for special transmission I
can still use the long address)
CONS:
–
–
multiple copy of the same msg sent can be generated
increase transmission overhead!
ACK not used
(the original MERLIN version uses burst tone instead)
2. Use the Zigbee address assignment procedure to
address a secific nodes (UNICAST)
a node transmits data packets to the node with
highest cost link function
Zone 1
Zone 2
Zone 3
A
PAN coord
B
Zone 4
Zone 5
Packet ACK
• In TICOSS, packet transmission can be:
– Multicasted to higher or lower timezones
• No ACK is performed
– Unicasted to a selected node that is chosen
based on a tunable cost function
• Successful reception are ACK by transmitting back
the IEEE802.15.4 sequence packet number
Routing characteristics (I)
Controlled multipath
•
3 small buffers of upstream, downstream and local broadcast are provided
•
Packets organised in multiple msgs of the same data traffic type;
•
Packets contain a msg-ID index of included msgs;
•
Nodes, which lose the contention, keep on listening to the beginning of the transmitted
packet then go into sleep;
•
Nodes discard from their buffer the msgs already fowarded.
P
Msg-index
a
c
k
e
Channel contention
t
messages
Pro : Reduce overhead in transmission!
Con : Small increase of node activity;
Increase complexity.
Discard msgs
already
forwarded from
their queue
Listen
to the
packet
index
Routing characteristics (II)
Timezone maintenance
•
Timezone update are sent periodically;
•
Failed reception of timezone update from zone N-1 node to zone N node triggers a upstream
multicast of Timezone Update request (TUR)
–
•
N-1 failed  local broadcast TUR
–
•
N-1 node/s reply  Connection reestablished
At least one reply  change of zoen to N+1
N failed  downstream broadcast TUR
2
1
2
1
1
3
3
2
1
3
4
2
2
3
4
4
4
6
TUR
4
3
TUR
5
TICOSS/MERLIN analogy
•
Similarities
– Both protocols use same routing
features;
– Both protocols use a slotted
CSMA to access the channel
•
Differences
– MERLIN is a proprietary
integrated MAC and routing
protocol, instead TICOSS
uses the IEEE 802.15.4
MAC+Phy features,
– MERLIN uses burst ACK to notify
correct incorrect receptions,
instead TICOSS has two ACK
modalities:
• Multicast with ACK disabled
• Unicast with ACK enabled
MERLIN Assessment
Simulation tool: OmNet++
Framework: EU EYES project
Evaluation of MERLIN against SMAC+ESR
Experiments:
Philips Sand node implementation
Evaluation of TICOSS in progress
Scenario and Setup
•Scenarios
•Metrics:
•5 nodes two-hops
Forwarder
Sources
Destinations
•Energy consumption per RX packet
•Network lifetime
•E-to-E latency
•Total packet overhead
•% sleeping time
•Parameters:
•70 nodes Random
multihop
•Duty cycle (acting on CW and frametime size)
•Low traffic conditions (12 packet/min)
•High traffic conditions (60 packet/min)
V scheduling Network lifetime.
V-scheduling
The network lifetime
depends linearly on the
frame length;
300
V-Scheduling
250
200
150
100
50
0
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
Frametime (sec)
1 Gateway
800*500 area network
50 msg/min sent by 5 rand. nodes
100 Nodes rand. Distributed.
Min signal strength(12 m)
Static network
•The network is considered to fail when 30% of nodes are depleted.
•Lifetime calculated for a linear depletion of 2 AA batteries.
V scheduling setup time
V-Scheduling Network Setup
10
Time (sec)
8
6
4
2
0
0
50
100
150
200
Node Density (nodes/100 m^2)
250
V scheduling can be
setup in less than 10
seconds up to 250
nodes/100m^2 of
network density.
End-to-end packet delay
V-scheduling
Node density = 125 nodes/100m^2
5.12
5
5.52 5.45
2.87
2.31
6.18 6.38
7
4.12
4
7.51
8
5.52
Latency (sec)
6
Latency (sec)
9
6.31
7
3
Node density = 275 nodes/100m^2
7.51 7.52
8
2.52
6
5
4.01
4
3
2
2
1
1
4.52
6.85
8.02
8.52
6.52
4.18
3.52
1.61 1.52 1.51
0
0
1
2
3
4
5
6
7
Node hop count
8
9
10
11
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Node hop count
•
The controlled multiple path mechanism may cause a lower delay for
nodes farther from the gateway;
•
An increase of latency at the intersection of data traffic flows due to
periodical stop of nodes activity that go into sleep.
•V-scheduling delay obtained
for 2sec frametime length
Frametime length should be based
upon application requirements.
Low traffic 2-hops scenario
High traffic 2-hops scenario
Multihop scenario: Lifetime
Note: These graphs have little relevance if not related to the EtoE latency
Multihop scenario: Latency/energy
Given a certain sustainable latency, MERLIN consumes between 2 and 2.5 times
less energy than SMAC+ESR
Total packet overhead
The MAC routing integrated nature MERLIN results in a smaller
packet overhead than SMAC+ ESR.
Conclusion
• PART I:
– The Zigbee stack has been presented;
– A focus on IEEE 802.15.4 has been given;
• PART II
– We described how to build networking capabilities over IEEE
802.15.4
– We presented TICOSS, which is derived from the MERLIN
protocol, as a tree-based routing layer
– MERLIN simulated results have been presented
Thank you!
www.csi.ucd.ie/research (Prism LAB web site)
www.adaptiveinformation.ie (AIC project)
An application for TICOSS
• Sensor-based wireless medical systems
Appendix: MERLIN MAC features
Intra-zone MAC features
Zone N+1
Zone N
Zone N-1
Recall that
• Nodes in the same zone share the same slot for activity
• transmission in MERLIN (multicast) do not address a
specific receiving node
How can simultaneous transmission be handled?
How can correct/incorrect receptions be notified?
Burst tones can help
• Properties
– Are signal impulse Do not contain any coded information
– Are robust  Several simultaneous burst can still be
identified as one burst
– They are shorter that a normal ACK
• Utilization
In transmission to the gateway
Multicast: Bursts identify correct receptions
BACK
In local broadcast
Broadcast: Bursts identify reception errors
BNACK
Asynchronous transmission Mechanism
Tc
Tc
CCA
Tx1
Preamble
CCA
Packet
Sleep
Tc
Rando
m
CCA
Preamble
CCA
Packet
Sleep
Tx2
Rando
m
Sleep
Listen
Sleep
Transmit
CCA
Rx1
Burst*
Listen
Sleep
Sleep
Burst*
CCA
Rx2
Listen
Sleep
Sleep
Slot length
Rx1
* burstACK if local broadcast, burst NACK if multicast
Rx1
Tx1
Tx1
Tx2
Rx2
Rx2
Tx2
Disadvantages
1)MERLIN does not address a
specific receiving node 
Zone 1
Zone 2
Zone 3
A
multiple copy of the same msg
sent can be generated
B
increase overhead!
2) Some collisions due to the
Hidden Terminal Problem (HTP)
Zone 3
A
?
B
Zone 4
Zone 5
Something more about the work that we do at
the PRISM group:
Autonomic WSNs:
• Origin of autonomic computing by IBM
Relieve human of the burden of managing large scale
computer systems
• Autonomic WSNs properties:
–
–
–
–
–
Self healing
Self protection
Self configuration
Self optimization
Self managing
Agent technology for autonomic WSNs
• Agent properties:
– Sense-deliberate-act cycle
• Sensing data is used as input for the decision making process
– Mobility
• Useful characteristic of agents that well map onto WSNs
• Agent can migrate from one node to another processing data
as it goes
– Fault tolerance
• Agents can still take decision if some data are missing
An example: Network anomaly intervention
Possible solution Multiple Notification
messages (High energy consuming)
Proposed solution: Migrating agent
(Moderate energy consuming)
Contribution of autonomic computing to WSNs
•
Self configuring nodes
(1) can set up a network;
(2) might not be well positioned but still work;
(3) can evaluate network gaps;
(4) can decide communication schedule.
•
Self protection attribute
– Migrating agents check channel condition and battery level before migrating
•
Self healing
–
–
–
–
•
Repair network damage due to hash work condition
Negotiating new routes;
Activating redundant nodes;
Ask for replacement of damaged nodes.
Self optimization
– Quality of service
– Network efficiency
– Delay control and data prioritization
Intelligence-aided sensor network
• Opportunistic power management
• Intelligent coverage
• Intelligent routing
Opportunistic power management (1)
• Increase network longevity by deactivating redundant
nodes: node hibernation
• Sensing Coverage:
– All points within the sensed area need to be covered by at least 1
sensor. Traditionally, a point is covered if it is within the sensing
range of a given sensor.
Gateway
Redundant based
on sensor coverage
Intelligent sensing coverage
• It deals with the quality of sensory data provided to the
application which is using it;
• Data sampling frequency at the node and surrounding
nodes should be enough to have a certain detail of the
phenomena of interest;
• Migrating agents control:
– Sensor sampling rate by tuning it;
– Might request an increase of node density in an area
Intelligent routing
• By interacting with different layers
the agent can check several
parameters
MAC
Physical
Antenna
table
• Even with incomplete data an agent
can figure out the best neighbours
to which to forward the data to
Routing
Route managing
Agent
• A look-up table with neighbouring
nodes parameters (RSSI, battery
level, location) is provided