WML environment
Within WAP1, WML (Wireless Markup Language) is the presentation layer on the top of the WAP stack. Under WML it is the Wireless Application Environment (WAE) that implements the presentation of WML pages in the mobile browser. Some WAEs may have support for telephony functions, using the Wireless Telephony Application (WTA) to implement this functionality. WTA telephony functions can include, for example, the ability to call a phone number from the WAP browser and store it in the phonebook of the mobile.
WAP protocols
The other part of the WAP standard is the WAP protocols where two versions exist, WAP1 being the old standard and WAP2 the current. WAP protocols are designed for optimized data transport performance over mobile network protocols. WAP protocols are mobile network independent and work on top of different mobile networks such as GPRS, EDGE and WCDMA (similar to JAVA that works independently on top of different platforms). WAP protocols are complete binary-based protocols. But web servers do not support WAP protocols, so this is one reason for using WAP gateways/proxies like Ericsson Mobile Internet Enabling Proxy (MIEP). A WAP gateway/proxy can work as a protocol converter between WAP protocols and common HTTP/TCP towards web servers on the internet.
WAP1 protocols
According to the WAP1 standard, the following protocols are used between a WAP-enabled mobile and a WAP gateway/proxy:
- Wireless Session Protocol (WSP) is used for the WAP connection towards the mobile (not the same as an HTTP session). Two modes can be used through a WAP browser connection-oriented mode and connectionless mode. Connectionless mode is based directly on Wireless datagram Protocol (WDP) and has a lower overhead.
- Wireless Transaction Protocol (WTP) is a lightweight transaction protocol for connection-oriented services.
- Wireless Transport Layer Security (WTLS) handles the communication security such as authentication and encryption.
- Wireless Datagram Protocol (WDP) makes the WAP stack adaptation to the common internet User Datagram Protocol (UDP).
WAP2 protocols
WAP2 is more similar to the common internet protocol HTTP/TCP than WAP1. Mobiles with support for WML2 and XHTML-MP also have support for WAP2 protocols. The difference between the WAP1 and WAP2 stacks is that WAP2 uses Wireless Profiled Hypertext Transfer Protocol (W-HTTP) and TCP to communicate with WAP proxies.
A key feature of WAP2 is the introduction of internet protocols into the WAP environment, enabling HTTP (Hyper Text Transfer Protocol) over TCP/IP to be used all the way to the wireless device. This support has been motivated by the emergence of high-speed wireless networks, for example, 2.5G and 3G.
When a WAP proxy, like Ericsson's MIEP, receives a HTTP request, it forwards the headers and content via the W-HTTP stack to the Pull Proxy layer, where the request is handled in the same way as a WSP request. HTTP is a request/response protocol that operates above TCP/IP. Due to the three-way handshake of the TCP, there is a considerable delay in establishing each new connection. TCP connections are therefore reused to reduce the load caused by creating and closing connections. To reduce latency further, pipelining is supported with persistent connections. Pipelining means that the next request is sent over the persistent connection before the previous response has been fully received. Pipelining considerably improves the round-trip time and performance, and most WAP2 mobiles are set to use HTTP pipelining as their first choice when accessing Ericsson's MIEP WAP proxy.
WAP Push
WAP Push is a function in a WAP Gateway/Proxy that enables applications (Origin Server) to send information to a WAP end-user with no previous user action required.
Push messages open up possibilities for new applications where end-users can receive useful information. Examples of push applications include stock notification ("Your stock has exceeded a threshold value, do you want to sell?") or public transportation notification ("traffic congestion is causing delays"). Push applications need to implement the Push Access Protocol (PAP). This means that the application includes a Push Initiator (PI) that is responsible for communicating with the Push Proxy Gateway (PPG). The PI transmits the Push content and delivery instructions to the PPG using PAP. The PPG then uses the Push Over-The-Air (OTA) protocol to deliver the content to the WAP terminal or mobile.
A PI can address a mobile by its MSISDN (mobile number), WAP user id or IP address.
Push can be done in two ways:
- Push over IP. Useful for push applications with high real-time requirements, for example chat applications.
- Push over SMS. Needed when pushing to a WAP mobile that has no IP connectivity.
WAP infrastructure
Where is the WAP gateway located?
A WAP gateway/proxy is a service enabler that is normally located in the service layer, between internet and mobile networks. The service layer consists of many other service enablers for internet mobile applications such as charging systems and mobile positioning systems. The WAP protocol runs like a tunnel from the mobile via radio waves towards the connectivity layer, the control layer and finally the service layer.
A WAP gateway/proxy in the service layer is operated by the mobile network operator. Other WAP gateways/proxies on the public internet can be used as gateways for web servers or by application developers for testing purposes.
In the figure you can see how the IP traffic is transported from a mobile device to an application server located on the internet over a GPRS network (2.5G). Normally, all IP packets from a mobile device are transported and controlled via three layers of networks before reaching an internet mobile or web application: the connectivity layer, consisting of the Radio Access Network (RAN); the control layer, consisting of the Core Network (CN); and the service layer, which consists of the Service Network (SN).
Because IP-package frames were not designed to be carried over radio protocols, the WAP protocol is the most effective way for using GPRS (General Packet Radio Services) to transport presentation information in an IP packet to a server-side application over a mobile network. The WAP protocol is independent of types of the mobile network, such as GPRS /GSM and WCDMA (Wideband Code Division Multiple Access).
As you can see in the figure, IP packets are transported over a stack of underlying mobile protocols such as MAC, RLC, LLC, SNDCP and X25. The IP transport for GPRS travels from the antenna to the Base Transceiver Station (BTS) to the Base Station Controller (BSC) and is then transferred from the connectivity layer to the control layer.
The Serving GPRS Support Node (SGSN) in the control layer provides packet routing from the SGSN service area. The SGSN also provides ciphering/authentication, mobility management, session management and more for the mobile IP network.
SGSNs are also the connection points towards the BSC, Home Location Register (HLR), the Mobile Switching Center (MSC) and the Gateway GPRS Support Node (GGSN). GGSN is a gateway router that routes IP traffic to the service layer or different internet services provider’s networks (public ISP or corporate intranet for enterprise applications). The GGSN uses Remote Authentication Dial-In User Service (RADIUS) for authentication towards ISPs. RADIUS is an Internet Engineering Task Force (IETF) standard for authentication with other IP networks.
Within the service layer, WAP/IP traffic is transported from the client side mobile device, via a WAP gateway/proxy, towards the server side Java EE web container that runs the application. The WAP gateway/proxy translates the binary WAP protocol to Hypertext Transfer Protocol (HTTP), which allows the mobile device to access for instance a Java EE web container on the internet, because the web container only accepts HTTP requests. WAP 2.0 enabled mobile devices, however – for instance smart phones – can communicate with a WAP/web application via a WAP proxy without specific settings in the mobile.
Cookie and WAP
Not all mobiles have support for cookie technique; such support requires WAP. Without cookies the session handling in your WAP application might be difficult or impossible, because a Java EE web container cannot write and receive the Session ID (via HTTP) from the mobile. Session ID must be written on the mobile phone, or for WAP1 phones temporarily stored in the WAP gateway, to keep track of the HTTP session towards the web container. The session ID in the cookie can then be mapped to the session object in the web container.
By using so called URL-rewriting technique you can solve the problem with lacking cookie support. WAP gateways, like Ericsson MIEP, can act as a cookie proxy for WAP-enabled mobiles that have no support for cookies. To make URL-rewriting work, the web container must have support for URL-rewriting. The following Java EE web container method can be used to support URL-rewriting:
public String encodeURL(String url)
The method encodes the specified URL by including the session ID in it. The method is a part of the ServletResponse interface.
By always using URL-rewriting will let the Java EE web container decide if it should use rewriting or not, you avoid problems with mobiles lacking support for cookies.
