tc90: presentation title
TRANSCRIPT
Multi-Channel Real-Time Communications in Wireless Sensor Networks
by Xiaodong Wang
Nov 18th, 2008
Page 2
First Paper
Flow-Based Real-time CommunicationIn Multi-Channel Wireless Sensor Networks
By Xiaodong Wang, Xiaorui Wang,Xing Fu, Guoliang Xing,
Nitish Jha
Page 3
Introduction
Real-time Requirement A lot of application of WSN require real time service quality:
Wood fire monitor Battle field application
Real time service quality hamper Existence of interference
Packet cannot be received because of collision Long packet routing path Too many service request
Border Intruder Monitor Alarm System
Page 4
Related Works Single channel real-time communication
Implicit EDF Collision-free real-real time scheduling
SPEED Enforcing uniform communication speed
None of them take advantage of multi-channel
Multi-channel protocols and channel assignment Node-based protocol
Require switching channel Interference free assignment
Some require synchronization
Transmission power control RPAR
High power transmission incur interference to others Most do not deal with real-time requirement
Page 5
Empirical Study on Multi-Channel Communication Power adaptation in RPAR
With single channel, increasing power has significant impact to other’s transmission Almost 40% drop ratio when the
communication power is low
Multi channel highly mitigate this problem.
Experimental Setup
Single Channel
Multiple Channel
Page 6
Multi-Channel Real-Time Protocol
Multi-Channel Real-Time Protocol (MCRT) Especially designed for the real-time application in multi-channel WSNs It is designed for meeting the end-to-end delay
Application traffic type: many to one communication Main components:
Flow-based channel allocation Power-efficient real-time routing
Contributions: Formulate the constrained optimization problem Heuristics is proposed Incorporating power efficient component Massive Simulations
Page 7
Flow Based Channel Allocation Link Weight
Packet Reception Ratio (PRR) 3 Communication Relationships:
Communication link: PRR > 90% Interference link: 90%>PRR>10% Cannot communicate: PRR<10%
Number of retries = 1/PRR Worst case one hop delay
End to end delay: Summation of the one hop delay along a path
Page 8
Flow Based Channel Allocation (cont’)
Channel assignment requirement: Each data flow is assigned a different channel Each data flow should be disjoint
Disjoint Path with Bounded Delay problem (DPBD) Directed graph G=(V,E) with weighted edges K source vertices s1,…, sk and a destination vertex t Goal:
Find k disjoint paths, one from each source si to t Each path delay is bounded by a value W
Page 9
Flow Based Channel Allocation (cont’)
DBPD is NP-complete Proof of the NP-completeness of DBPD
by reducing to MLBDP MLBDP problem: Maximum Length
Bounded Disjoint Path Problem
Find the greatest common denominator c for all the link weights Every link weight is rational number
Transform a single link to a chain Inserting I-1 node
Add a fake source
The bound is W*c +1
Page 10
Flow Based Channel Allocation (cont’)
Disjoint Path Search Algorithm Centralized algorithm
Phase I: Initial solution set searching To search an initial solution set with some disjoint paths The shortest path algorithm is used in this paper
Phase II: Augmentation algorithm Get as many disjoint paths as possible
Phase I can only give a fast searching solution set, but not complete enough Depth first searching Matching to the existence solution
Phase II is running iteratively. Every round of phase II will add one more new disjoint path to the solution set
Page 11
Phase II: Augmentation algorithm
Using DFS to search a path on the free vertex, which should be bounded. DFS keeps proceeding when there is a free neighbor and the path to the free neighbor is bounded
FD E ts CB
V(I)
Page 12
Phase II: Augmentation algorithm (cont’)
If a search path does not have free neighbor to meet requirement any more, a match between non-free neighbor is performed
FD E ts CB
V(I)
Page 13
Phase II: Augmentation algorithm (cont’)
If a match is found, it changes the existing solution set and a new search path established, and continue the DFS( in this example, from D)
Every node keep a match forbidden list
FD E ts CB
V(I)
Page 14
Phase II: Augmentation algorithm (cont’)
Current iteration ends with a search path reaches to t
FD E ts C
X
B
V(I)
Page 15
Phase II: Augmentation algorithm (cont’)
If X does not meet the requirement, there is no neighbor for D to choose to perform DFS or match, then search path go back to C to perform DFS or match
FD E
V(I)
ts C
X
B
V(I-1)
Page 16
Phase II: Augmentation algorithm (cont’)
If the search path go back to node s, which means the previous matching is an unsuccessful one, we should return to the search path before the previous matching
FD E
V(I)
ts CB
V(I-1)
X
Page 17
Phase II: Augmentation algorithm (cont’)
If there is no match of V(I), we backtrack to the search path of V(I-1) to find a match
FD E
V(I)
ts CB
V(I-1)
X
Page 18
Flow Based Channel Allocation (cont’)
Algorithm analysis of the augmentation algorithm: Time complexity: O(W’2|V||E|)
DFS: O(W’|E|) Matching algorithm O(W’2|V||E|)
W’ is the edge number boundary V – number of nodes E – number of edges
Extended DBPD problem More fault tolerant More energy efficient neighbor
to choose for forwarding
Page 19
Power-Efficient Real-Time Routing (RPAR)
Real-time forwarding velocityrequired(s, d) =dis(s, d)/slack velocityprovided(n, p, c) =(dis(s, d) − dis(n, d))/delay(n, p, c)
Neighborhood Management Power adaptation Neighborhood discovery, using Routing Request (RR) packet
Trade off between decrease the overhead and interference.
Page 20
Evaluation
Baseline design SIMPLE
A flow based distributed heuristic to find disjoint path Require initialization phase to establish path
Using explorer packet Multi-hop ack is used
Channel switching Guarantee disjoint path
Node-based scheme Every node has default listening channel Node need to switch channel for listening and transmitting RR packet is broadcasted on two channels
Real-time Power Aware Routing (RPAR) Single channel protocol
Page 21
Evaluation (cont’)
Simulation setup Ns-2 simulation, based on the characteristic of Mica2 sensor mote Probabilistic radio model from USC is implemented 130 nodes in a 150x150m2 square scenario, divided into 130 grid
Main evaluation metric Deadline miss ratio Energy consumption per data packet
To see in order to successfully finish a work load within a deadline, how many energy does it require
Page 22
Evaluation (cont’) Performance with different deadlines
MCRT outperforms others on different deadlines
Performance with different packet rate MCRT shows low miss ratio and energy consumption
Page 23
Evaluation (cont’) Performance with different number of flows
MCRT is not impacted significantly by number of flows
Performance for different network density MCRT is not sensitive to density
Page 24
Conclusion
The proposed MCRT protocol can Effectively utilizing the multichannel based on flow traffic pattern Greatly reduce the deadline miss ratio Outperform a state-of-art real-time protocol
Page 25
Critique
Should find a way to transform the DBPD bound to a real-time delay bound, which makes more sense.
The baseline SIMPLE performs similar to the MCRT protocol
With small network, the MCRT could only support few network flows.
Page 26
Second Paper
RACNet: Fine-Grained and Large-Scale Data Center Sensing
By Chieh-Jan Mike Liang, Jie Liu, Liqian Luo, Andreas Terzis
Johns Hopkins University, Microsoft Research
Page 27
Data Center Power Consumption
61 billion kWh energy consumption is consumed by data center in US alone in 2006 Enough to power up 5.8 million average households Estimated to be double in 2001
Power consumption components: IT equipment Computer Room Air Conditioning (CRAC) Water chillers (de-)humidifiers
Power Usage Effectiveness (PUE) Ratio of the total facility power consumption over IT equipment
2 is good, but some could be as high as 3.5 The reason of high PUE
Lack of visibility of the data center’s operating conditions Limited means to diagnose and handle the situation
Page 28
Cooling Management in Data Center
Cold-aisle-hot-aisle cooling design
Usual means to manage the data center cooling system Computational Fluid Dynamics (CFD)
simulations Cool the whole room
Page 29
Solution
Dense and real-time environmental monitoring system Troubleshoot thermo-alarms Help decisions on rack lay out and server deployment Innovate on facility management
Wireless sensor network Advantage
Low-cost Non-intrusive Wide coverage No need to change infrastructure
Challenge and requirement Density is high: high packet collision possibility Real-time data collection
Page 30
RACNet
Large-scale sensor network for fine-grained data center monitoring Part of the project called Data Center Genome (DC Genome).
Understand the energy consumption Optimize the control datacenter resources
Planning to deploy 2000 sensors
Reliable Data Collection Protocol (rDCP) Customized sensor hardware: Genomotes Uses multiple wireless channels: 802.15.4 have 16 channels In-network bi-directional collection tree
Page 31
RACNet Architecture DC Genome system:
The fewer gateways, the better Multiple base-station mounts on
the gateway, periodically pull data from master mote (see below)
Genomtes: customized mote Masters and slaves
Master at the top of a rack Master has 1MB flash Memory,
rechargeable battery, radio, humidity sensor
Slaves has 2 serial ports forming a chain Master use polling protocol to get data
from slave, and store in the RAM Master/slave approach decreases the
collision, facilitates the deployment ofserver rack
Page 32
Reliable Data Collection Protocol (rDCP)
Placing routing and data retrieval operations: Distributed ways Centralized ways
rDCP employs a hybrid way Genomotes cooperatively determine touting topology
Topology Control Layer (TCL) Gateways initiate data downloads
Data Download Layer (DDL)
Page 33
Topology control for rDCP
BiTree construction Tree topology network with bi-directional link, supporting point-to-point
communication Gateway broadcasting HEARTBEAT message Genomote receiving the HEARTBEAT, compete to join the tree by
JOIN_REQ, parent will grant joint by JOIN_GRANT Children list is added in the HEARTBEAT Two way hand shake process
After join tree, generate their own HEARTBEAT message
Page 34
Topology control for rDCP (cont’)
Parent selection requirement Potential parent does not have maximum children
number Path quality to the gate way:
Expected total transmission count (ETTC)
ETTCi is included in the HEARTBEAT message for recursively calculation
HEARTBEAT is periodically sent out from gatewayServe as a node live signal
If time out, abandon parent or childrenLocal TDMA is used
A time slot T is given for all one node childrenith child use time slot Remaining slot is used by tree construction
Page 35
Topology control for rDCP (cont’)
Channel assignment (tree establishing) High density reduce the throughput
Multiple gateways Utilize channel diversity to build bitrees on different frequency
Every base station node has a fixed channel Non-basestation node start scanning channels sequentially
Wait two intervals of HEARTBEAT time on each channel After scanning, switch to the optimal parent’s channel Delete this child in other channel
Page 36
Topology control for rDCP (cont’)
BiTree balance Unbalanced tree lead to long overall time of collecting all the data
Tree balance choosing requirement : Longest total data collecting time Must exceed the average collecting time to a threshold
The only tree to do balance meets
Switching probability to channel i If channel i tree’s collecting time is longer than average, the probability to switch
to channel i is 0 Otherwise, the less time channel i use, the highest probability to switch to it
If cannot find parent in channel i, switch back The switch decision is transmitted through START_BAL message
Page 37
Data Download
Centralized, pull-based approach from gateway Upload approach will course collision Gateway sequentially poll each node for data
Downstream Route Construction Every node only knows the parent and children Gateway merge children list
Data reliability and integrity CRC (Cyclic Redundancy Check) for integrity End to end ack used for reliability
Data time stamping Time stamping on HEARTBEAT Gateway provide global timestamp Each node provide local timestamp
Page 38
Evaluation
Tree settling time evaluation 100 nodes (10x10) is simulated in a
100x100ft networks
Data collection evaluation Real Test Bed HEARTBEAT interval (s)
Page 39
Evaluation (cont’)
Application level evaluation: latency and data loss Network Density (simulation)
Data latency (test bed)
Page 40
Real Data Center Deployment
100 masters real deployments
Page 41
Real Data Center Deployment (cont’)
174 masters real deployment Channel balancing
Multichannel impact
Page 42
Conclusion
RACNet is the first attempt to provide fine-grained and real-time visibility into data center cooling system
Compared with CTP, rDCP is more reliable and flexible
RACNet can provide a holistic understanding of key operation and performance parameters of the data center energy saving based on the effective data
Page 43
Critique
The pulling approach of data collection may decrease the collision, but will trade the time, especially when network is dense
The time stamping is important for latency calculation. But the scheme proposed in the paper require both global timing and local timing, which is complicate
From the experiment, the tree balancing takes too long time. It need a fast balancing approach to improve
Page 44
Comparison
MCRT RACNet
Traffic Pattern Flow traffic Tree based
Multi channel protocol
Yes Yes
Data collection approach
Push approach Pull approach
Metric for realtime Transmission count
Transmission count
Channel Assignment
Centralized Distributed
Real test bed No Yes
Page 45
Q&A