[ Home | Glossary | Acronyms | Links | Contact us ]

Cellular Networking Perspectives

Multi-Media Message Service (MMS) may be the next big thing in wireless, the ‘killer app’ that wireless packet data proponents are looking for. Carriers want to take advantage of the advanced features of modern phones, including more memory, higher processing capacities, colour screens, cameras and even video capabilities. They hae learned from SMS that MMS must be universal, not restricted by carrier, phone manufacturer, radio interface technology type or by country.

How MMS Works

MMS is SMS on Steroids. It still allows messages to be sent between mobile phones, not just containing text, but also containing graphics, animations, still pictures, audio and video.

After an MMS user, perhaps a person with a camera phone, prepares an MMS message, it gets sent over the wireless packet data network and then an IP network to the MMS Relay/Server. This then distributes the message to another mobile or, if the destination is on another network, to another MMS Relay/Server. Messages may also be received by mobiles from Value-Added Service Providers and to or from external servers for fax, email and voicemail.

The MMS network reference model is shown in Figure 1. This logical figure shows the types of devices in the network, there will be many of each type. An interface between a network element and itself represents an interface between two distinct devices of the same type.

MMS has 8 interfaces, named MM1 through MM8. The green arrows in Figure 1 show those being standardized first. MM1 allows the mobile to communicate with the MMS Relay/Server and is clearly the most important. MM4 allows inter-carrier operations. MM3 supports communications with gateways for email and other services. MM7 allows Value Added Service applications to send MMS messages and MM8 supports the all-important communication with billing systems, which allows carriers (and, in some cases, third parties, such as value added service providers) to be compensated for MMS services rendered. Standards for MM2, MM5 and MM6 do not yet exist.

Figure 1: MMS Network Reference Model

MMS Design

MMS was designed to reuse existing wireless and IP protocols. SMS began life traveling over the SS7 network, but even these relatively small text messages were a burden for it, being optimized for small signaling messages. IP is really the only choice. MIME was chosen as the way of packaging up the different media components of the message. The MMS session is managed by WAP, IMAP or SIP, all of which run over IP. This fits nicely into existing wireless packet data technologies (e.g. GPRS, CDMA 1X) which are all IP-based.

Inter-Carrier Messaging

Mobile-to-mobile MMS messages are sent from the User Agent (i.e. the wireless device) to the user’s home MMS Relay/Server. If the two mobiles are not served by the same carrier, the message is then forwarded over the MM4 interface to the receiving mobile’s MMS Relay/Server using SMTP (Simple Mail Transmission Protocol). This device then sends a notification to the destination mobile. The mobile then may retrieve the MMS message from the server at its leisure. Before actually receiving the message, the destination mobile will negotiate the best acceptable media formats with its MMS Relay/Server, which will then perform content adaptation, if necessary.

It might seem that the use of multiple MM1 access methods in 3GPP2 (see Table 1) might also cause some inter-carrier problems. However, this is not actually a problem because this interface is between the mobile and its home system and the protocol layer is transparent to the lower layer protocols that transport it across the packet data network even when a mobile is roaming.

MMS will not just be used between mobiles. The MM7 interface is designed to connect with Value Added Service Providers. A news summary could be sent to a mobile from a media outlet, containing a mixture of text, audio clips, still pictures and video clips. Content may be sent by a VASP on a schedule, or when a certain event occurs (such as traffic congestion, a weather warning or a news break) or upon request from the mobile user.

Another common interaction will be over the MM3 interface between an MMS device and external services to interface to email, fax, voice mail or other services.

Store and Forward: The MMBox

MMS and SMS are both ‘store and forward’ services, where an intermediate device keeps a copy of the message at least until it is delivered. With SMS, however, the user has no direct control over their mail box. With MMS, control over the MMBox (Multimedia Mailbox) is possible. Messages can be deposited there and distributed at different times to different destinations. This is important for MMS because the large size of many messages makes it inefficient to retransmit them from the originator if they have to be sent multiple times.

Media Types

Every media type, from voice to video, has to be defined. This includes a coded format for the digital information, as well as a method of encapsulation. This generally does not require new wireless standards, but does require the selection of acceptable media types, and a method of marking them so that they can be recognized.

Formats that are currently acceptable for MMS include video (e.g. MPEG-4 and H.263), audio (e.g. MPEG-4, AMR and AMR-WB and, for 3GPP2 only, EVRC and QCELP and SMV), text and graphics (e.g. GIF, JPEG, PNG, Bitmap). MMS devices must also support at least one presentation language such as SMIL, XHTML or cmf (Compact Multimedia Format). This allows a mixture of media to be presented in a controlled fashion. A simple example would be a picture of a baby with a caption underneath (e.g. “Baby’s first words”) with a button to play a short audio clip.

Content Adaptation

The many media types that can possibly be wrapped in an MMS message creates one of the big challenges for MMS – interworking between devices and networks. If a GSM/GPRS terminal uses the native GSM AMR voice coder as part of an MMS that it sends to a CDMA terminal that only supports EVRC and QCELP voice coders, content adaptation will be necessary or the message transmission will fail. Similarly, a photograph might be produced in PNG format, but need to be delivered to a terminal that supports only JPEG.

Content adaptation could become a significant cost for the network, requiring bigger and more powerful MMS Relay/Servers than would just be required for storing and forwarding messages unchanged. This is also a problem for SMS, but to a much lesser extent. SMS only needs to worry about mapping between the bit formats for GSM, TIA-136 and cdma2000 and imposing the lowest common denominator maximum message length. MMS is less constrained by the size of messages, and more by the significantly larger number of more complex conversions.

Addressing

The two main ways to address an MMS message are with a phone number (MDN – Mobile Directory Number) or an email-like address. An email-address works well with a service carried over IP networks, like MMS, but is harder to enter from a wireless phone. It also means that carriers have to maintain an email address for each MMS customer, and coordinate their address plans.

A phone number is also a useful address, although there are significant problems in countries, like the United States after November 2003, that require wireless carriers to participate in number portability. The number portability database was intended to be queried from the SS7 network and from a system that was in the same region as the destination number. This will not work for MMS because the challenge is to route to the destination MMS Relay/Server, meaning that the Home Relay/Server will have to do the number portability query. However, this device may be in a different country and can hardly be expected to perform this service, and might not even be allowed to. Solving this may require introducing another network element, at least for international MMS transmissions, to perform number portability queries at an intermediate point.

Billing

MMS would work without billing, but carriers would be understandably unenthusiastic about the service if they could not get paid for it. The simplest billing model will be that customers pay a monthly service fee, plus charges for each message. The sender and recipient may both be charged, or just one of them. In the case of VAS messages, the carrier may apply premium charges to each such message, and return an agreed upon portion to the VASP. Some VAS messages, such as advertising (hopefully ‘opt in’) may be paid for by the VASP, resulting in no charges to the mobile subscribers.

MMS is compatible with both monthly billing models and prepaid. In both cases carriers must determine what customers are paying for. Per-message charges will not be equitable, because messages may vary dramatically in size. Per-byte charges, on the other hand, will be very fair, but will be confusing to the consumer. Somehow carriers have to create a billing model that consumers will understand, be willing to pay for and that roughly reflects resource usage. An example could be a flat fee for sending an MMS containing one JPEG-encoded photograph, with the carrier limiting the maximum size of the photograph to stop abuse. This is something that consumers can understand and that maps into a small range of transmission sizes, so that carriers can ensure that their packet data network runs at a profit.

Billing raises additional inter-carrier issues. Both carriers must have a contractual agreement, and a method for exchanging call detail records on a regular basis (at least once a month, if not closer to real-time). MMS also presupposes the existence of packet data roaming and billing arrangements between carriers.

Standardization

MMS represents a truce in the technology wars between 3GPP and 3GPP2. Although both organizations would like their technology (GSM/Wideband CDMA or cdma2000) to come out on top in the long run, but they have also realized that this will not happen soon, and MMS will not be successful if consumers cannot exchange messages with phone, regardless of type.

In November, 2003 an agreement was reached between OMA (www.openmobilealliance.org), 3GPP (www.3gpp.org) and 3GPP2 (www.3gpp2.org) to share responsibility for the future evolution of MMS. Following the current release of MMS specifications, OMA will assume responsibility for the air-interface independent aspects of the protocol, leaving 3GPP and 3GPP2 to develop specifications that are access dependent, including the definition of accounting (billing), media types and coder/decoders (codecs).

Table 1 shows the current standards being developed by 3GPP and 3GPP2. This will change as the migration to OMA occurs, expected some time in 2004.

Table 1: MMS Specifications

MMS: A Work in Progress

MMS is not a service like SMS, it is an entirely new infrastructure. New media types can be added as they are invented and as it becomes possible and desirable for wireless devices to use them. MMS, building on the availability of higher speed packet data protocols, will enhance the user experience by providing an integration of newer phone capabilities, such as colour graphics and photographs with sound and text.

There will be some frustrations at first, as interworking problems are worked out. But carriers are aware that parochialism is not an option. It did not work with SMS, and it will not work with MMS. Consumers will expect that they can send an MMS message to any wireless customer, no matter which carrier they purchase services from, no matter what brand of phone they are using and no matter where in the world they are.