ISBN: 0-471-41405 -0
Download (direct link):
Public WTAs are likely to be the most frequently used, because they are the easiest to access for developers. Two such features are implemented in WAP 1.2.1: Make call and Send DTMF tones. Make call is exactly the feature that we illustrated in the previous example, where a user can call a number by simply selecting it in the WAP browser. DTMF tones are the tones that you generate as
Figure 7.6 WTA architecture.
you dial a phone number (might or might not be data-enabled) The Send DTMF tones imitate the feature that many call centers use today where you press a number to navigate a set of menu options.
Wireless Session Protocol (WSP)
Wireless Session Protocol (WSP) brings some of the key differences from the TCP/IP suite to the WAP table by introducing sessions and connections that have a client state. With the foreseen impact of personalized services of the mobile Internet, it was vital for the server/gateway end to keep a more lasting relationship with the client than what HTTP offers. The HTTP request/responses are forgotten as soon as they have been executed, and no permanent state is kept between the client and the server. This situation makes it hard to use variables and other state indicators that personalized services require. The most important difference between this solution and the Web solution with cookies is that cookies keep information about the user and the application while WSP keeps information about the connection and its properties. The information that cookies can hold (mostly personal information) should instead be handled in a more secure way, such as storing it on the userís SIM card.
The WSP state is also kept when the user is out of reach of the network (when the phone is turned off or is out of coverage). Suspending a request quickly and then resuming it when the user gets back into action again enables parameters and the client state to be kept. This suspend -resume functionality is also used when a user changes bearers. A user could use WAP over General Packet Radio Services (GPRS) and then suspend the session in order to establish an HSCSD call with a higher, fixed bit rate and then resume the WAP session. During the time that the session is suspended, it does not matter if the client changes IP addresses or keeps the old one. In fact, WSP is not reliant on lower layers of the protocol stack when suspended, which enables the device to run more efficiently and save battery power.
From WAP 1.2.1 on, WSP also has support for PUSH, which we also foresee as an important part of the mobile Internet. As GPRS is introduced and users are always online, this feature enables a server to give the user customized, situation -centric information. Say that you are arriving in a new city and you subscribe to a soccer information service. The server can then send a notice to you that there is a great game going on that night and enable you to purchase tickets on the spot. PUSH is already available in GSM as SMS, but GPRS introduces this feature to any IP-enabled device.
Although WSP differs in these matters from HTTP, it is largely a binary-encoded version of HTTP/1.1. The same GET and POST commands that we use on the Web are used here, but content is sent as binary ones and zeros instead of plain text. This feature dramatically reduces the amount of data that is sent over the air and increases the efficiency of WAP.
Because WSP uses headers that are well known to both the gateway and the client, you can encode them into short, binary sequences. This procedure can shrink 32 bytes in plain text into two bytes of encoded representation. This shrinkage saves important capacity over the wireless link, and as we will discuss in the next chapter, it probably also saves the users some money. This dramatic gain in capacity is not only due to the non-binary representation of HTTP headers but also results from avoiding the repeated static headers that HTTP uses. WSP reduces the amount of redundant information that is sent and minimizes overhead. When several packets of the same session are exchanged, WSP can also cache the used headers so that they are not sent to the user every time.
WSP offers the application two connection types: connection mode and connectionless. Both have their advantages and disadvantages, and it is up to the application to choose. Newer WAP browsers provide the option to choose between the two, which increases the developerís feeling for WAPís characteristics (to play around and switch between the two). The difference in handling interruptions is especially interesting, as we will see in the next chapter.
Connectionless WSP was the most commonly supported service in the first WAP phones because it is easier to implement. Connectionless WSP uses the same send-and-forget philosophy as UDP, where packets are not acknowledged. In fact, when running connectionless WSP over an IP bearer, UDP is used as a datagram service. Because there is no established session, more header information has to be included in each packet in order to route it correctly (which leads to higher protocol overhead).