By now you are no doubt familiar with the shortcomings of the Wireless Application Protocol (WAP). Some of these shortcomings—low bandwidth and high latency—have to be addressed by network operators. Others—usability and richness—have to be addressed by the application developers themselves. The latter had proven to be a difficult task until Mobile Services (M-Services) were introduced by the GSM Association (GSMA) in June 2001. With the introduction of M-Services, developers now have a standard, cross-platform way to create sophisticated and user-friendly wireless Internet applications. But for M-Services to be successful, network operators, handset manufacturers, and application developers have to cooperate on the guideline implementations.
M-Services are guidelines for creating wireless Internet applications. They are not an industry standard, as the GSMA is not a standards body; rather they are requirements that members of the GSMA adhere to for developing and deploying wireless data applications. M-Services provide a way for wireless operators, handset manufacturers, and application developers to provide value-added services that are attractive to consumers—similar to what is provided by NTT DoCoMo with the i-Mode service in Japan. Unlike previous solutions that are largely browser-based, M-Services address the entire development and deployment platform. In doing so, they incorporate several elements, many of which are existing standards:
WAP June 2000 Conformance Release
WAP 2.0 (for WML2/XHTML Basic and provisioning)
Graphical user interface (GUI)
Download of media objects
Multimedia Message Service (MMS) and, optionally, email
Enhanced Message Service (EMS)
SIM Application Toolkit
SyncML for vCard and vCalendar
When M-Services were released, many misinterpreted them to be intended as a replacement for WAP. This is not true. The M-Services guidelines complement WAP; they define areas that the WAP specification does not address, such as application user interfaces, navigation, and content downloads. For more information on WAP and wireless Internet applications, see Chapter 11, "Thin Client Overview."
Not all of these features are immediately required in M-Services. Rather, M-Services are being rolled out in two phases over a two-year period. Phase I was introduced in June 2001; its objective was to deploy the first set of M-Services by the end of 2001. The requirements for Phase I included handset support for GPRS and WAP provisioning; support for WAP 1.2.1 features, such as WAP Push, WTLS 2, and UAProf; support for Enhanced Message Service (EMS) and long messaging; and downloadable object support for ringtones and wallpapers. Phase II, introduced in February 2002, is intended to complete the picture. Two implementation dates were defined for Phase II: September 2002 and April 2003. Building on Phase I, Phase II requires additional support in many of the same areas, with a focus on the user interface, downloadable objects, and messaging. The following subsections give a more in-depth explanation of what is required in these categories.
The first, and in many cases most important, set of requirements applies to the user interface and navigation of M-Services applications. These requirements include a new suite of graphical components, as well as a specification for navigation between screens. This will address one of the major problems of WAP, where the UI varies from phone to phone, making development incredibly difficult.
The following are some improved navigation and UI features aimed at making the wireless browsing experience more similar to a traditional desktop:
A set of new components for more advanced applications. These components include pop-up menus, radio buttons, check boxes, push buttons, text boxes, tables, and inline hypertext links.
Support for WAP components such as UAProf, WAP Push, WTLS Class 2, and Provisioning agent. It is also recommended that WML2 or XHTML Basic be used.
Use of soft keys to support icons. In addition, soft key labels must appear near the physical key, out of the text flow.
The use of a title bar to let users know what part of the application they are currently in. The title bar must scroll with the content of the page.
Push buttons must have the label inside of the button, rather than beside it. This will help distinguish them from text entry fields.
This list is not exhaustive. Many other user interface requirements will make wireless Internet applications much more approachable. In order for these applications to be successful, handset manufacturers have to produce M-Services-compatible devices, with support for over-the-air provisioning, color, graphics and multimedia. By 2002, the first wave of M-Services-enabled devices had come to market, and many more are expected in 2003 and beyond.
The ability to download larger and richer content is important to the developers of M-Services. Though users can download content such as ringtones, wallpaper, and screensavers using SMS, anything more advanced, such as digital pictures, Java MIDlets, or multimedia files, were too large for these transport mechanisms. M-Services solves this by adopting Download Fun (DF), a structured system for managing content downloads. It allows wireless operators to control application content distribution and provides an opportunity for them to share in the deployment revenues.
Many types of content are suitable for download to a wireless phone. The more common types are ringtones, wallpaper, screensavers, pictures (JPEG, GIF, WBMP, PNG), games, Java applications (that are compliant with CLDC 1.0 and MIDP 1.0 or later), audio clips, video clips, vCard and vCalendar entries, and bookmarks. A Download Fun server is required to support these downloadable objects. The M-Services Phase II requirements specify which formats are mandatory, recommended, or optional. Most of the formats listed here are mandatory.
In Phase I, M-Services require support for Long SMS (640 characters in length) EMS; in Phase II, for MMS. Support for these advanced messaging protocols is essential if M-Services are to be universally accepted by both consumers and corporations. In order to take advantage of these new messaging protocols, faster networks (2.5G and 3G), as well as handsets with color and graphics support, are required.
Support for email is optional in M-Services.
The primary beneficiary of M-Services is the consumer. In fact, providing effective services for the end user is the driving force behind the M-Services guidelines. When applications based on the M-Services guidelines are deployed, consumers will finally have sophisticated, user-friendly services available to them from their wireless devices. These applications have interfaces similar to standard Web applications, making them much more approachable to the average consumer.
But to be successful in creating effective consumer services, the other parties involved in the creation and deployment of M-Services have to work together—the network operators, handset manufacturers, and developers. Fortunately, these parties will also benefit from M-Services, giving them the incentive to bring these solutions to market quickly.
Network operators. The operator will form the relationship with the consumer. They will take control of application management and provisioning, giving them new revenue streams by selling M-Services. In addition, M-Services will help drive wireless data usage, thereby increasing operator revenues.
Application developers. Second only to consumers, developers benefit most from M-Services, primarily because M-Services improve upon WAP in two main areas: increased application usability and a standard client interface. M-Services help developers create applications that are more attractive to users and that will work equally well on any mobile handset. Anyone who has developed WAP applications knows that both of these were difficult to achieve before the advent of M-Services.
Handset manufacturers. The compelling set of M-Services applications will lead consumers to upgrade their devices to support the latest applications. By using mobile phones for more than just voice calls, consumers will realize more value from their device, hence will be more inclined to spend more on a handset. In addition, because M-Services guidelines describe how content should be displayed and how user interactions are to be handled, true application interoperability between handsets becomes possible.
M-Services have the potential to revive the floundering WAP industry. Consumers have become frustrated by the lack of compelling applications available on wireless phones, and developers have had a hard time addressing the issue because of the fragmented WAP market. Thanks to M-Services, network operators, handset manufacturers, and developers have a standard platform to aim for.
It is important to point out that M-Services require the network operator to support GPRS. Other network protocols, including GSM, are not supported. The GSMA does not see this as a limitation since close to 70 percent of the world's digital subscribers are represented by the GSMA. As 3G technologies are rolled out, they expect this number to grow to 80 percent.
If you are planning to implement M-Services applications, be sure to visit www.gsmworld.com and download the M-Services Phase I Guidelines and M-Services Phase II Requirements.