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.

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.