Transcript 2013 esIoT - Yi

An Asynchronous Message Delivery
Service for iGaDs
(intelligent Guards against Disasters)
Yi-Zong Ou
Institute of Information Science
Academia Sinica, R.O.C (Taiwan)
C. M. Huang, C. T. Hu, E. T. H. Chu, C. S. Shih, J. W. S. Liu
esIoT-2013 Taichung,Taiwan July 3-5th
Imagine that…
Earthquake 7.0
3
A Future Scenario
Alert xmlns: …
Sender: Central Weather Bureau
Status: Actual
MsgType: Alert
Scope: Public
Info
Category: Geo
Event: Earthquake
Urgency: Immediate
Severity: Strong
Certainty: Observed
Description: A strong earthquake
measuring 7.3 occurred in …
Parameters: Magnitude, depth, …
Areas: Polygons specifying
affected areas
Resources: … …
Common Alert Protocol
ITU-T Recommendation X 1303 (07/2007)
A common format that supports
 Broadcast of messages of all
types to all public alert systems
 Message exchange between
emergency information systems
 Aggregation and correlation of
warnings from multiple sources
 End-to-end authentication and
validation
 Automatic reports by sensor
systems to analysis centers
 Automatic processing by smart
devices and applications
Standard-Based Alert Delivery
Authenticated
message
senders
Integrated Public Alert and Warning System
http://www.fema.gov/emergency/ipaws/ipaws_cap_mg.pdf
Pushing Alert Messages
CMAS
CMAS
Happening now:
 Guide for CAP-EAS
implementation published
by EAS industry
 Weekly testing since
December 2011
CMAS
7
iGaDs in Smart Homes
and Buildings
iGad
(AlertType == Earthquake) AND (Magnitude >= 7.3)
OR
iGaD AND (Severity >= 3) AND
(AlertType == Tornado)
(OutsideAirPressure * THRESHOLD_RATIO < InsideAirPressure)
CAP-aware
elevator controller
CAP-aware
entry access
controller
CAP-aware building
management system
(AlertType == Earthquake) AND (Magnitude>= 7.3) OR
(AlertType == Tornado) AND (Severity >= 4)
8
iGaD demo prototypes
Modem
Alert
message
buffer
Signature
validation
XML
parser
CAP Message Processor
Affected
areas
Location
filter
Device
location
Alert type &
information
Resources
Alert
records
Rule processor
Activation
parameters
and rules
Rule engine
Local data
Device interfaces
Configuration
files
Device
Controller
[1] Cyber-physical elements of
enhanced disaster prepared
smart environment,” by Liu, Chu
and Shih, IEEE Computer
[2] Ubiquitous smart devices and
applications for disaster
preparedness,” by Liao, et al,
9
IEEE UIC-ATC 2012
iGaDs and Qpid
CAP message
Authorized alert sender
Broadcast pathways
?xmlns version = “1.0”
<alert xmlns = …
…
<event>Earthquake</event>
<urgency>Immediate</urgency>
<severity>Strong</severity>
…
<parameter>
<valueName>Magnitude
</valueName>
<value>7.3</value>
</parameter>
…
PuSH
PuSH
IP
Network
Message processor
iGaD
Action activation rule evaluation
Device interface
iGaD
PuSH
To diverse devices:
Gas regulator,
door or windows controller……
iGaD
PubSubHubbub (PuSH)


A server-to-server web-hook-based Pub/Sub
protocol as an extension to Atom and RSS
(topic: feed URL).
The subscriber subscribes to the Topic URL
from the Topic URL's declared Hub(s).
Publisher
Announce
new alert
Ping
Data
Push
Subscribe
notification
Alert
PuSH
subscribers
Information
Message Hub
Fetch
data
Subscriber
Notifications
Update!
11
Qpid



Apache Qpid™ is a cross-platform Enterprise
Messaging system which implements the
Advanced Message Queuing Protocol (AMQP)
Reliable delivery service
Feasible use to restore network during disaster.
Messages with
routing key
Exchange
Bindings
Queues
Priority queues
Decreasing Priority
Earth
-quake
Debris Tsunami
Flow
12
PQ Node
Notification
to local
subscribers
Hub
Requests from
publishers
PubSubHubbub
Data
Bridge
Down stream data
Up stream data
Cached
data
Messages from
other Qpids
Exchange
Priority
Queues
Messages to
other Qpids
Bindings
Decreasing Priority
13
PQ Node – Down stream
Requests from
publishers
Notifications to
local subscribers
Hub
Data
PubSubHubbub
Data Update
Monitor (DUM)
Work item
(Earthquake)
Call
DataBridgeNotifyDataUpdate( Highest
Topic,RelativeDeadline, ...);
Priority
Data Transfer
Service (DTS)
Data Bridge
data
Data
Exchange
High
Priority
Queues
Low
Bindings
Route to other
Qpids
Decreasing Priority
14
PQ Node – Up stream
Notifications to
local subscribers
Hub
PubSubHubbub
Data Retrieval
Service (DRS)
Work
item
Messages from
other Qpids
Data
Priority
Queues
Cached
Data
High
Incoming Data
Monitor (IDM)
Register
long pollsLow
Data
Bridge
Route to other
Exchange Qpids
Bindings
Decreasing Priority
15
Summary and Future work
Our work provides:


Asynchronous prioritized messaging delivery
service
Web-based Publish/Subscribe alert messages to
iGaDs via Internet
We will investigate:


How responsive a network of nodes built from
PuSH, data bridge and Qpid?
How system resources of each node are
allocated to tasks that move data within the
node?
16
Thank you very much!
This work is supported by the Academia Sinica, Republic of China (Taiwan)
Open Information Systems for Disaster Management project.
Why PuSH on Qpid?


Pub/Sub for Qpid needs subscribers
to stay connection (session) with the
Qpid broker. If the connection
terminated, there is no way that Qpid
can push notification to Subscribers
PuSH can push notification via
callback URL. Subscriber does not
need to stay connection with hub.
18
Why design priority queues in data bridge ?



There is no priority among queues in a
Qpid broker. Prioritized messages only
exist in single queue.
Retrieve messages from a priority queue
is only ordered by priority. Impossible to
change the algorithm (ex: 5high, 3low
avoid starvation) to retrieve messages.
No prioritized message delivery between
two brokers. Hence, we design to send
messages in the order of priority before
entering a Qpid broker.
19