Supporting WAP in Linux

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.

WAP history

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:

• Wireless Sessions -- When a wireless user is accessing an application from a wireless device, the device may go out of range. Wireless sessions give the wireless device the opportunity to suspend an application session on the content server before the device goes out of range or loses contact in some way. This way , the content server has the ability to save any application specific data. When the device comes back into range, the device can resume the session giving the content server the ability to load the application data and resume the wireless application from where it last left off.
  
  
• Device Abstraction -- WAP has the concept of User Agent Profiles which is a representation of the client device on the application server. This allows wireless applications to serve a wireless client differently depending on the device they are using. Some devices may require different content because their displays are small or their input device is limited in some way.
  
  
• Data/Header Compression -- All headers and data are compressed to ensure optimal bandwidth of wireless bandwidth.
  
  
• Reliability -- WAP provides reliable transport over any bearer in the same way as TCP (Transmission Control Protocol) does but in a manner which uses low bandwidth. WAP also provides SAR (Segmentation And Reassembly) for bearers which do not support it natively.

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:

• WAP Stack -- Technologies such as WSP (Wireless Session Protocol), WTP (Wireless Transport Protocol), WTLS (Wireless Transport Layer Security), WDP (Wireless Datagram Protocol) make up a WAP stack. These technologies allow communications over telecom networks taking into account the low bandwidth, need for push, unpredictable networks and many different bearers that make up the telecom world today.
  
  
• WML Browser -- The WML Microbrowser is the front end to the stack on the telecom client. A WML browser allows a client device, such as a phone, to browse WML content over the web through the stack. It parses a minimalist markup language called WML and a scripting language called WMLScript and displays the formatted text and graphics on the client device. It acts much in the same way as Netscape Communicator or Microsoft Internet Explorer.
  
  
• WAP Gateway -- The WAP Gateway is the front end to the stack on the telecom server. The functionality of the gateway is to emulate the behavior of a web browser. In effect, it allows the phone to communicate over the IP-based web. The Gateway also encodes content for the low bandwidth telecom network. This content does not necessarily have to be WML and can be HTML or streamed content.
  
  
• Origin Server -- Also known as the content server. This server receives HTTP requests from the WAP Gateway on behalf of the user and returns content based on the request.

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:

• Security -- Firstly, even though the WAP protocol has a security mechanism via WTLS, it is not possible for the content provider, using HTTP or HTTPs, to know whether there was security over the air unless a proprietary header is placed in the HTTP header. Secondly, when a user connects with a WAP Gateway it authenticates with it, but never authenticates with the content provider. Thirdly, when the user has authenticated with the WAP Gateway, the gateway decrypts the secure content and might re-encrypt the message to be sent over HTTPs. This implies that the secure content that was intended for the content provider flows as clear text through the WAP Gateway. Fourthly, the WAP Gateway represents the browser and means that any cookies or security information is kept on the Gateway. Information such as credit cards, address, names and all sorts of other information usually kept in cookies by the browser are kept by the Gateway.
  
  As can be seen, the content provider is required to bestow a lot of trust in the carrier. A situation which makes a lot of content providers quite nervous. The ideal situation would be that the wireless user authenticates with the content provider as well as the carrier's WAP Gateway implying that no trust of the carrier would be required.
  
  
• Intelligent Content -- WAP allows information about devices to be transmitted to the WAP Gateway. This allows the WAP Gateway to format pages according to the capabilities of the device. For instance, some devices may have a display which can only display three lines of text and no graphics. The gateway is responsible for formatting content based on the capability of the device, so it will take a stab at formatting the content to fit the three lines and attempts to deal with the graphic in some intelligent way. Traditional WAP Gateways will have a problem because more often than not, the Gateway will format the page in a way that breaks the flow of the wireless applications. This is simply because the Gateway applies the same content formatting rules for all pages flowing through it regardless of the application developers intent. If the content formatting is left to the content server, then the wireless application developer can dictate how the application looks on any device or even determine which devices that it will support. If this were to be done through HTTP it would once again require proprietary headers to be placed in the request to the content server.
  
  
• Suspendable sessions -- As mentioned previously, WAP has the ability to suspend wireless sessions if the device goes out of range or starts using a different underlying transport. As with security, HTTP would need a proprietary header inserted by the WAP gateway indicating that the session has been suspended in order for the application developer to know and deal with the situation in an application dependant way.
  
  
• Single Gateway -- Ultimately, the wireless end user is bound to the WAP Gateway of the carrier. Since the WAP Gateway acts as a proxy to the Internet, the user needs to configure the mobile browser with the address of this Gateway. This causes a problem. If the mobile user roams to a new wireless network whose gateway has a different address or perhaps even on a new network protocol (bearer) the user is then forced to reconfigure the browser for the new WAP gateway on the new wireless network. This information is not always publicly available and does not enhance the user experience.

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.

End-to-end WAP

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:

• Security -- If WAP is streamed directly from the browser to the content-server and vice-versa it solves all of the security problems. Firstly, the WAP connection is secured by the content server so the connection is guaranteed to be secure. Secondly, the user authenticates directly with the content server so information intended for the content provider not seen by anybody else. Thirdly, end-to-end WAP ensures that data never flows as clear text through the WAP Gateway. A tunnel is established where the WAP Gateway is not able to "snoop" the data. Fourthly, cookies are never kept on the WAP Gateway, only on the client device, ensuring data integrity.
  
  
• Intelligent Content -- The WAP session is handled by the content server so content can be formatted in an application specific fashion. For instance, an application may want to format differently depending on the device. WAP streams device information within the request.
  
  
• Suspendable Sessions -- Having the ability to be notified when a device goes out of range allows the application to save data and information and take specific actions when the user resumes the wireless session.
  
  
• Single Gateway -- Using a load balancing feature, WAP Gateways can redirect connections to content servers allowing for the ability to create sessions with the content servers. In addition, a DHCP (Dynamic Host Configuration Protocol) like protocol needs to used to configure the wireless device for new gateways solving the problem of a roaming user.

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.

WAP example

Here is some code taken from the WML Browser project, which shows how to make a simple connectionless WAP request:

#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <stdio.h>

#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;
int fd;
unsigned char* data;
unsigned char* headers;
int dataLen;
int headersLen;

if (argc < 2)
{

printf ("Usage: wspsend <URL>n");
exit (1);

}

/* Header encoding */
headersLen = 1 + strlen (user_agent) + 1;
headers = (unsigned char*) malloc (headersLen);
headers [0] = USER_AGENT | 0x80;
memcpy (headers + 1, user_agent, strlen (user_agent) + 1);

/* Data */
dataLen = 3 + headersLen + strlen (argv[1]);
data = (unsigned char*) malloc (dataLen);
data [0] = 0; /* TID */
data [1] = GET; /* GET method */
data [2] = (unsigned char) (strlen (argv[1])); /* URI len */
memcpy (data + 3, argv [1], strlen (argv[1])); /* URI */
memcpy (data + 3 + strlen (argv[1]), 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));

return 0;

}

Visit the WML Browser project to learn how to decode the data that is returned.

Conclusion

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.