12
The Wireless Application Protocol
Wireless Application Protocol (WAP) is a wireless protocol that allows mobile devices to use data service and access the Internet. WAP can work with a variety of different wireless technologies, each of which connects at the bottom of the WAP stack as a bearer. Bluetooth simply provides another possible bearer beneath the WAP stack.
In the same way that Bluetooth has the SIG which defines standards and helps to ensure interoperability of Bluetooth devices, WAP has the WAP forum. The WAP forum brings together companies from all parts of the wireless industry to define WAP standards and to help ensure interoperability between WAP products. WAP standards can be downloaded from the WAP forum Web site at http://www.wapforum.org.
WAP supports many wireless networks: CDPD, CDMA, GSM, PDC, PHS, TDMA, FLEX, ReFLEX, iDEN, TETRA, DECT DataTAC, and Mobitex, but at the time of writing, Bluetooth has not been formally adopted as a bearer layer by the WAP forum. This does not mean that there will be no standards for interoperability between WAP-enabled Bluetooth products. The Bluetooth specification includes a section on how to interoperate with WAP, and the Bluetooth SIG is working with the WAP forum to help ensure interoperability of Bluetooth and WAP.
WAP supports a client/server architecture. The client communicates with a server (or proxy) using the WAP protocols. WAP-enabled client devices can use micro-browsers, which are specially designed Web browsers that fit onto mobile devices such as mobile cellular phone handsets. A microbrowser is designed to work with a small screen, and to use less memory than a browser running on a desktop PC. WAP supports such facilities through the Wireless Markup Language (WML). This works in similar ways to Hypertext Markup Language (HTML). HTML is used to design pages on the World Wide Web; WML pages work in a similar way to HTML pages, but are designed to cope with the smaller screen sizes typically found on today’s mobile devices.
Content providers (the people who put up Internet sites) are providing WAP pages because it allows them to access a huge market of mobile customers, many of whom browse the Web at home, or at the office, but cannot access it on the move. The market for WAP services extends much further than this though, around twice as many mobile phones are sold as desktop PCs, so as more and more phones become “smart phones” with microbrowsers, many people who do not have a PC will be able to access the World Wide Web through their mobile phone.
WAP does not just work with phones. Pagers and PDAs are obvious candidates to work with WAP; in fact, any device with a screen and the ability to support a wireless connection could be turned into a WAP device.
12.1 The Wap Forum
The WAP forum is headed by a board of directors; below the board is the specification committee, the architecture group (a group who specifies what working groups will do), and the expert working groups themselves (see Figure 12–1). It is the expert working groups who define the details of the WAP standard. Members of the WAP forum can at tend these groups and participate in the definition of the WAP standard. Nonmembers can still influence the specification by submitting comments to the WAP Web site at http://www.wapforum.org.
Figure 12–1 Structure of the WAP organisation.
The board of directors staffs the specification committee. The specification committee is in charge of releasing WAP specifications, and it is also in charge of their content. To aid in this work, the specification committee forms expert working groups and specification working groups.
Members of the WAP forum can attend the working groups which define the WAP specification, allowing them to participate directly in the process of writing new versions. They can also help to define the marketing messages for WAP, nominate and elect directors to the WAP forum board, and, of course, network with other companies interested in WAP.
The architecture group is staffed from the working groups. This group provides technical direction for the specification and expert working groups, including resolving issues and conflicts. The architecture group also tracks the overall architecture of WAP.
Companies apply to join the WAP forum by filling out a form. This form is available from the WAP Web site. At the time of writing, the Bluetooth SIG is free to join, but the WAP forum costs $27,500 USD for full membership and $7,500 for associate membership. Only full members may vote in the elections for the WAP board of directors.
Members who join the WAP forum agree to license the IPR (Intellectual Property Rights) essential to implementing WAP on “fair, reasonable, and non-discriminatory terms”. This probably means that essential IPR for WAP will not be free. This is in contrast with the Bluetooth license, which provides SIG members with free access to essential IPR.
On the other hand, content and application developers get a royalty free IPR license. This is because widespread availability of WAP pages and WAP applications will assist the take-up of WAP.
12.2 The Wap Stack
WAP uses a combination of Internet protocols (such as UDP) and protocols specially modified to work with mobile devices (such as WML, which is based on XML, the same standard on which HTML is based).
The WAP components used above the Bluetooth protocol stack and shown in Figure 12–2 are:
- WAE (Wireless Application Environment)—Provides a user interface, typically a microbrowser, which is a lightweight version of a Web browser.
- WSP (Wireless Session Protocol)—Supports the session between a WAP client and the WAP server.
- WTP (Wireless Transport Protocol)—Provides a reliable transport layer for WSP. If other layers below WSP provide a reliable service, there is no need for WTP. Since the Bluetooth baseband provides reliable transport, WTP could be omitted when Bluetooth is used as a bearer for WAP.
Figure 12–2 WAP on the Bluetooth protocol stack.
- WTLS (Wireless Transport Layer Security)—Provides security. This layer can be omitted for applications which do not require more security than the Bluetooth baseband provides.
The WAP layers are joined to Bluetooth by three Internet protocol layers, which allow datagrams to be sent across Bluetooth’s RFCOMM serial port emulation layer.
- UDP (User Datagram Protocol)—Provides unreliable, connectionless datagram transport.
- IP (Internet Protocol)—A protocol which supports addressing, routing, segmentation, and reassembly of packets.
- PPP (Point to point Protocol)—A client/server-based packet transport system commonly used on dial-up links to carry IP traffic.
12.3 PPP Links
PPP is used to carry packets from the higher IP and WAP layers across Bluetooth’s RFCOMM serial port emulation layer. RFC1661 describes PPP, and RFC1662 describes how it can be carried across High Level Data Link Control (HDLC) framing systems. (RFCOMM is an HDLC framing system.)
PPP encapsulates information for transmission in RFCOMM frames as shown in Figure 12–3.
The protocol field is used to identify what sort of PPP message is being sent. The categories for protocol are:
- 0x0001 Padding protocol.
- 0xC021 Link Control Protocol (LCP).
- 0xC023 Password Authentication protocol.
- 0xC025 Link Quality Report.
- 0xC223 Challenge Handshake Authentication protocol.
The information field is used to carry the datagrams, which are transferred across a PPP link. The datagrams can be information from UDP and above, or they can be encapsulated PPP control packets. For instance, a single PPP link control protocol packet can be transferred in the information field.
The information field can be missing. PPP has a Maximum Receive Unit (MRU); the padding field can be used to round up the length of the packet to the MRU, but it is not compulsory to use padding.
12.3.1 PPP Link Control Protocol
The Link Control Protocol (LCP) configures and controls PPP links. A single LCP packet is encapsulated in the information field of a PPP frame. The structure of an LCP packet is shown in Figure 12–4.
The code field is a single byte, and identifies the type of LCP packet. The possible types are:
- 0x01 Configure-Request—Used to send options for use on a link.
- 0x02 Configure-Ack—Acknowledges Configure-Request if options are acceptable.
- 0x03 Configure-Nak—Replies to Configure-Request if some options not acceptable; the Configure-Nak specifies new options.
- 0x04 Configure-Reject—Replies to a Configure-Request if options are unrecognisable, or if the responder does not wish to negotiate the options.
- 0x05 Terminate-Request—Used to request shut down of a PPP link.
Figure 12–3 Structure of PPP encapsulation.
Figure 12–4 Structure of a PPP LCP packet.
- 0x06 Terminate-Ack—Acknowledges that the link is to be shut down.
- 0x07 Code-Reject—Used to reject a PPP LCP packet with an unrecognised code.
- 0x08 Protocol-Reject—Used to reject a PPP packet with an unrecognised protocol field.
- 0x09 Echo-Request—Requests an Echo-Reply to test the link.
- 0x0A Echo-Reply—Responds to an Echo-Request.
- 0x0B Discard-Request—These packets are discarded on reception; they are provided for debug and test purposes.
The identifier field is a single byte used to match up requests and replies. Response packets carry an identifier value copied from the request packet they are answering.
The length field is two bytes, which gives the total length of the LCP packet, including code, identifier length, and data fields.
To set up a PPP link first, an RFCOMM connection is established (see Figure 12–5). Then each side sends LCP packets for link test and configuration. Parameters which can be configured are:
- Maximum-Receive-Unit—The maximum length of a PPP information field; defaults to 1500 bytes.
- Authentication-Protocol—The protocol for authentication; either password authentication protocol or challenge handshake authentication protocol can be used.
- Quality-Protocol—Whether a quality monitoring protocol will be used to determine whether the link is dropping packets (this should not be needed on Bluetooth as the baseband links are reliable).
- Magic-Number—Random number used to detect looped back links.
- Protocol-Field-Compression—Can be used to select different lengths of protocol field in PPP packets.
Figure 12–5 Message sequence chart for setting up a PPP link.
- Address-and-Control-Field-Compression—Used to negotiate compression of the address and control fields of the data link layer.
After configuration, packets can then be sent across the link, which configures the higher layer protocols that are using the link (IP and WAP protocol layers).
12.3.2 PPP States
PPP links have various states. LCP messages and authorisation messages move the links between the states. Figure 12–6 shows the states of a PPP link.
The link begins in the dead state. Exchange of configuration messages is carried out in the establish state, which opens the link.
Authentication is not mandatory, but if it is being done, it is the next phase. If it succeeds or if there is no authentication, the PPP link goes to the network state, where data is transferred. If authentication fails, the link is taken straight to a terminate state, which shuts it down. The link also goes through the terminate state when the link is being shut down.
Figure 12–6 State transition diagram for a PPP link.
12.4 Wap Clients And Servers
WAP uses a client/server architecture. Typically a WAP client will be a mobile device with lower bandwidth links than one would find on wired devices such as networked PCs. Because of their low bandwidth links, WAP content is communicated in a compact encoded format.
WAP supports Wireless Markup Language (WML), which is similar to the Hypertext Markup Language (HTML) that is used to encode Web pages. Both WML and HTML are derived from a set of rules for producing markup languages called XML. The two have so many elements in common that it is possible to produce a Web page that could be read by both a WML browser and an HTML browser. However, WML has been designed to suit the capabilities of mobile devices with limited screen sizes.
WAP clients can talk to WAP servers which hold WML pages in plain text format. When a WAP client requests a page from a WAP server, it is put through a content encoder, then sent to the WAP client in the compact encoded format. The encoding converts the page into a series of tokens, which provide a shorter representation than the human-readable text form of the page.
In addition to Wireless Markup Language (WML), the WAP standard defines a format for simple bitmap images, called WBMP (Wireless Bitmap), and a scripting language which can be used to run programs on a WAP client called WMLscript. WMLscript is comparable to JavaScript and allows WAP pages to initiate actions on the device displaying them.
Figure 12–7 shows a closed system where the WAP client can only see one WAP server. This is typically found in high security situations such as banking. However, most WAP clients will wish to retrieve files from servers on the Internet. Devices called gateways are used to access files from Internet servers. Figure 12–8 shows a WAP client accessing files from a WAP server, which is also a WAP gateway.
When the WAP client requests a file which is on the WAP gateway/server, the request is routed up the WAP stack to the user agent. This takes the request for a URL, realises that it refers to a local file, and routes it as a file request to the local file store.
Figure 12–7 Retrieving WAP content from a WAP server.
The file store returns its content, which the user agent directs to a MIME type switch. If the content is WAP content (WML, WMLScript, WBMP), then it is sent to the encoder/decoder to be converted into compact encoded format for transmission on air. From the encoder/decoder, the content is sent down the WAP stack for transmission to the client.
When the WAP client requests a file which is on a remote server, the request is routed up the WAP stack to the user agent. This takes the request for a URL, realises that it refers to a remote URL, and performs DNS (Domain Name Server) resolution. DNS resolution involves taking the URL, which is made up of a file location and a domain name, and resolving the domain name to an Internet address.
For example, <http://www.Bluetooth.com> resolves to the Internet address 192.36.140.2, which is the address of a server. The file part of the location can be routed to this server via the WAP server’s/gateway’s IP stack.
The origin server, which has the URL, routes the request to its user agent, which retrieves the content from its file store and sends the reply back down the origin server’s IP stack. The content is passed up the WAP server’s/gateway’s IP stack, and into the MIME type switch. If it is WAP content, it will be encoded for transmission to the WAP client in compact format. If it is nonWAP content, it cannot be tokenized by the encoder/decoder so it will have to be transmitted in its raw format. Either way, the content is transmitted down the WAP server’s/gateway’s stack to be sent to the WAP client.
The gateway is performing two services:
- It is receiving on an IP stack and transmitting on a WAP stack with Bluetooth as its bearer layer.
- It is encoding WAP content into a compact format for transmission, whether this is local WAP content or WAP content received from remote servers.
12.5 Suspend And Resume
WAP provides suspend and resume facilities, which might be used to halt a WAP session temporarily if a WAP client with a Bluetooth bearer layer moved out of range of its server. However, implementers should be aware that not all versions of WAP can suspend cleanly when the bearer layer fails.
The Bluetooth specification also suggests that clients with multiple protocol stacks (such as GSM handsets with Bluetooth capabilities) could connect to WAP servers via more than one stack. If such a device connected over Bluetooth, it could retrieve the information necessary to connect to the server via another WAP bearer, then if the client lost its Bluetooth bearer, it could resume the session using the alternate bearer. Again, implementers should be aware that not all versions of WAP may support this functionality, so it may be necessary for the WAP application to completely shut down the WAP session and restart it on the alternate bearer.
12.5.1 Server Push
Most communications protocols rely on client pull, that is to say, the client requests data from the server. WAP supports server push, where the server initiates transactions actively, sending out data to all clients in an area. There are many applications for server push—for example, database updates can be pushed out from a desktop to a PDA, or advertisements could be pushed out from a shop to passing Bluetooth devices with WAP clients.
Of course, once you’re considering server push, there are huge security implications. Without security, a WAP server could push code for execution onto your device—it could pull off your confidential information, or it could instruct your Bluetooth enabled phone to run up a huge bill calling a high rate off-shore sex line! To avoid this, the Blue-tooth bearer layer uses encryption and authentication, so some authenticating PIN number must be entered into the WAP client and server before they can communicate.
Version 1.0b of the Bluetooth specification references WAP version 1.0. At this level of the standard, the server push facilities were not fully defined throughout the WAP stack. Version 1.3 of WAP introduced the WAP push architecture with support throughout the WAP stack, so work remains to be done before Bluetooth devices can fully take advantage of server push.
12.6 Service Discovery
A WAP client using Bluetooth as a WAP bearer layer which wants to connect to a WAP server first has to find the server. It could be preconfigured with the Bluetooth device address of a WAP server in range, or it could find it by conducting an inquiry, then use service discovery to find a WAP server.
Even if the WAP client has been preconfigured with the Bluetooth device address of the WAP client, it will still need to use SDP to find the RFCOMM server number the WAP client has allocated to WAP services. The WAP server’s service discovery record will also identify whether the server is a proxy (used to access files on other devices), an origin server (provides its own files), or both. A home URL, the page to begin browsing at, is provided. A service name, for instance “train timetable information,” is provided. A set of parameters needed to connect to the WAP service are given; these are the port numbers allocated to the various layers of the WAP stack.
Once the service discovery information has been retrieved, an L2CAP link for RFCOMM is established, and a WSP session is set up over this link. Finally, URLs can be requested by WAE across WSP.
Figure 12–9 shows the process of establishing a link between WAP client and server. If the link was established to retrieve information directly from the local WAP server, the first URL requested would be the home URL of the WAP server. The home URL is passed from server to client in the WAP server’s service record.
12.7 Wap Interoperability
Just as the Bluetooth SIG arranges for Bluetooth qualification testing, the WAP forum has compliance specifications and test suites.
12.8 Using Wap
WAP implementations supporting server push allow smart servers to announce themselves to passersby. The owner of a WAP-enabled PDA could walk into a waiting room, get out the PDA to check appointments, and have a message from a LAN access point pop up, offering to connect to timetable information. Clicking on yes, up pops a page with hypertext links guiding around arrivals and departures. Of course, if all this information isn’t wanted, there is always the option of making a Bluetooth device nondiscoverable so it doesn’t answer inquiries from the local WAP servers, and they don’t know it’s there. Or to still allow connection to other devices, applications can be set to refuse contacts from WAP servers that haven’t been preauthorised.
Figure 12–9 Establishing a WSP session and retrieving WAP content.
Another use for server push is setting up personal devices to automatically synchronise with one another. For example, when a user’s WAP-enabled phone gets within Blue-tooth range of the same user’s WAP-enabled PC, it automatically initiates a link, transferring its up-to-date phone book information. Once the user has installed and configured the applications, it all happens automatically without further intervention.
The combination of Bluetooth wireless technology and WAP data transfer technology provides the potential for local data transfer in new environments. There are many cases where local short range information transfer is useful, and the limited range of Blue-tooth links can be an asset, ensuring that the information transferred is relevant to the environment. For example, tourist information from a local WAP kiosk could be automatically tailored to the location of the user, whereas tourist information transferred from a more remote server might not be so relevant.
12.9 Summary
WAP (Wireless Application Protocol) is defined and promoted by the WAP forum, which organisations may join for an annual fee.
WAP provides a protocol stack similar to the IP (Internet Protocol) stack, but it is tailored for the needs of mobile devices. It caters to the limited display size and resolution typically found on mobile devices by providing special formats for Web pages which suit their capabilities. It also provides for the low bandwidth of mobile devices by defining a method for WAP content to be compressed before it is transferred across a wireless link.
The WAP stack can be used to transfer files which do not have WAP content, but when nonWAP content is transferred, it cannot be compressed.
Version 1.3 of WAP supports server push, which allows a WAP server to initiate a transfer of information to a device.
WAP can use Bluetooth as a bearer layer in the same way as it can use GSM, CDMA, and other wireless services. The WAP stack is joined to the Bluetooth stack using UDP, IP, and PPP.