Leveraging the mobile phone

There are huge opportunities to leverage the mobile phone to communicate with your user base. The mobile phone is one of the few devices where you can push a message to your users in real time. Unlike a website or instant messaging application where the user needs to be logged on or email where the user needs first read their email, with a SMS or WAP push message the user can be contacted immediately.
There are many opportunities to leverage the mobile phone for marketing, notifying or prompting users. For instance there are a number of banks like First National Bank's inContact and MTN Banking that send out SMS alerts whenever money is paid from or to your bank account. There are a huge number of companies using SMS messages for marketing messages. There are a number of other uses particularly for two factor authentication like sending an SMS message with a one time pin (OTP) that is entered onto a website during the login process. This proves the user has the mobile phone in addition to knowing the username and password.
With all this added ability comes the inevitable risks. Too many marketing messages will annoy the user. It is therefore essential that the user always has an opt out option. There is also the added risk that the SMS can be spoofed. For instance an SMS can be sent to a user with a WAP link asking them to go to log onto your website, but the link points to a phishing site. This might enable somebody to get hold of a user's password.
So the bottom line is that 'yes' it is a great opportunity to contact your user base, but speak to some consultants who have a strong knowledge about this space before you do so, because there are a lot of pitfalls.

How a SIM browser works

A SIM browser is basically a lightweight browser loaded onto a mobile phones SIM card. It basically renders a form of xml on the phone and allows for communication to a SIM browser gateway. There are to leading suppliers of SIM browser platforms. Gemalto with their S@T Platform and Smarttrust with their WIG platform. Both of these platforms working in a similar way although the format of the xml differs.

The xml is either loaded onto and stored on the SIM card or it can be dynamically downloaded on request. The nice thing about the way the xml is rendered is that it is rendered at the SIM level so it communicates to the mobile phone itself through the same protocol that is used for the other phone specific features. What this means is that the menus and prompts are consistent which the other menus and prompts on the phone.

Communication to the gateway is via SMS, but the SIM browser controls the communication. In the xml an http url is configured and the SIM browser packs this request up into SMS messages and sends them to the gateway. The gateway then unpacks the SMS messages and forwards it onto the application server. The application server would then respond with some xml, which is converted to byte code and packed into SMS messages on the gateway. These SMS messages and then sent to the phone where the SIM browser unpacks the SMS messages and renders the response to the user.

Since the SIM browser runs on the SIM card it has access to the 3DES security plugins on the SIM card and can encrypt data such as passwords or perform generate MAC values to check message integrity. A Security server can also be used on the gateway to perform password translations before passing the password into another security zone.

SMS message lengths

One of the critical issues with writing a system that interacts with users using SMS messages is the cost of the SMS messages. This cost needs to be accommodated in the business plan as it has a major ongoing cost. Since SMS messages are normally 160 bytes for a single message and 140 bytes for concatenated messages it is critical to ensure that you message fits into the fewest number of messages. You do not want your message to span 2 SMS messages because it is one byte too long.
SMS messages use a 7-bit alphabet and the majority of characters fit into one byte. There are as always exceptions such as the euro symbol or a square bracket. This alphabet is specified in the GSM 03.38 specification.
Have a look at http://www.dreamfabric.com/sms/default_alphabet.html to see the full alphabet.

Processing incoming requests

Let us look at processing incoming request from different mobile applications. Depending on the channel the request might be asynchronous or synchronous, by this I mean the response is is sent using a different connection to the request vs the response being sent on the same connection of the request.
An example of an asynchronous channel would be SMS. The mobile phone sends a SMS to the server via the mobile network operator's infrastructure, the server process the request and then establishes a connection to the mobile network operator to send out the reply SMS. The incoming and out going SMS are not tied together in any way other than by the data they contain.
An example of a synchronous channel would be HTTP over GRPS. Here a connection is opened, the HTTP request data is sent to the server, the server processes the request and sends the response data down the connection and the connection is closed.
For asynchronous communication your application will require a level of internat thread management. This is difficult to achieve using many web scripting languages such as php whereas for synchronous communication you can get away with a web scripting language. To build an application that supports both types of communication requires a lot of thread management and synchronization techniques.

Security for mobile applications

Security capabilities differ considerably depending on the channel used. By channel I mean the technology used for the user interface and the communication mechanism to the back-end application. Some channels allow for no encryption at all and are deemed to be very insecure. A standard text SMS would be such a channel. The text cannot be encrypted so entering a password in an SMS is not a good idea. SMS messages use a store and forward protocol and thus can be intercepted and changed. In addition to this they are left in the 'Sent Messages' list on the users phone. More secure channels such as the SIM Browser solution from Gemalto and Smarttrust allow for data encryption within the SIM card of a GSM mobile phone. The encryption normally used 3DES and a secure key resident on the SIM card. This channel will be extremely secure as the encryption is performed within hardware components. For the MTN Banking run by the MTN mobile operator a Mastercard PIN is entered on the mobile phone.

Off-deck applications

On mobile devices off-deck applications are much easier to deploy since deployment of on-deck applications can be difficult for the average user. Off-deck applications include SMS, USSD, IVR, WAP, HTML etc. The way this type of application works it the the user submits a request by dialing a phone number, submitting a url from the phone browser or sending an SMS. The server on receiving this request guides the user through the application using menus and prompts for input.
In general off-deck applications are easy to use, but require more bandwidth and this could be expensive. It is critical to look at the cost of communication when building this type of application. The Fundamo mobile banking and payment system supports a wide range of channels and each of these have been tuned to reduce the bandwidth of the communication.
I will look at each channel in more detail in later posts and explain how they work and communicate to the server, but in my next blog I will look at the security aspect of the communication. Security is crucial for m-commerce, m-payments and m-banking systems.