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.

Short Messaging and Common Alerting Protocol over HF Spectrum

Amateur radio operators have played a major role during disasters in providing front line communication when all other technologies have seized to operate. MARTS - Malaysia Amateur Radio Transmitter's Society was in full force sharing their experiences and demonstrating the equipment at the ITU Asia-Pacific Centers of Excellence Training Workshop on Effective Use of Telecommunication/ICT in response to disasters: saving lives. The equipment range from vehicle mounted, hand helds, and nomadic units that work over UHF/VHF/HF frequencies. I had the privilege of presenting the Common Alerting Protocol experience in Sri Lanka to the government delegates from Asia and the Pacific Islands; CAP was unheard of by the delegates.

Another novel project on the use of HF spectrum for communicating short messages (or chat messages) was presented by Prof. Dr. Ahmad Zuri bin Sha'ameri at the same ITU event. It was definitely a product that could be engulfed in to the Sahana suite of Messaging gateways or part of the P2P CAP Broker. Both him and I got off to a good start on agreeing to proceed with the experimental idea of porting his solution on to Sahana. An initial document of the concept and action plan was exchanged within a few days of us returning to our desks.

Most of the officials attending the ITU event were officials from their respective telecom regulatory bodies working on disaster management. They were quite excited of the project we have put on the table and promised to educate their ministers of the possibility of piloting the HF spectrum text messaging modules for emergency communication in their countries.

The first step is to develop the software and prove the concept in Malaysia and/or Sri Lanka. This portion of the project is being funded by the Malaysia Communication and Multimedia Commission. Second step is to write a larger proposal to pilot the working solution in Sri Lanka, Malaysia, and few of the Pacific Islands - Nauru, Marshal Islands, Vanuatu, etc.

Optimally transporting XML through SMS for CAP Messages - How can it be done?

While working on my presentation titled "Common Alerting Protocol" (CAP) for the ITU Workshop in Kedha, Malaysia and experimenting with the Sahana Messaging/Alerting Module in preperation for a demo for the workshop participants, I questioned, "is there a method already in place or how does one optimally send an XML file through the SMS transport. Of cause this is in relation to transporting a CAP message with the underlying XML data storage and transfer standard through the SMS transport technology.

One would say, "why bother with SMS just transport it through GPRS or any other advanced mobile data service platform transport layer. There are advantages that SMS offers and GPRS does not; a key advantage being SMS is always ready to receive messages (i.e. data can be pushed on to) provided the handset is turned on; where as GPRS must be user initiated where the data must be pulled. For the purpose of "alerting" SMS surpasses GPRS with the mentioned advantage. It is also possible to house a an applet that resides on the handset and uses GPRS to periodically fetch newly posted WAP alerts.


Obviousely all one needs to do is insert the XML formatted text including the tags, header, etc in an SMS text and send it to whomever they want. The dilemma is in the payload. The XML formated text in the image above has 520 characters with white space and 421 characters without white space. The 520 characters would fit in to four 8-bit encoded SMS pages. Cost of an SMS is proportional to the number of SMS pages; unlike GPRS which is billed by the number of bytes (or kilobytes). More so, the intent of CAP being mass alerting efficiency is compromized with the size of the payload. Hence the key question is "how do we minimize the payload of a CAP message transported througg SMS to maximize the efficiency and the effectiveness?"

For a targeted application such as one that would display a CAP message could be designed to include only the necessary and sufficient (tags), which are yet to be determined by experts and remain an open problem. Let us assume the CAP SMS text carries the <incident>, <scope>, <status>, <msgType>, <category>, <event>, <urgency>, <severity>, <certainty>, <areaDesc>, and <resourceDesc> tags. The mobile phone application would be designed to read these tags and display on an interactive mobile phone GUI. The GUI would give the recipient the option to change the predefined values such as the <msgType> from the received value of "Alert" to "Ack" and reply to the sender. Assuming the alert was issued through a software such as the Sahana Messaging Module, which has a feature to store replies and produce a consolidated report, sender could match those who had received and acknowledged the alert.

I anticipate the need to transfer XML files on to mobile phones will become a must with standardization and interoperability. The revers or the dual exists; thus XML encoding for SMS. Any one interested can find technical literature on IBM's developer works Tips.

Healthcare Worker based mobile Sensor Systems

The aim of the real time biosurveillance program is to mobilize Healthcare Workers in the rural settings with mobile phones to record and submit patient counts for the purpose of consolidating national health data for surveillance of unusual patterns (headsup). Problem that this real-time biosurveillance program (RTBP) promises to solve is to strengthen existing disease surveillance and detection communication systems, reduce latencies in detecting and communicating disease information, and set a stand interoperable protocol for sharing disease information with national and international health-related organizations in the region.

My role in the RTBP is working in the capacity of a Researcher and Project Director. The grant has been approved by IDRC but the administrative work remains to be completed before funds can be transfered and work can begin

RTBP shares many similarities with the small study working in (somewhat) rural Tanzania focus on guiding health care workers through medical algorithms, with the primary goal of improving care and the secondary goal of collecting data. In particular, it is automated with the IMCI protocols for classifying and treating childhood illness. If you are interested, an online paper titled "e-IMCI: Improving Pediatric Health Care in Low-Income Countries" describes the project and lessons learned.

The design of RTBP using mobile phones is in par with this abstract from the IEEE Internet Computing article titled - The Rise of People-Centric Sensing - "Technological advances in sensing, computation, storage, and communications will turn the near-ubiquitous mobile phone into a global mobile sensing device. People-centric sensing will help drive this trend by enabling a different way to sense, learn, visualize, and share information about ourselves, friends, communities, the way we live, and the world we live in. It juxtaposes the traditional view of mesh sensor networks with one in which people, carrying mobile devices, enable opportunistic sensing coverage. In the MetroSense Project's vision of people-centric sensing, users are the key architectural system component, enabling a host of new application areas such as personal, public, and social sensing."

P2P CAP Broker for Communicating Cyclones/Hurricanes

A proposal was submitted for an NSF grant on Communicating Hurricane Warnings. This a two country research collaboration between the iSchool @ UMD and LSF @ UCSC. I will work with LSF as a Principle Investigator in the capacity of an OR Analyst/Project Manager in managing and conducting the Sri Lankan research component. Dave Yates from the iSchool will conduct the parallel research in USA.

The research will develop a Peer-to-Peer Common Alerting Protocol (CAP) Broker for exchanging hurricane/cyclone information with stakeholders such as the Met dept, Broadcasters, First-Responders, Citizens, and other associates. The P2P CAP Broker will be a FOSS application amalgamated in to the Sahana suite of Disaster Management software modules. The intent of the P2P CAP Broker is to provide a plat form for stakeholders to network in the same way as a "social network" to exchange cyclone/hurricane information before, during, and after an incident.

A major component will be testing the CAP interoperability structure for communicating information in multiple languages; Sinhala/Tamil in Sri Lanka and English/Spanish in USA. The software will be accessible via mobile handhelds and laptop/desktop computers via the internet. The alerting component will work on SMS too. The National Weather Bureau (Met dept) could issue alerts to first-responders downstream and receive acknowledgments from alert recipients up stream. Users who are part of the network could also send situational reports upstream to the central authorities. The figure above shows the schematics of the proposed system.

The P2P CAP Broker was a recommendation made in the HazInfo research technical report. As we had encountered in the real life experiences as well as in the HazInfo research, it is usually the people and protocols that fail and not the technologies. Therefore, the proposed research of evaluating the P2P exchange of cyclone/hurricane information intends to measure the uncertainties caused due to technological and organizational complexities of this system through evidential analysis.

If the grant is approved work should begin in January 2009 and end in 2011. The first year will be dedicated to research and development of the ICT system and the second year for evaluation through mock-drills and the use during the cyclone/hurricane seasons in Sri Lanka and USA.

Fano Matroid is Spot-on

In this blog I give reasons for choosing a rendition of the fano matroid as the logo for Spot-on Solution, as shown in this image.

The fano matroid is named after Gino Fano, a mathematician who devoted his life to projective and algebraic geometry. The fano matroid is also referred to as the fano plane, projective geometry P(2,2), steiner tipple system S(2,3,7).

During my foundation in operations research at the University of Montana, I was introduced to all three of the notions associated with the algebraic structure comprising 7 vertices and seven edges. When a cube with 8 vertices and 8 edges (3 dimensional object) is projected on to a plane (2 dimensional space) it produces the fano plane. In block design theory the steiner triple system S(2,3,7) when represented as a graph, resembles the fano plane. In matroid theory the fano matroid plays a significant role as what is termed as an excluded minor in differentiating properties of certain classes of matroids.

My masters thesis was on defining the notion of circuit double covers for matroids and developing a few algorithms to create matroids with circuit double covers in several classes of matroids such as the uniform matroid, graphic matroids, ternary matroids, binary matroid, etc. The notion of circuit double covers had already been established for graphs in graphs theory by Seymour and Szekeres, in 1970. This conjecture, the cycle double covers for graphs, remains an open problem to this day. I first came across the notion of cycle double covers of graphs when attending the 1998 Bigsky conference on Discrete Mathematics, hosted by the University of Montana Mathematics Department. My adviser, Prof. Jenny McNulty, handed me the challenge of understanding circuit double covers of matroids, which was a pioneering topic. That's when I fell in love with the fano matroid, which is now my favorite abstract structure, where 23 is my favorite number.

With this I have chosen a rendition of the fano matroid as my Spot On Solution's logo. As seen in the image above, the warped version is due to many reasons. Given that my current focus on systems, specifically, Information Communication Systems (ICT), the idea of stability is a major criteria that all those who deal with systems hard to establish. Although perfection cannot be achieved, designers of systems, strive to achieve, at least, an asymptotic or near perfection, of stability. The lines (or edges of the fano matroid) in the logo resemble the transient and steady state response of a system arriving at some asymptotic stability (looking like an exponential function). Moreover, no matter at which "state" (vertex on the fano matroid) one starts it is possible to traverse to any other point with one hop (passing through one vertex).

In ICT redundancy is a word that is commonly used as well as an action that is commonly practiced. A double covering in graph theory or matroid theory is synonymous with redundancy. Remarkably the fano matroid is beyond a double covering and is a triple covering per say; where each node has 3 edges descending upon it. With respect to ICT we can think of it as each node is connected to 3 independent channels or links; thus disruption of one link does not effect the operation of any of the nodes; as a matter of fact each node can afford to lose 2 links and still be able to communicate with the other nodes.

Credit has to be given to Absoulte Einsteins for creating the first cut of the logo and Dacia Closson, my friend with exceptional graphic and web design capabilities, for completing the logo.