Boris Kuschel of 5NINES discusses what must be done for
Linux to fully support the semi-open wireless Web phone "standard."
For many in the Linux community, WAP -- the Wireless Application Protocol -- leaves a bittersweet taste because of its semi-open nature. The WAP forum is an elitist club for telecommunication giants that requires $27,500 up front and does not promote open discussion about its specifications. Unfortunately, these telecommunication giants control the technical direction of telecommunication carriers which have committed to WAP. While there are other specifications that are open, such as LEAP, it would require both telecommunication hardware manufacturers and carriers to embrace this protocol. A daunting task considering the nature of the wireless data industry today. Besides, the WAP protocols are free to download and free for anybody to implement.
In order to make Linux an attractive platform for wireless data networks it must support WAP on the client and server side. Telecommunication carriers wireless data networks will have WAP servers that Linux devices will need to communicate with in order to access the Internet. This implies that any wireless device manufacturer that intends to use Linux to access the Internet over the PSTN (Public Service Telephone Network ) will need technologies such a WAP stack, a WAP Gateway, and a WML Browser on Linux. For Linux to be attractive as a WAP server it needs WAP technologies and support for common networks such as SMS, Mobitex, and Bluetooth to be able to communicate with the abundant amount of wireless devices in existence today.
The WAP standard needs to be embraced in order to ensure that one player does not dominate the wireless market and that devices can communicate together seamlessly. It doesn't mater whether the standard is not as open as it should be as long as we are able to implement solutions based on Linux which will make it a player in the wireless data market before a proprietary solution dominates the market. If Linux does become a big player in the wireless data market then we, as the Linux community, will be able to influence the direction of WAP. So in the end, it comes down to another fruitless KDE vs. GNOME debate. That being said, lets look at WAP in more detail.
Before the creation of the WAP forum on July 27,1997, all of the telecommunication giants were developing their own protocols and markup languages for wireless Internet access. Nokia had Narrow Band Sockets (NBS) and the Tagged Text Markup Language (TTML), Ericsson had the Intelligent Terminal Transfer Protocol (ITTP) and Phone.com had the Handheld Device Markup Language (HDML). This diversity was threatening to fragment the wireless data access market. Ericsson, Motorola, Nokia and Phone.com all believed that it was in their best interest to create a forum to discuss wireless Internet data access standards. Hence, the WAP forum was created.
What is WAP . . . and who needs it?
WAP was designed for wireless networks. Simply speaking, wireless networks are flaky. Devices can go out of range, then come back into range on a totally different network and can be so small that it would seam ludicrous to browse the web with and be as large as a desktop computer. Additionally, wireless network bandwidth is generally small and even though broadband technologies are being developed that promise 40 Mbits/s, you basically have to stand next to a base station ( a powerful antenna ) to get that data rate, with a dose of radiation included. Wireless networks are vulnerable to interference, distance and load -- all of which effect transmission speeds.
The Wireless Application Protocol was designed to deal with the peculiarities of wireless networks mentioned previously. Features of WAP include:
Who needs WAP? Any content provider that wishes to make an effective wireless application. Simply put, if wireless applications were developed with HTTP/HTML, it would cause a lot of pain for mobile users. Some symptoms would include lost pages, slow responses, no push ability and bad content. As far as telecommunication carriers are concerned, they have no choice because a lot of their customer base may use many different devices -- none of which use IP, but all of which need to communicate with the Internet in a uniform way.
WAP as a wireless protocol
Traditionally, WAP has three components: a WML Browser, a WAP Gateway and the origin server. The Browser on the client device uses the WAP protocol, provided by the WAP stack, to communicate with the Gateway which converts the WAP protocol to HTTP to communicate with the content server. Lets look at these components in detail:
All of these components make up the traditional WAP architecture but there is a fundamental problem here. The Origin Server, or the content server, must use HTTP to communicate with the WAP gateway thus giving the carrier an unfair advantage because they can write WAP applications while the content provider is stuck with HTTP, giving the user none of the benefits that WAP has to offer. While WAP Gateways can be created intelligently to make up for some of these problems, they create others.
Problems with WAP
There have been papers written about the problems with WAP, such as the one written by 4K Associates, but I feel that many of these problems are a matter of interpretation; and some of them are simply not important, from the end users or content provider's perspective. However, there are problems with WAP which are critical and affect the wireless data access experience for the end user and content provider:
All of these problems stem from the fact that WAP was designed as a carrier-centric protocol. If the carrier is the content-provider then there is no problem but if the content provider is on the Internet we end up with the problems mentioned above. Any solution to these problems must move the end point of communication to the content provider.
Bringing WAP to the content-server is a new concept, used in the 5NINE Wireless Internet Servers, which takes a WAP request and, instead of converting it into HTTP, streams the WAP request to the content server. This can be done in two ways: over HTTP and over IP both of which are used as tunnels for WAP requests routed over the Internet to the content server. This solution allows the WAP request to end up at the content server and solves the problems mentioned in the previous section in the following ways:
Bringing WAP to the content solves a lot of problems with WAP Gateways. The WAP Gateway principle of protocol conversion is flawed by nature, and taken it out of the picture makes a clean solution and solves a lot of problems.
Here is some code taken from the WML Browser project, which shows how to make a simple connectionless WAP request:
#define GET 0x40
#define USER_AGENT 0x29
#define CONNECTIONLESS_PORT 9200
static char* user_agent = "wsp-connectionless-test";
int main(int argc, char** argv)
struct sockaddr_in sock_addr;
unsigned char* data;
unsigned char* headers;
if (argc < 2)
printf ("Usage: wspsend <URL>n");
/* Header encoding */
headersLen = 1 + strlen (user_agent) + 1;
headers = (unsigned char*) malloc (headersLen);
headers  = USER_AGENT | 0x80;
memcpy (headers + 1, user_agent, strlen (user_agent) + 1);
/* Data */
dataLen = 3 + headersLen + strlen (argv);
data = (unsigned char*) malloc (dataLen);
data  = 0; /* TID */
data  = GET; /* GET method */
data  = (unsigned char) (strlen (argv)); /* URI len */
memcpy (data + 3, argv , strlen (argv)); /* URI */
memcpy (data + 3 + strlen (argv), headers, headersLen); /* Headers */
fd = socket (AF_INET, SOCK_DGRAM, 0);
bzero (&sock_addr, sizeof (sock_addr));
sock_addr.sin_family = AF_INET;
inet_aton ("127.0.0.1", sock_addr.sin_addr);
sock_addr.sin_port = htons (CONNECTIONLESS_PORT);
sendto (fd, data, dataLen, 0, (struct sockaddr*) &sock_addr, sizeof (sock_addr));
Visit the WML Browser project to learn how to decode the data that is returned.
A lot has been said about WAP being dead. However, I have yet to see any alternative for wireless networks that comes close to WAP's political and technological momentum. An article recently published online by Infoworld clearly explains why an access protocol is needed for wireless devices, and that the protocol may change from what it is today. However, whatever it is five years from now, it will still be called WAP. It is critical for Linux to have strong support for WAP, in order for it to be a serious contender as the operating system embedded within the devices and servers of tomorrow's wireless world.
Author's bio: Boris Kuschel is the Chief Technology Officer of 5NINE. He has been working with Linux since 1996 and currently specializes in wireless data access and has consulted for firms such as Ericsson and Telia in Sweden. He holds a Bachelor of Applied Science (Computer Engineering) degree from the University of Toronto.