Introducing the Sahana CAP-enabled Messaging Broker to ITU-D Asia Pacific Community

-->

The International Telecommunications Union - Disaster (ITU-D) conducted workshop in Thailand, introduced the utility of the Common Alerting Protocol (CAP) standard, to the delegates, through a the Sahana CAP-enabled software and a series of hands-on exercises. The CAP ease-of-use and utility were appreciated by those delegates. Participants experienced the efficiency gains of the single entry of a message being simultaneously disseminated through multiple technologies to multiple recipients, acknowledged the CAP message consistency removing ambiguity that may, otherwise, lead to false responses, and realized the capabilities of brokering multi-agency publishers and subscribers for improved situational-awareness^.
 

ITU-D hosted a session on the topic: “Introduction to Operationalizing the Common Alerting Protocol” at the workshop: “Use of Telecommunications/ICT for Disaster Management¹”. This hands-on CAP session was resourceful in producing positive outcomes. Delegates had the opportunity to assess the capabilities of the standard using the CAP-enabled Sahana broker software.

Click to view the workshop report available on the web and the slide deck .

Evidence points to the growing need for a CAP-enabled ITU-D Module (CAP-ITUM). The CAP-ITUM would foster the wider-scale adoption of the the CAP standard and the policies it offers. The ITU branded module would advance the member states, lagging in implementing CAP, with facilitating multi-agency all-hazards all-media warning, alerting, and situational-awareness capabilities, to effectively coordinate hazard events. Since the first release of CAP in 2005, only a handful of member states: North America, Australia, and Germany have adopted the standard. Sri Lanka, an early adopter, has carried out several research projects involving the standard but has not progressed beyond with institutionalizing it at a National level. Other member states have failed to realize the full potential of CAP beyond simply accepting as an interoperable XML schema.

Interactive voice for a volunteer organization to manage disasters

Crowd sourcing emergency information with Interactive Voice:

"CERT members call one of the four telephone numbers to access Freedom Fone; then press the “reporting” menu item number on their phone keypad to record a “field observation report”. That report is received and stored in the Freedom Fone inbox as an audio file (MP3) at Sarvodaya’s Hazard Information Hub (essentially the data center belonging to the Sarvodaya Community Disaster Management Center). Trained HIH Operators (HIHO) listen to those local language spoken incident field observations, then transform them in to English language text to feed in to the Sahana Eden, Emergency Data Exchange Language Situational Reporting (SITREP) application."
click to read full story

Sahana HF data platform for alert and situation reports

On my way to the IDRC meeting in Penang I spent two days with Prof. Ahmad Zuri et al in Cyberjaya, Malaysia evaluating the Sahana Common Alerting Protocol (CAP) messaging over HF spectrum data platform. Prof. Zuri's team through, a grant from the Malaysia Communications and Multimedia Commission (MCMC) and the support from Mr. Zolkhonain Norizan and Mohd Aris Bernawi of MCMC, a prototype of the transport and application layers were developed by June 2009.

The lab setup was replicated at MCMC with two HF radios connected to two laptops through Pactor II modems; one acting as the remote client and the other as the IP-HF gateway transforming the HF data to the Internet. A third laptop was hosting Sahana on the LAMP stack. A CAP message sent through Sahana could is first received by the IP-HF gateway, which resolves the string and relays it to the remote station transported as HF data.

Other than a few flood incidences, Malaysia (MY) is perhaps one of the least disaster prone country in the Asia-Pacific. With that in mind, the idea is to setup a hub in MY to transport Sahana specific emergency information through the HF spectrum. As of now, Maldives, Malaysia, and Sri Lanka have agreed to pilot this system. We await hope a Pacific Island or New Zealand may join the consortium. Proposal is in the working to seek funding.

A short video demonstrating the concept

Now a member of Sahana Project Management Committee

The Sahana community included me as a Project Management Committee (PMC) member. My work with Sahana is in the early warning space with the development of the biosurveillance module and the messaging module.

The first Sahana conference took place in Colombo, Sri Lanka during the last week of March, 2009. I made two presentations (biosurveillance and common alerting protocol) and Prof. Samarajiva one (public warning), which stated our (LIRNEasia's) commitment to Sahana.

Sahana has divested from the original parent Lanka Software Foundation and has been incorporated as a foundation in the state of California, USA. Work is still in progress in establishing the foundation.

SMS Transport for GSoC 2009

It is my first time volunteering to mentor students for the Google Summer of Code 2009. The Sahana Free and Open Source Software community has been taking part in GSoC since 2007. This year Google has offered 10 slots to begin with; meaning 10 student will be provided summer funding to develop code for Sahana. There were 34 applicants with project ideas for Sahana.

One of my initial ideas had been to develop a SMS transport that mimics IP where data can be exchanged between a mobile client and a server (database). This is to address the problem faced by emergency coordinators in communicating field data to central levels and receiving information during the response stage of a crisis. Network congestion is a fact during the peak or initial stages of a crisis. Hence, voice channels are the first to shut down. Other means such as GPRS signals are not always up to par and in most cases would be weak in covering remote location that are in the periphery of the footprint of cellular towers. However, SMS that works on weak signal strength, a store-and-forward communication technology, even though may not send the information in real time, would eventually get the data across to the terminal devices.

Presently Sahana, a web browser application, reliant on Internet connectivity for data exchange, is developing a class of mobile phone and personal data assistant hand-held device applications to operate in the field. These hand-held devices are handy effective tools in data collection and reception. Although GPRS exists as means for providing connectivity, given the question on reliability, it is important that a redundant or alternate channel for transferring information is in place, if Sahana applications are to be effective across available communication network platforms.

The problem that this project promises to solve is to develop an SMS transport layer that can communicate with the Sahana applications during times of need. This proposal outlines the goals and design of the envisaged software object that will work as a general protocol to support all Sahana modules for networking with hand-held terminal device applications.

The Sahana community has definitely selected the student who has provided some original ideas and proven skills to develop the client and server side components. Some aspects that the developer must keep in mind are compressing the strings to minimze on SMS tariffs are multifold relative to GPRS, sequencing the SMS pages to ensure they are chained back at both server and client sides. Some thoughts such as use of binary XML has been suggested to structure the server calls or client requests and data exchange between the Sahana clients and Sahana servers.

I'm excited to mentor the student in developing this component as part of GSoC2009 for Sahana.

Common Alerting Protocol messages over Radio Data System

In several blogs I've mentioned my work in relation to Common Alerting Protocol (CAP) a standard that is being absorbed by emergency communicators for exchanging situational reports in relation to natural and man-made threats. Past month I was in Sri Lanka, predominantly, attending to field work on the real-time biosurveillance program, my current ongoing project, which is using CAP for issuing health alerts (situational reports) to health workers. During this visit I was invited by CEL Lanka to review their home brewed Radio Data System (RDS) for issuing text alerts over FM radio waves.

The RDS for alerting comprises a special FM radio developed by CEL Lanka that can receive text to display as well as turn on an audible siren according to a priority level, a larger LCD display to be assemble in public spots such as bus stations, road side, trains, etc, and a software module to communicate with the encoder for generating text messages in Sinhala, Tamil, and English languages. This project had been funded by the Information Communication Technology Agency of Sri Lanka (ICTA) under a small grant. CEL Lanka has produced 40 of the LCD units to be deployed in location around the Island.

I recommended that the system incorporate CAP for value addition; more so for being CAP compliant to receive a CAP message and automatically feed the required data to the RDS text element. This way the system can be easily plugged in to any existing Disaster Communication Software system without too many changes such as a P2P CAP Broker. Similar to SMS alerts or Email alerts one can include RDS as another medium for receiving alerts.

CEL Lanka is interested in enabling the system with CAP. We will include the RDS as a plug in to the Sahana Messaging Module. Another similar project is the inclusion of a gateway to send and receive text over HF Radios being developed by Universiti Teknologi Malaysia (UTM). Respere Lanka developed the SMS/Email engine for issuing text alerts. Respere will come in as a partner to develop the web browser based GUI to trigger CAP alerts to be transported through the RDS.

Similar to SMS, RDS also has limitations on the number of characters that each packet can carry. Concatenation of packets pose the same problem as SMS pages; where packets/pages not arrive in the same sequence they are sent. These are some of the few challenges that lie ahead in delivering this component. Over the next few weeks I will be working on the software architecture and the CAP profile for including the RDS in to the Sahana Messaging Module. We intend to apply for a small grant to produce the remaining components.