1. An Asynchronous Message Delivery Service for iGaDs (intelligent Guards against Disasters) esIoT-2013 Taichung,Taiwan July 3-5th 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

2. Outline Scenarios Standards and technologies for disaster preparedness and response iGaDs (intelligent Guards against Disasters) Messages delivery service and platform Opportunities and future work 2

3. Imagine that… Earthquake 7.0 3

4. 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: … … A Future Scenario

5. 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

6. Standard-Based Alert Delivery Integrated Public Alert and Warning System Authenticated message senders http://www.fema.gov/emergency/ipaws/ipaws_cap_mg.pdf

7. Pushing Alert Messages Happening now:  Guide for CAP-EAS implementation published by EAS industry  Weekly testing since December 2011 CMAS 7

8. iGad CAP-aware entry access controller iGaD CAP-aware elevator controller CAP-aware building management system iGaDs in Smart Homes and Buildings (AlertType == Earthquake) AND (Magnitude>= 7.3) OR (AlertType == Tornado) AND (Severity >= 4) (AlertType == Earthquake) AND (Magnitude >= 7.3) OR (AlertType == Tornado) AND (Severity >= 3) AND (OutsideAirPressure * THRESHOLD_RATIO < InsideAirPressure) 8

9. iGaD demo prototypes CAP Message Processor Alert type & information Alert records Affected areas Alert message buffer Modem Signature validation XML parser Location filter Device Controller Device interfaces Configuration files Device location Resources Local data Rule processor Rule engine Activation parameters and rules [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, IEEE UIC-ATC 2012 9

10. Authorized alert sender PuSH iGaD PuSH Broadcast pathways iGaDs and Qpid To diverse devices: Gas regulator, door or windows controller…… IP Network ?xmlns version = “1.0” <alert xmlns = … … Earthquake Immediate Strong … Magnitude 7.3 … CAP message Message processor Action activation rule evaluation Device interface iGaD PuSH

11. 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). 11 PuSH Message Hub Publisher Subscribe Alert Information Subscribe Alert Information Subscriber Announce new alert Announce new alert Ping Fetch data Data Notifications Push notification subscribers Push notification subscribers Update!

12. 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. 12 Exchange Queues Bindings Decreasing Priority Priority queues Earth -quake Debris Flow Tsunami Messages with routing key

13. PQ Node Exchange Priority Queues Decreasing Priority Bindings Down stream data Cached data Data Bridge Hub PubSubHubbub Messages to other Qpids Up stream data Notification to local subscribers Requests from publishers Messages from other Qpids 13

14. PQ Node – Down stream Exchange Priority Queues Decreasing Priority data Bindings Data Update Monitor (DUM) Data Transfer Service (DTS) Data Bridge Hub PubSubHubbub Requests from publishers Low High Route to other Qpids Notifications to local subscribers Work item (Earthquake) Data 14 Call DataBridgeNotifyDataUpdate( Topic,RelativeDeadline,...); Highest Priority

15. PQ Node – Up stream Priority Queues Decreasing Priority Incoming Data Monitor (IDM) Data Retrieval Service (DRS) Data Bridge Hub PubSubHubbub Messages from other Qpids Exchange Bindings Route to other Qpids Notifications to local subscribers High Low Data Work item Data 15 Register long polls Cached Data

16. 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

17. Thank you very much! This work is supported by the Academia Sinica, Republic of China (Taiwan) Open Information Systems for Disaster Management project.

18. 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

19. 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