Home : Support : Documentation : Jack's Hacks : Archive : August 2004
 

August 2004

 

We've talked in great detail about what MMS is and how it works (see the MMS SDK Quick Start Guide and the archives for December 2003 and January 2004), and what WAP Push is and how it works (see the Read WAP Push Quick Start Guide and the archives for February 2002 , March 2002, and May 2002), so this month we're going to take a closer look at the differences and similarities in these two messaging mechanisms, and how they compare with SMS. We'll take both a high level functional look as well as make some technical comparisons to help you make the decisions about what method is best for your application needs. If this topic is of interest to you, you'll probably also find the Comparison of WAP Push and Short Message Service (SMS) white paper an entertaining read.

Ok, so getting down to business on this, the three messaging technologies that we're talking about (SMS, WAP Push, and MMS) actually build on each other. SMS can operate directly as a way to get information or content to the end users in the form of a text message or in a binary content such as a ringtone or wallpaper/screensaver. SMS can also operate purely as a transport to pass a notification to some other application in the device so the fact that SMS is being used is transparent to the end user. When a WAP Push is delivered over SMS, SMS is a transparent transport to the end user. Similarly, if a J2ME application uses the Messaging API (JSR 120), the delivery of the messages to the Midlet happen via SMS even though the user who receives a message doesn't interact with the SMS client.

Similar to SMS, WAP Push can be used either as a direct way for an application to interact with an end user, or it can be used as a transport. For direct end user interaction, WAP Push can send a browser alert to bring the end user into the browser to a specific URI, or it can send ringtones or wallpapers. It can also operate in a more silent manner by sending chache control operations to the browser on the handset to time out content which may be stored locally. WAP push is also the transport that MMS uses to get notifications of MMS messages to a handset. In this case, WAP Push is being used as a transparent transport, and the user interacts only with the MMS client, not the WAP Push interface.

MMS sits at the top level of the functionality stack because today MMS today is an end unto itself only, and can not be used as a means to transport content/notifications to other applications on the handset. MMS is used for delivery of rich messaging content (e.g. SMIL, pictures, text combined with images and/or sounds), and for ringtones/wallapapers/video clips that can be stored and used by other applications in the device. The delivery of MMS relies on WAP Push, which in turn, relies on SMS.

Hopefully the figure below will help clarify things with regards to the base line capabilities of each of the messaging transports.

Functional Capabilities of Messaging Methods

So, now that we have the functional capabilities of SMS, WAP Push, and MMS defined, let's look a bit closer at how the technologies interact with each other.

When an application wishes to send an SMS message with either text or binary content (ringtone/wallpaper) to a device, the application initiates a connection to an SMSc via a standard protocol such as SMPP. The application must have appropriate access credentials to gain access to the SMSc, and the SMSc will send the message over the air to the handset. The SMSc might be run directly by the mobile operator, or it might be an aggregator which has connections to a variety of mobile operators.

To send a WAP Push message to a handset, an application will post the notification into a Push Proxy Gateway (PPG) via the Push Access Protocol (PAP). The PPG preforms a lookup on the destination address for the push recipient. If the recipient currently has an active data session, the PPG may choose to send the notification directly over the data channel. If there is no active data session, the PPG will send the message as a specially formated binary SMS message as defined by the Push OTA protocol. In this instance, SMS is being used as a pure transport. The PPG is usually run by a mobile operator, and the Push OTA protocol is used between the PPG and the handset, but is transparent to both the application.

To send an MMS Message to an end user, an application will leverage the MM7 protocol to post a message in to the MMSc. The MMSc will then do a lookup on the recipient and queue the message for delivery. The MMSc will actually post a specially formatted WAP Push message into a PPG, whcih will in turn send a notification to the recipient. Just like with a regular WAP Push message, the actual notification may be sent to the handset either over the data channel (if it is available), or via SMS as a pure transport. The MMSc is usually run by a mobile operator, but in the future, there will also likely be aggregators that developers can use to use a single location to reach a range of mobile operators.

Comparison of Submission and Delivery Mechanisms

Hopefully this overview has provided you with enough of a comparison of functionality and mechanics so that you can choose the messaging mechanism whcih is the most efficient and effective for any applications that you choose to build. Please do remember that Openwave provides libraries which implement the standards for WAP Push (PAP), and for MMS (MM7), that can be found as part of the Openwave Mobile SDK. We also operate both a live PPG (as part of our Mobile Access Gateway), and a live MMSc both of which can be used for complete end to end testing of messaging based applications either using the Openwave Phone Simulator or GSM handsets. The details about our test servers can be found here. Until Next time....

Jack's Archives