The World Wide Web is potentially about a lot more than just surfing from a desktop PC. But infrastructure challenges make true wireless Web a bit harder to access.
A significant amount of media coverage has been given to the wireless web of late. It seems you can't turn around without seeing some new prognostication, press release, or advertisement on how the wireless web is going to change everything. The scary thing is that, all hype aside, it's probably true-wireless will have a profound impact on businesses and consumers alike. It's a matter of when, not if.
Predictions are that sometime between 2003 and 2006 there will be over 1 billion wireless phone subscribers worldwide, between 50% and 80% of whom will have data capability. But cellular phones and PDAs are only part of the story. Mobile devices include digital cameras, MP3 players, diagnostic equipment, and much more. In addition, many non-mobile devices can make use of wireless technology-remote monitoring and other field assets can derive benefits from wireless access to the Internet.
In many respects, accessing the wireless web is no different then the traditional methods of access. As shown in Figure 1, a client device makes a connection, often through some gateway, to a server that responds to the client requests with specific data. The main difference is that in this case, the communications between the client and the gateway uses a wireless transmission mechanism and the protocol may or may not be standard HTML over HTTP/TCP/IP.
As is usually the case with a market in its formative years, several technologies are vying for market share as a wireless access mechanism. The current contenders are the Wireless Access Protocol (WAP), Web Clipping, Compact HTML, and standard HTML using a wireless modem, all of which are discussed subsequently.
The answer to the question “how do I access the wireless web today?” is: very slowly. The maximum data rates achievable today are on the order of 14.4Kbps for the current second generation (2G) infrastructure. It is interesting to note that there is obviously a lot of pent up demand, even at these pitiful data rates. How else could you offer what is essentially text-based Internet access at 14.4Kbps for around $10 per month and still have people buy it.
The mobility offered by wireless devices provides such an attractive upside that people are willing to put up with such shoddy performance. Perhaps even more troublesome to the end user than lack of bandwidth is the connection time required before data even starts to move.
Most of today's wireless standards are circuit-based systems rather than packet-based systems. That means that when a user tries to access the wireless web they are essentially placing a phone call to the gateway. All of the setup time of making that dedicated circuit connection creates a painful delay of up to 30 seconds or so before data can start flowing. Two notable exceptions to this are NTT Docomo's i-Mode system and the Mobitex network used by Palm VII, which are both packet-based systems.
Another annoyance is the lack of a single worldwide digital wireless standard. In fact, four standards are currently used in the U.S. It quickly becomes an alphabet soup of acronyms when trying to keep track of the current infrastructure. Table 1 contains a list of the more prevalent wireless technologies currently in use worldwide.
Table 1: Some of the more prevalent wireless technologies currently in use
As anyone with a digital cell phone can attest, coverage is spotty and highly dependent on your carrier. For voice calls, when digital coverage is not available, some phones can change to an analog roaming mode. Unfortunately, for data calls, analog roaming doesn't cut it; no digital signal means no data transfer.
The good news is that the wireless data infrastructure is rapidly evolving to 2.5G and third-generation (3G) systems. 3G systems will provide significantly higher bandwidth and compatibility amongst carriers and countries. 3G technology provides data rates up to 384Kbps for mobile devices (2Mbps for stationary devices). While this bandwidth is shared by all users in a particular cell, these data rates still offer a tremendous opportunity for new and creative services, including video and multimedia. See Figure 2.
It is important to note that most of the 2.5G and all of the 3G systems are packet based, removing the annoying latencies associated with circuit-switched networks.
Various technologies can be used to provide formatted data to wireless devices. Some of these technologies are tied to a specific service provider, while others allow your data to be accessed from any device on any provider. Regardless of the final implementation details, all of these technologies must deal with some basic constraints of wireless systems. These constraints touch both the data transport mechanism as well as the capabilities and resources of the client device.
On the data transport side is the limited bandwidth (ruling out graphics and multimedia); poor quality of service (signal dropouts are to be expected); and high latencies.
The constraints on the device (client) side are certainly familiar to embedded developers. They include limited ROM/RAM and processing power; power consumption considerations (a potentially huge issue for 3G systems); and limited display capability and user input mechanisms. The last two items have the biggest impact on developers implementing Web sites for wireless devices.
The following sections detail some of the more common technologies used in implementing wireless web access. Several other technologies and combinations of technologies that can provide wireless access to the Internet are not covered here. The lines are very fuzzy between devices, mark-up languages, transport protocols, wireless ISPs, and RF networks-leading to a lot of confusion. For instance Research in Motion's (RIM) Blackberry and similar devices can use Mobitex, Motient (ARDIS), or, soon, CDMA RF networks to share information; can run WAP, ReFlex, or IP protocols; and support HTML, WML, Compact HTML, or proprietary mark-up languages. What you get as an end user is determined by the carrier/ISP you choose.
The Wireless Access Protocol (WAP) has been getting the lion's share of the press coverage of late. This protocol is the underlying technology for most of today's cell phones that have Web capability. As shown in Figure 3, WAP loosely follows the standard seven-layer OSI reference model, but replaces most of the layers with layers optimized for wireless environments.
As with the other wireless technologies mentioned here, the content server side of WAP utilizes standard Internet technologies for data transport. There is no need to throw away your existing servers that use HTTP and connect to the Internet using TCP/IP. Most of the real heavy lifting is done by the so called WAP gateway (which is technically a proxy).
A WAP gateway provides protocol translation and data compression capabilities. Data comes in on the wireless end in a binary encoding on top of the rest of the WAP stack and is translated to the HTTP over TCP/IP, which we all know and love.
Figure 4 is a representation of how data flows in the WAP universe. The WAP gateway is typically maintained by the wireless service provider. However, if a CDPD modem that dials directly into a corporate infrastructure is used, the gateway functionality would have to be provided by that company's enterprise system. In Europe, service providers often allow flow-through access to a corporate controlled gateway.
Web clipping is the technology used by the Palm VII handhelds. The concept is beautiful in its simplicity. It is based on the premise that most content is static and that specific information an end user is requesting is usually the only dynamic part. This maps very well to one of the keys for developing a Web site that is accessed by multiple types of devices-keep the content separate from the format.
Developing a Web site that supports a Palm VII device consists of two steps. Step one is developing a Palm Query Application (PQA), which ultimately resides on the user's device. Step two is developing a series of web pages using a subset of HTML that serve up “results pages.”
The PQA is an application that runs on the Palm device. It generates specific HTTP requests to the server containing the results pages. Also included in the PQA is static formatting information, including any graphics that might be displayed. Results pages can return not only specific data requested, but can also refer to any objects (graphics, text strings, and so on) stored locally with the PQA. The obvious downside to this method is that the PQA must be downloaded to the handheld ahead of time. Any changes to the Web site that involve formatting would necessitate the end user re-downloading the PQA.
One other disadvantage of the Palm VII's web clipping implementation is the lack of choice in wireless service providers. The Palm.Net service uses the Bell South infrastructure. While Bell South has pretty extensive coverage throughout the U.S., many areas have no coverage. This presents a problem to users in those locations.
CDPD and analog modems
Another implementation option uses the fairly ubiquitous analog cellular (AMPS) infrastructure and a wireless modem. To the end user this is a similar experience to using a wired dial-up service using standard HTML and HTTP over a PPP dial-up.
The advantages of this approach are that the end user has access to everything the Internet has to offer and the server side of the enterprise does not need any modification. The bigger disadvantage is that the end user may need an Internet Service Provider in addition to the already high roaming charges that may accrue. In addition, all of the rich content of the web is downloaded at 9,600bps-a painful proposition at best. Cellular Digital Packet Data (CDPD) modems offer higher throughput at 19.2Kbps, but coverage is spotty and roaming agreements are less common.
Japan's i-Mode system has been nothing short of a phenomenon. Run by NTT Docomo, at the time of this writing i-Mode has garnered over 15 million users in little over one year of operation. To put that in perspective, that is more than all of the other wireless Internet services combined.
i-Mode is a packet-based, always-on connection with data rates up to 9,600bps. (A 64Kbps infrastructure is presently being rolled out.) Users pay for the data service by the byte and purchase of third-party goods and services are aggregated by NTT and presented in the user's monthly bill.
i-Mode uses Compact HTML (cHTML) at its application layer. cHTML is a W3C-approved subset of HTML 4.0. Features excluded from cHTML include support for JPEG images, tables, image maps, multiple-character fonts, frames, and stylesheets. A move is underway to merge cHTML with WML, but only time will tell how successful the effort to bring these two warring factions together will be.
One of the interesting things about the success of i-Mode is that it debunks the popular belief that all we need is more bandwidth to make the wireless web take off. From a pure bandwidth standpoint, i-Mode is the slowest of all the technologies discussed here. There are three factors that I believe have led to the success of i-Mode, one technical, one economic, and one social.
The technical part is that i-Mode is always on; there are no latencies associated with using it-you click on a button and you are there. The economic factor is that i-Mode provides content and convenience that people are willing to pay for. Believe it or not, one of the most popular purchases made over i-Mode phones are background wallpaper images for the screens on the phone; users pay about 25 cents for each new download. The final factor is cultural. The U.S. concept of the Web revolves around browsers on PCs and fancy pages with all sorts of eye candy. In Japan dial-up Internet service has never been a huge factor, so people's expectations are very different. As a result, the capabilities of the wireless web have never been oversold in Japan as they have been in the U.S.
Web design for wireless
The remainder of this article focuses on WAP, although most of what is said is just as applicable to web clipping applications. In fact, it is quite possible that a Web site will need to support both technologies.
Impact on existing system architecture
The first question that someone tasked with implementing wireless capabilities on top of an existing Internet-based system should ask is: how is this going to affect what I already have in place? The good news is that all of your existing hardware and backend systems can be used without modification. In fact, a well architected enterprise system can add wireless capability by the process of addition, not modification. The bad news is that most enterprise systems were not designed to support multiple client device types; if they supported Netscape Navigator or Microsoft's Internet Explorer on a PC monitor, that was enough.
Server requirements and setup
Any computer capable of serving up HTML and supporting HTTP 1.1 can act as a WML server. The only change needed is the addition of a few new MIME types.
Table 2 lists the necessary MIME type additions. The last two entries in the table are only needed if the server intends to reply with precompiled WML or WMLscript. Compilation usually falls under the domain of the WAP gateway and is typically not performed on the content server.
Table 2: Necessary MIME type additions
Dynamic content creation
The heterogeneous environment presented by multiple types of wireless devices trying to access your Web site requires a change in thinking for most Web application integrators. In addition, many Web sites deal with dynamic information. Web front ends that hook into corporate backend information systems need to be able to retrieve requested data and format it appropriately for the requesting device.
WML is an XML-derived markup language. The purpose of this article is not to go into the specific details of WML; that has already been well covered in the pages of this magazine. (See Jeff Stefan's article “Working with WAP,” October 2000, p. 47.) The XML foundation of WML allows for content to be targeted to specific devices based on their display capability. Since WML is a text-based markup language, any application that can dynamically serve up HTML pages can also serve up WML. Technologies such as Java Server Pages (JSP), Active Server Pages (ASP), and Perl can all be used to generate WML on the fly.
The more difficult part of extending your enterprise to support wireless is how to support not only the plethora of different wireless devices, but the traditional PC-based wired browsers as well. It is possible to retrieve the requesting device capabilities from the HTTP header of the request. From that information a decision can be made on whether to serve up HTML or WML. Unfortunately, for non-PC devices you still aren't done. Display capabilities can run the gamut from full color 640×480 displays down to 4-line by 14-character text-only displays.
For non-public sites and portals, it is possible to reduce some of this complexity by simply specifying to your employees or customers the type of device(s) they should use to access the content on the site. Unfortunately, for a public site, this won't work. Short of writing separate JSP/ASP/Perl applications for every type of device, what can be done?
The fact that WML is based on XML allows us to separate the structure and data content from the formatting. XML, in conjunction with the eXtensible Stylesheet Language (XSL), can be used as a mechanism to provide the data in the proper format for each device. See Figure 5.
The number of stylesheets one can reasonably support is still limited, but this technique makes it much easier to add support for new devices as they come along.
UI and navigation issues
Anyone who has ever typed a name into an address book on a cell phone knows that inputting information on a handheld device can be quite trying. When used as a phone, these are wonderful devices; when used for other purposes, they violate almost any good user interface design rule imaginable. Small displays with limited graphic support and multifunction keys that do different things in different modes are just two of the sins visited upon an end user. It is up to the Web site developer to alleviate some of the pain by understanding the device's limitations and formatting the content and input screens accordingly. Some keys for designing good Web sites for wireless devices:
User interface technology is changing rapidly and form factors are changing as well. Things like voice recognition, VoiceML and other text-to-speech languages, and handwriting recognition are all improving in quality and will become mainstream technologies over the next few years.
It is also important to recognize that for businesses incorporating mobile connectivity and appliances into their enterprise systems, the user interface is only part of the recipe required to gain the maximum benefit. Adding anytime, anywhere communications changes the entire workflow of an organization. The fact that the field service technician can now have device malfunction alerts pushed to him and he can run remote diagnostics on that device changes his day-to-day operating procedures and the business processes associated with them. If these changes are not accounted for when developing a complete solution, much of the potential benefit will be lost.
WAP was designed to be bearer-independent. The Wireless Datagram Protocol (WDP), which is the lowest layer defined in the WAP specification, performs the adaptation to whatever underlying RF layer is used. Standards addressed in the WDP specification include GSM, IS-136 (TDMA), CDMA, CDPD, PDC, iDEN, FLEX and ReFLEX, PHS, and DECT-just to name a few! Depending on what vendor is supplying the protocol stack, the device developer may have to provide this translation layer if he is using a bearer that is not supported out of the box by the stack vendor.
WAP browsers for devices are available from the likes of Phone.com (the UP.Browser), Microsoft (Mobile Explorer), Nokia (WAP Client), and others. Microsoft's browser is notable because it is designed to support HTTP and HTML along with WAP and WML. Because these browsers are targeted towards handheld devices, they do try to conserve resources. A typical implementation requires 200KB to 300KB of ROM and a similar amount of RAM.
There are also some minimum display and user input requirements defined for any WAP-capable device. These requirements are as follows:
- Four-line, 12-character display
- Bottom line is used for function key labels
Numeric and alphabetic character entryTwo programmable function keys
- Referred to as ACCEPT and OPTIONSLabels for keys appear above the keys in the display
Support for ASCII printable character setVertical scrolling with arrow keysHorizontal scrolling of non-wrapping lines A PREV or BACK key for navigating backwardChoice selector (up/down arrows or number keys)
Since WAP is typically designed into a mobile, battery-powered device, power consumption will always be an issue. While it is not intuitive, the user interface and the design of wireless Web sites have a direct effect on battery consumption (as well as user satisfaction). A significant latency is associated with having to make a new request to the server. It can take several seconds to get a response, and each request and response uses precious RF energy and battery power. WAP supports data caching and cookies, which can be cleverly used to minimize the number of requests made back to the server. Of course, the amount of data you can cache has a direct correlation to the amount of memory available.
Security is a major issue for the Internet. Add to that the fact that wireless devices are, by their very nature, broadcasting RF signals out to anyone who wants to listen, and you come up with some real fears among end users. No one wants their credit card or sensitive corporate information out there, exposed for the taking. Fortunately, WAP addresses security in the Wireless Transport Layer Security (WTLS) specification. WTLS is based on the industry standard Secure Sockets Layer (SSL).
The W part of WTLS is where the main differences are-dealing with the wireless environment means dealing with low bandwidth and high latency. Encryption key exchanges and handshaking can consume a lot of bandwidth. WTLS optimizes the handshaking used to initiate a session and then provides for lightweight dynamic key refreshing to allow continual encryption key updates. In addition to the encryption aspect, WTLS also provides for authentication, data integrity, and denial of service protection.
The wireless link is half of the battle. Once the data reaches the WAP gateway it must be transmitted to the content server. Luckily, this entire path is based on standard Internet technologies that provide for the same level of security you can get anywhere. The big concern for the truly paranoid is what happens inside the WAP gateway. The content encoding and encryption mechanisms are different between the wireless and wired sides of the gateway. The gateway must decrypt, decode, and then re-encrypt the data. Some time during this process, that credit card info or corporate secret sits unencrypted on the WAP gateway.
Taking the plunge
End-user mobility and the integration of devices of all sorts, mobile or otherwise, into the business enterprise are two big trends that are bringing fundamental changes to both business and society. The closest analogy I have come up with is the invention of the steam engine. When applied to a locomotive, the steam engine created substantial mobility and the resulting population shifts greatly changed both society and how business was done. When applied to the factory, the steam engine completely changed the business environment with new efficiencies and new ways of working. Those two applications of one technology, the steam engine, fed the industrial revolution. The application of Internet technologies to non-PC devices has the potential to have an impact that is just as significant and long lasting.
When the wireless web was introduced in the U.S., the main feedback was “Why would I want to surf the Web on such a small screen?” The point is that wireless Web is not about surfing; it's about getting the information you, your customers, or your devices need anytime, anywhere.
Creating a successful wireless enterprise is much more complicated than slapping a wireless modem on your existing infrastructure. A number of variables exist when selecting the right wireless approach to meet your requirements. Being able to understand and navigate all of the issues, from the devices up through the enterprise systems, is a critical element in any successful wireless endeavor. esp
John Canosa is a contributing editor to Embedded Systems Programming and chief scientist of Questra Corp. John has a BSEE from Clarkson University and an MSEE from the Rochester Institute of Technology. You can e-mail him at
1. WAP Forum: www.wapforum.org
2. Palm Web Clipping Applications: www.palm.com/devzone/webclipping
- Figure 1 : A typical wireless web infrastructure
- Figure 2 : Digital wireless infrastructure migration
- Figure 3 : WAP stack
- Figure 4 : The WAP model
- Figure 5 : Supporting multiple device types
- Figure 2 : Digital wireless infrastructure migration
Return to Table of Contents