Wireless Application Protocol(WAP)
WAP is an open international standard for applications that use wireless communication. Its principal application is to enable access to the Internet from a mobile phone or PDA. A WAP browser provides all of the basic services of a computer based web browser but simplified to operate within the restrictions of a mobile phone, such as it's smaller view screen. The Japanese i-mode system is another major competing wireless data protocol.
WAP sites are websites written in, or dynamically converted to, WML (Wireless Markup Language) and accessed via the WAP browser. Currently, there are WAP site authoring tools accessible to many countries - tagtag.com (hosted in Slovenia), wapple.net (England U.K.), all2wap.com (Switzerland) and celladmin.com (Israel).
Before the introduction of WAP, service providers had extremely limited opportunities to offer interactive data services. Interactive data applications are required to support now commonplace activities such as:
Email by mobile phone
Tracking of stock market prices
Sports results
News headlines
Music downloads
Contents [hide]
1 Technical specifications
1.1 Wireless Application Environment (WAE)
2 Maintenance and evolutions
2.1 WAP 2.0
2.2 WAP Push
3 Commercial status
3.1 Possible failure
4 Protocol design lessons from WAP
5 See also
6 External links
[edit] Technical specifications
wap is a protocol for wireless devices like multi media mobile
The bottom-most protocol in the suite is the WAP Datagram Protocol (WDP), which is an adaptation layer that makes every data network look a bit like UDP to the upper layers by providing unreliable transport of data with two 16-bit port numbers (origin and destination). WDP is considered by all the upper layers as one and the same protocol, which has several "technical realizations" on top of other "data bearers" such as SMS, USSD, etc. On native IP bearers such as GPRS, UMTS packet-radio service, or PPP on top of a circuit-switched data connection, WDP is in fact exactly UDP.
WTLS provides a public-key cryptography-based security mechanism similar to TLS. Its use is optional.
WTP provides transaction support (reliable request/response) that is adapted to the wireless world. WTP supports more effectively than TCP the problem of packet loss, which is common in 2G wireless technologies in most radio conditions, but is misinterpreted by TCP as network congestion.
Finally, WSP is best thought of on first approach as a compressed version of HTTP.
This protocol suite allows a terminal to emit requests that have an HTTP or HTTPS equivalent to a WAP gateway; the gateway translates requests into plain HTTP.
[edit] Wireless Application Environment (WAE)
In this space, application-specific markup languages are defined.
The primary language of the WAE is WML, the Wireless Markup Language, which has been designed from scratch for handheld devices with phone-specific features.
[edit] Maintenance and evolutions
The WAP Forum has consolidated (along with many other forums of the industry) into OMA (Open Mobile Alliance), which covers virtually everything in future development of wireless data services.
[edit] WAP 2.0
WAP 2.0 is a re-engineering of WAP using a cut-down version of XHTML with end-to-end HTTP (i.e., dropping the gateway and custom protocol suite used to communicate with it). A WAP gateway can be used in conjunction with WAP 2.0; however, in this scenario, it is used as a standard proxy server. The WAP gateway's role would then shift from one of translation to adding additional information to each request. This would be configured by the operator and could include telephone numbers, location, billing information, and handset information.
XHTML Mobile Profile (XHTML MP), the markup language defined in WAP 2.0, is made to work in mobile devices. It is a subset of XHTML and a superset of XHTML Basic. A version of cascading style sheets (CSS) called WAP CSS is supported by XHTML MP.
[edit] WAP Push
WAP Push, has been incorporated into the specification to allow WAP content to be pushed to the mobile handset with minimum user intervention. A WAP Push is basically a specially encoded message which includes a link to a WAP address. WAP Push is specified on top of WDP; as such, it can be delivered over any WDP-supported bearer, such as GPRS or SMS.
In most GSM networks there are a wide range of modified processors, however, GPRS activation from the network is not generally supported, so WAP Push messages have to be delivered on top of the SMS bearer. On receiving a WAP Push, a WAP 1.2 or later enabled handset will automatically give the user the option to access the WAP content. This is also known as WAP Push SI (Service Indication).
The network entity that processes WAP Pushes and delivers them over an IP or SMS Bearer is known as a Push Proxy Gateway.
[edit] Commercial status
This article or section may contain original research or unverified claims.
Please improve the article by adding references. See the talk page for details. (January 2008)
[edit] Possible failure
WAP was hyped at the time of its introduction, leading users to expect WAP to have the performance of the Web. One telco's advertising campaign depicted a cartoon WAP user surfing through a Neuromancer-like "information space". In terms of speed, ease of use, appearance, and interoperability, the reality fell far short of expectations. This led to the wide usage of sardonic phrases such as "Worthless Application Protocol", "Wait And Pay", and so on.
Critics advanced several explanations for the early failure of WAP, possibly not realizing that it was a United Kingdom product which had to comply with the laws of European nations. An example is the requirement to utilize an ITU message-type that is specific to the French language with appropriate character conversions being deployed by the WAP message transmit and receive software [some comments in this and later sections are provided by the WAP inventor, Trevor Cutler of England]. Some are technical criticisms:
The idiosyncratic WML language, which cut users off from the true HTML Web, leaving only native WAP content and Web-to-WAP "proxified" content available to WAP users. However, others argue that technology at that stage would simply not have been able to give access to anything but custom-designed content which was the sole purpose of WAP and its simple, reduced complexity interface as the citizens of many nations are not connected to the web at the present time and have to use government funded and controlled portals to WAP and similar non-complex services.
Under-specification of terminal requirements. In the early WAP standards, there were many optional features and under-specified requirements, which meant that compliant devices would not necessarily interoperate properly. This resulted in great variability in the actual behavior of phones, principally because WAP service implementers and mobile phone manufacturers did not obtain a copy of the standards or the correct hardware and the standard software modules. As an example, some phone models would not accept a page more than 1 Kb in size; others would downright crash. The user interface of devices was also underspecified: as an example, accesskeys (e.g., the ability to press '4' to access directly the fourth link in a list) were variously implemented depending on phone models (sometimes with the accesskey number automatically displayed by the browser next to the link, sometimes without it, and sometimes accesskeys were not implemented at all).
Constrained user interface capabilities. Terminals with small black and white screens and few buttons, as the early WAP terminals were, are not very apt at presenting a lot of information to their user, which compounded the other problems: one would have had to be extra careful in designing the user interface on such a resource-constrained device which was the real concept of WAP.
Lack of good authoring tools. The problems above might have been alleviated by a WML authoring tool that would have allowed content providers to easily publish content that would interoperate flawlessly with many models, adapting the pages presented to the User-Agent type. However, the development kits which existed did not provide such a general capability. Developing for the web was easy: with a text editor and a web browser, anybody could get started, thanks also to the forgiving nature of most desktop browser rendering engines. By contrast, the stringent requirements of the WML specifications, the variability in terminals, and the demands of testing on various wireless terminals, along with the lack of widely available desktop authoring and emulation tools, considerably lengthened the time required to complete most projects. However, with many mobile devices now supporting xHTML, and programs such as Adobe Go Live and Dreamweaver offering improved web authoring tools, it is becoming easier to create content, accessible by many new devices.
No good user agent profiling tools. It quickly became nearly impossible for web hosts to determine if a request came from a mobile device, or a larger more capable device. No useful profiling or database of device capabilities were built into the specifications in the unauthorized non-compliant products.
Other criticisms are oriented towards the wireless carriers' particular implementations of WAP:
Neglect of content providers. Some wireless carriers had assumed a "build it and they will come" strategy, meaning that they would just provide the transport of data as well as the terminals, and then wait for content providers to publish their services on the Internet and make their investment in WAP useful. However, content providers received little help or incentive to go through the complicated route of development. Others, notably in Japan (cf. below), had a more thorough dialogue with their content provider community, which was then replicated in modern, more successful WAP services such as i-mode in Japan or the Gallery service in France.
Lack of openness. Many wireless carriers sold their WAP services that were "open", in that they allowed users to reach any service expressed in WML and published on the Internet. However, they also made sure that the first page that clients accessed was their own "wireless portal", which they controlled very closely. Some carriers also turned off editing or accessing the address bar in the device's browser. To facilitate users wanting to go off deck, an address bar on a form on a page linked off the hard coded home page page was provided. It makes it easier for carriers to implement filtering of off deck WML sites by URLs or to disable the address bar in the future if the carrier decides to switch all users to a walled garden model. Given the difficulty in typing up fully qualified URLs on a phone keyboard, most users would give up going "off portal" or out of the walled garden; by not letting third parties put their own entries on the operators' wireless portal, some contend that operators cut themselves off from a valuable opportunity. On the other hand, some operators argue that their customers would have wanted them to manage the experience and, on such a constrained device, avoid giving access to too many services.
[edit] Protocol design lessons from WAP
The original WAP was a simple platform for access to web-like WML services and e-mail using mobile phones in Europe and the SE Asian regions and continues today with a considerable user base. The later versions of WAP were primarily for the United States region and was designed for a different requirement - to enable full web XHTML access using mobile devices with a higher specification and cost, and with a higher degree of software complexity.
There has been considerable discussion about whether the WAP protocol design was appropriate. Some have suggested that the bandwidth-sparing simple interface of Gopher would be a better match for mobile phones and Personal digital assistants (PDAs).
The initial design of WAP was specifically aimed at protocol independence across a range of different protocols (SMS, IP over PPP over a circuit switched bearer, IP over GPRS, etc). This has led to a protocol considerably more complex than an approach directly over IP might have caused.
Most controversial, especially for many from the IP side, was the design of WAP over IP. WAP's transmission layer protocol, WTP, uses its own retransmission mechanisms over UDP to attempt to solve the problem of inadequacy using TCP over high packet loss networks.
[edit] See also
.mobi
i-mode
Microbrowser
Wireless transaction protocol
Wikipedia access via WAP
Mobile development
Mobile web
[edit] External links
BWap.ORG - BWap.ORG community and downloads portal
infoWAP.info - create free statistics counter for WAP sites
Wap Community Site
Mobility.mobi - WAP Forum
Wap-2-Go Mobile CMS - WAP/Nuke CMS Project
WAP Specifications
WAP Forum White Paper: WAP 2.0
WAP - Directory & Informational Resource
MobileMultimedia WAP phone repository with all handset specifications
WAP sites are websites written in, or dynamically converted to, WML (Wireless Markup Language) and accessed via the WAP browser. Currently, there are WAP site authoring tools accessible to many countries - tagtag.com (hosted in Slovenia), wapple.net (England U.K.), all2wap.com (Switzerland) and celladmin.com (Israel).
Before the introduction of WAP, service providers had extremely limited opportunities to offer interactive data services. Interactive data applications are required to support now commonplace activities such as:
Email by mobile phone
Tracking of stock market prices
Sports results
News headlines
Music downloads
Contents [hide]
1 Technical specifications
1.1 Wireless Application Environment (WAE)
2 Maintenance and evolutions
2.1 WAP 2.0
2.2 WAP Push
3 Commercial status
3.1 Possible failure
4 Protocol design lessons from WAP
5 See also
6 External links
[edit] Technical specifications
wap is a protocol for wireless devices like multi media mobile
The bottom-most protocol in the suite is the WAP Datagram Protocol (WDP), which is an adaptation layer that makes every data network look a bit like UDP to the upper layers by providing unreliable transport of data with two 16-bit port numbers (origin and destination). WDP is considered by all the upper layers as one and the same protocol, which has several "technical realizations" on top of other "data bearers" such as SMS, USSD, etc. On native IP bearers such as GPRS, UMTS packet-radio service, or PPP on top of a circuit-switched data connection, WDP is in fact exactly UDP.
WTLS provides a public-key cryptography-based security mechanism similar to TLS. Its use is optional.
WTP provides transaction support (reliable request/response) that is adapted to the wireless world. WTP supports more effectively than TCP the problem of packet loss, which is common in 2G wireless technologies in most radio conditions, but is misinterpreted by TCP as network congestion.
Finally, WSP is best thought of on first approach as a compressed version of HTTP.
This protocol suite allows a terminal to emit requests that have an HTTP or HTTPS equivalent to a WAP gateway; the gateway translates requests into plain HTTP.
[edit] Wireless Application Environment (WAE)
In this space, application-specific markup languages are defined.
The primary language of the WAE is WML, the Wireless Markup Language, which has been designed from scratch for handheld devices with phone-specific features.
[edit] Maintenance and evolutions
The WAP Forum has consolidated (along with many other forums of the industry) into OMA (Open Mobile Alliance), which covers virtually everything in future development of wireless data services.
[edit] WAP 2.0
WAP 2.0 is a re-engineering of WAP using a cut-down version of XHTML with end-to-end HTTP (i.e., dropping the gateway and custom protocol suite used to communicate with it). A WAP gateway can be used in conjunction with WAP 2.0; however, in this scenario, it is used as a standard proxy server. The WAP gateway's role would then shift from one of translation to adding additional information to each request. This would be configured by the operator and could include telephone numbers, location, billing information, and handset information.
XHTML Mobile Profile (XHTML MP), the markup language defined in WAP 2.0, is made to work in mobile devices. It is a subset of XHTML and a superset of XHTML Basic. A version of cascading style sheets (CSS) called WAP CSS is supported by XHTML MP.
[edit] WAP Push
WAP Push, has been incorporated into the specification to allow WAP content to be pushed to the mobile handset with minimum user intervention. A WAP Push is basically a specially encoded message which includes a link to a WAP address. WAP Push is specified on top of WDP; as such, it can be delivered over any WDP-supported bearer, such as GPRS or SMS.
In most GSM networks there are a wide range of modified processors, however, GPRS activation from the network is not generally supported, so WAP Push messages have to be delivered on top of the SMS bearer. On receiving a WAP Push, a WAP 1.2 or later enabled handset will automatically give the user the option to access the WAP content. This is also known as WAP Push SI (Service Indication).
The network entity that processes WAP Pushes and delivers them over an IP or SMS Bearer is known as a Push Proxy Gateway.
[edit] Commercial status
This article or section may contain original research or unverified claims.
Please improve the article by adding references. See the talk page for details. (January 2008)
[edit] Possible failure
WAP was hyped at the time of its introduction, leading users to expect WAP to have the performance of the Web. One telco's advertising campaign depicted a cartoon WAP user surfing through a Neuromancer-like "information space". In terms of speed, ease of use, appearance, and interoperability, the reality fell far short of expectations. This led to the wide usage of sardonic phrases such as "Worthless Application Protocol", "Wait And Pay", and so on.
Critics advanced several explanations for the early failure of WAP, possibly not realizing that it was a United Kingdom product which had to comply with the laws of European nations. An example is the requirement to utilize an ITU message-type that is specific to the French language with appropriate character conversions being deployed by the WAP message transmit and receive software [some comments in this and later sections are provided by the WAP inventor, Trevor Cutler of England]. Some are technical criticisms:
The idiosyncratic WML language, which cut users off from the true HTML Web, leaving only native WAP content and Web-to-WAP "proxified" content available to WAP users. However, others argue that technology at that stage would simply not have been able to give access to anything but custom-designed content which was the sole purpose of WAP and its simple, reduced complexity interface as the citizens of many nations are not connected to the web at the present time and have to use government funded and controlled portals to WAP and similar non-complex services.
Under-specification of terminal requirements. In the early WAP standards, there were many optional features and under-specified requirements, which meant that compliant devices would not necessarily interoperate properly. This resulted in great variability in the actual behavior of phones, principally because WAP service implementers and mobile phone manufacturers did not obtain a copy of the standards or the correct hardware and the standard software modules. As an example, some phone models would not accept a page more than 1 Kb in size; others would downright crash. The user interface of devices was also underspecified: as an example, accesskeys (e.g., the ability to press '4' to access directly the fourth link in a list) were variously implemented depending on phone models (sometimes with the accesskey number automatically displayed by the browser next to the link, sometimes without it, and sometimes accesskeys were not implemented at all).
Constrained user interface capabilities. Terminals with small black and white screens and few buttons, as the early WAP terminals were, are not very apt at presenting a lot of information to their user, which compounded the other problems: one would have had to be extra careful in designing the user interface on such a resource-constrained device which was the real concept of WAP.
Lack of good authoring tools. The problems above might have been alleviated by a WML authoring tool that would have allowed content providers to easily publish content that would interoperate flawlessly with many models, adapting the pages presented to the User-Agent type. However, the development kits which existed did not provide such a general capability. Developing for the web was easy: with a text editor and a web browser, anybody could get started, thanks also to the forgiving nature of most desktop browser rendering engines. By contrast, the stringent requirements of the WML specifications, the variability in terminals, and the demands of testing on various wireless terminals, along with the lack of widely available desktop authoring and emulation tools, considerably lengthened the time required to complete most projects. However, with many mobile devices now supporting xHTML, and programs such as Adobe Go Live and Dreamweaver offering improved web authoring tools, it is becoming easier to create content, accessible by many new devices.
No good user agent profiling tools. It quickly became nearly impossible for web hosts to determine if a request came from a mobile device, or a larger more capable device. No useful profiling or database of device capabilities were built into the specifications in the unauthorized non-compliant products.
Other criticisms are oriented towards the wireless carriers' particular implementations of WAP:
Neglect of content providers. Some wireless carriers had assumed a "build it and they will come" strategy, meaning that they would just provide the transport of data as well as the terminals, and then wait for content providers to publish their services on the Internet and make their investment in WAP useful. However, content providers received little help or incentive to go through the complicated route of development. Others, notably in Japan (cf. below), had a more thorough dialogue with their content provider community, which was then replicated in modern, more successful WAP services such as i-mode in Japan or the Gallery service in France.
Lack of openness. Many wireless carriers sold their WAP services that were "open", in that they allowed users to reach any service expressed in WML and published on the Internet. However, they also made sure that the first page that clients accessed was their own "wireless portal", which they controlled very closely. Some carriers also turned off editing or accessing the address bar in the device's browser. To facilitate users wanting to go off deck, an address bar on a form on a page linked off the hard coded home page page was provided. It makes it easier for carriers to implement filtering of off deck WML sites by URLs or to disable the address bar in the future if the carrier decides to switch all users to a walled garden model. Given the difficulty in typing up fully qualified URLs on a phone keyboard, most users would give up going "off portal" or out of the walled garden; by not letting third parties put their own entries on the operators' wireless portal, some contend that operators cut themselves off from a valuable opportunity. On the other hand, some operators argue that their customers would have wanted them to manage the experience and, on such a constrained device, avoid giving access to too many services.
[edit] Protocol design lessons from WAP
The original WAP was a simple platform for access to web-like WML services and e-mail using mobile phones in Europe and the SE Asian regions and continues today with a considerable user base. The later versions of WAP were primarily for the United States region and was designed for a different requirement - to enable full web XHTML access using mobile devices with a higher specification and cost, and with a higher degree of software complexity.
There has been considerable discussion about whether the WAP protocol design was appropriate. Some have suggested that the bandwidth-sparing simple interface of Gopher would be a better match for mobile phones and Personal digital assistants (PDAs).
The initial design of WAP was specifically aimed at protocol independence across a range of different protocols (SMS, IP over PPP over a circuit switched bearer, IP over GPRS, etc). This has led to a protocol considerably more complex than an approach directly over IP might have caused.
Most controversial, especially for many from the IP side, was the design of WAP over IP. WAP's transmission layer protocol, WTP, uses its own retransmission mechanisms over UDP to attempt to solve the problem of inadequacy using TCP over high packet loss networks.
[edit] See also
.mobi
i-mode
Microbrowser
Wireless transaction protocol
Wikipedia access via WAP
Mobile development
Mobile web
[edit] External links
BWap.ORG - BWap.ORG community and downloads portal
infoWAP.info - create free statistics counter for WAP sites
Wap Community Site
Mobility.mobi - WAP Forum
Wap-2-Go Mobile CMS - WAP/Nuke CMS Project
WAP Specifications
WAP Forum White Paper: WAP 2.0
WAP - Directory & Informational Resource
MobileMultimedia WAP phone repository with all handset specifications
Comments