## 3 Active Disaster Response System (ADRS)
### Active Disaster Response System
#### 3.3.1 CAP Message Parser and Actuators  
In addition to our simulated emergency broadcast system, ADRS registers for the CAP messages provided by the Emergency Digital Information Service (EDIS), the National Science and Technology Center for Disaster Reduction (NCDR) [26] and the Integrated Public Alert and Warning System (IPAWS). As shown in Figure 4, there are two ways to get warning messages. One is from RSS feeds, and the other is from email. IPAWS of NCDR sends XML-based CAP messages by email or RSS to registered receivers.  
Figure 5 shows the major four parts in a Common Alerting Protocol message. They are alert, info, resource and area. The CAP parser extracts important information from a message, respectively.  
Figure 3: Deliver messages via PubNub. (**a**) PubNub broadcast; (**b**) PubNub receiver.  
Figure 2: Deliver messages via PubNub.  
First, the CAP parser extracts message ID (Identification), sender ID, sent data, and so on, from the alert part. Second, the CAP parser extracts event category, event type, urgency, and severity and so on from the info part. Third, the description is extracted from the resource part. Finally, the CAP parser extracts area description from the part of area. The Common Alerting Protocol Validator (CAPV) [27] is used to validate the correctness of our CAP parser.  
Figure 6 shows the flow of parsing CAP message and controlling associated devices. After parsing a CAP alert message warning of an imminent earthquake, ADRS obtains earthquake information, including urgency, severity, magnitude, depth, _etc_. According to the standard operating procedure (SOP) for earthquakes, in order to reduce potential dangers, people who are inside a building should open doors and windows, cut off gas and turn off light and power before evacuating to a safe place [28,29]. Therefore, we designed ADRS to automatically perform these tasks, so as to help people to evacuate faster and to keep their belongings from being damaged.  
Figure 4: CAP messages published by an early warning system (EWS). EDIS, Emergency Digital Information Service.  
Figure 5: Common alerting protocol architecture.  
ADRS needs to be able to verify that a CAP message it receives was issued by an authorized source. As CAP is an XML-based format, existing XML security mechanisms can be used to secure and authenticate the content of a CAP message. The commonly used security mechanism is described as follows. First, the receiver has to ensure that the CAP message was delivered from a trustworthy entity, such as a trusted SIP (Session Initiation Protocol) proxy, and that the communication channel between the receiver and the SIP proxy is properly secured. Second, the sender of the CAP message should be on the whitelist. Finally, the message should be protected by a digital signature, and the entity signing the CAP message should also be listed on the whitelist. If none of these verification checks indicates a known sender, the CAP message should be treated as malicious and suspicious. As mentioned in Section 3.2, we used PubNub real-time push service to push CAP messages to receivers. We first registered a PubNub account to get a subscribe key and a publish key. We then used the two keys to establish a secure channel between the sender and the receiver.