To support WAP services with Bluetooth in the Client/Server environment, the client and the server have to run the protocol stack, as shown in Figure 8-2.
Because the mobile device can be a high-end device, such as a laptop, or a low-end device, such as a cellular phone, the stack shown in Figure 8-2 is very generic in order to accommodate a variety of mobile devices. The following is a brief description of each of the layers:
♦ Baseband/Link Manager Protocol (LMP) takes care of link management over the radio. This layer establishes the Bluetooth link, and the messages exchanged between the Bluetooth modules are not passed to the higher layers.
♦ Logical Link Control and Adaptation Protocol (L2CAP) assumes that a Bluetooth link is already established between two devices (in this case, the client and the server) and identifies the higher layer to which the messages have to be passed on (for example, SDP or RFCOMM) In other words, this layer carries out protocol multiplexing.
♦ Service Discovery Protocol (SDP) locates the services provided by other Bluetooth devices. These devices exchange SDP messages to discover the services of each other. One of the devices sends an SDP request and the other sends an SDP response. The responses are in the form of service records, which contain the details of the service. Either the WAP server or the mobile device can send the request and obtain the response. For push applications, the WAP server sends the SDP request to the mobile device and obtains the response. For pull applications, the mobile device sends the SDP request and obtains the response.
Figure 8-2: Protocol stack on Client and Server for WAP with Bluetooth
♦ RFCOMM is the transport protocol that emulates the RS 232 serial port, meaning we can assume that the communication between the mobile device and the server is in the form of serial
communication without the cable.
♦ Point to Point Protocol (PPP) is the protocol used for dial-up lines to transport packet data from higher layers across the Bluetooth RFCOMM serial port emulator. Because we are emulating the serial communication dial up through RFCOMM, this protocol is required.
♦ Internet Protocol (IP) is the protocol that takes care of the addressing and routing on the Internet. Every device connected to the Internet is given an IP address. Every packet contains the source IP address and the destination IP address. The destination IP address is used to route the packets to the correct destination.
♦ User Datagram Protocol (UDP) is the transport layer protocol. Unlike Transmission Control Protocol (TCP) that uses connection-oriented service, UDP uses connectionless service. The advantage of UDP is its low protocol overhead as compared to TCP. However, the service is unreliable as packets may be lost.
♦ Wireless Datagram Protocol (WDP) is the transport layer equivalent of UDP, which is the transport layer protocol in the WAP stack.
♦ Wireless Transport Layer Security (WTLS) is the optional security layer of the WAP stack. This layer provides the optional functionality of authentication and encryption for applications that require secure communication.
♦ Wireless Transaction Protocol (WTP) and Wireless Session Protocol (WSP) together provide the HTTP functionality in the WAP environment. These protocols establish a session and communicate with the WAP server/gateway for obtaining the information. They then present the information to the user through the Wireless Application Environment (WAE), which has a micro-browser to interpret the WML content.
♦ However, note that the WAP services can also be provided through Short Messaging Service (SMS). In such a case, there is no need to run the IP and UDP protocols. The Wireless Datagram Protocol (WDP) can run on the SMS bearer. If security above WDP is required, the Wireless Transaction Layer Security (WTLS) layer is run (note that this is only an optional layer). Above WTLS, Wireless Transaction Protocol (WTP) and Wireless Session Protocol (WSP) may be run. Figure 8-3 shows the complete protocol stacks that run on the WAP server/gateway and the Origin server to provide WAP services with Bluetooth.
Figure 8-3: Protocol Stack on WAP Gateway and Origin server for WAP services with Bluetooth
The WAP client sends a request in the form of a URL through the Bluetooth bearer (over the radio link) to the WAP gateway. The Bluetooth-enabled WAP gateway receives the request. If the request
corresponds to the content that is available locally on the WAP server, it will fetch the WML content, encode it in binary format, and send it to the client. If the content is not available locally, the WAP server contacts the Origin server through HTTP protocol, obtains the content, and sends it to the client. Because the Origin server has the TCP/IP protocol stack, the WAP server has to do the necessary protocol
conversion. If the Origin server sends the content in HTML instead of the WML format, the WAP gateway has to convert the content into WML format, do the encoding of the content, and send it to the mobile device over the Bluetooth bearer. For the WAP gateway to send the URL request to the right Origin server, the URL has to be mapped to the IP address, which is done by a Domain Name Server (DNS). Thus, one of the requirements for the WAP gateway is to have the capability of the DNS address mapping.