Wireless Application Protocol#WAP Push

WAP Push is a system for distribution of various contents (content) from a server to a mobile device (client). The content is usually "pushed" in principle no initiative on the part of the client from the server to the mobile device. Therefore, the server assumes the initiative of the transmission and " pushes " the content to the client.

A so-called WAP push link that is sent via SMS to their mobile phone, leading to a WAP address, to which the cell phone to read SMS messages ( usually costs) dials, for example a product download. After Sweden, the UK and Australia in 2006 were also in Germany and Austria such advertising messages on.

Reasons for the development of WAP Push

WAP Push technology was developed in the background of the 1990 featured Internet push. However, this technique was unable to meet its ambitious goals. As a major obstacle was the unwillingness of the two largest browser developers, Microsoft and Netscape, seen to provide a uniform standard.

WAP Push is designed in the background of this failure. Manufacturers and network operators jointly founded the WAP Forum, now part of the Open Mobile Alliance ( OMA) to create a uniform standard.

Openwave, co-founder of the WAP Forum, formulated the value and potential of WAP Push in 2001 as follows: Wireless operators judge the success of Their mobile Internet offering by measuring the adoption of services, the increase enlarge in wireless usage, and to increase enlarge in Average Revenue per User ( ARPU) per month. WAP Push Allows carriers and content developers to increase enlarge subscriber adoption and usage, and offers enhanced revenue opportunities with improved and new applications.

The WAP push architecture

A WAP push operation is performed technically in several steps. The WAP push technology including multiple instances, their interaction with each other is shown in the adjacent diagram.

Summary

The Push Initiator (PI) communicates with the push proxy gateway ( PPG), with the aid of the push access protocol (PAP). The PPG uses the Push Over-The- Air Protocol ( PushOTA ) by a Uniform Resource Identifier ( URI) to the mobile client to deliver. This is done via an SMS Centre (SMS -C). Now, the mobile client has to activate the URI to load the content from the content server. Between these two steps is still the "pull" gateway mediates between the mobile client and the content server. In practice, however, PPG and the gateway are often pull a device.

Push Initiator (PI)

The push initiator ( PI) is the first instance and therefore the author of the WAP - push operation. PI is essentially a program that generates a push message according to PAP specifications. The push message can take three different forms, all of which are written in XML 1.0 and are optional on WBXML encoded. The PI will send the push message but in plain text to the PPG via PAP. The implementation of the PPG determines that the message is converted to the substantially smaller WBXML.

Three possible types Service Indication ( SI), Service Load ( SL) and cache operation (CO). In the meantime ( as of 2008) have SL and CO lost much of its meaning and SI is the method that is used most often.

Service Indication ( SI)

An SI is the most common form of a WAP push message and is often translated in the German language with " service message " ( as for example in Nokia devices ) or simply displayed as " WAP Push" (end devices from Sony Ericsson ). The SI get a message to the client about the availability of external services by means of a Uniform Resource Identifier ( URI). In other words, the SI is a message that contains a link to a specific content (also known as WAP Push link). The client after receiving the SI three options: he can open the service, move the use or delete the SI. The specifications allow this implementation of various conditions or functions for handling the SI by the client, for example the duration of validity, the erase behavior and handling in case of errors.

Service Load ( SL)

If the client receives an SL message, he has, in contrast to SI, no way to ignore the URI. The client is thus not informed of the receipt of services and may not even learns that a SL has been received, as this was directly loaded into the cache. Although this is an obvious security problem, the WAP Forum renounced to specific safety specifications and were only a few guidelines for the protection of clients from abuse. Therefore, the adoption of SL messages in many mobile clients is simply disabled.

Cache operation (CO)

A CO allows invalidation of content that the mobile client has in the cache. This may be necessary if the service the temporal validity of the content can not be determined in advance and the use of a SI is therefore not practicable. An example of this would be mailbox applications. Read or deleted mails can be easily deactivated by CO.

Push Access Protocol (PAP )

Using the PAPs is content transmitted to the Push Proxy Gateway ( PPG) from the push initiator (PI). PAP supports various functions, which summarizes the following table. PAP uses for the transmission of XML delivery instructions, while the contents themselves MIME -encoded.

Push Proxy Gateway ( PPG)

The PPG (or " WAP Gateway" ) allows communication between PI and mobile client and therefore between wireless ( "wireless" ) and wired ( "wired " ) networks. He " taught " the different protocols both instances use (PAP and PushOTA ) and is responsible for the line connecting both instances, as to for authentication.

A further object is to ensure the correct address. PIs address mobile clients via plain text, but can not be used in wireless networks. The PPG must convert the address from the PI for the client. The same task has the PPG in rear-facing communication when the client responds to the PI.

The PPG can decide whether the push message ( the Push Submission) can be pushed via PushOTA to the client. This will only be rejected if the Submission is not the PAP equivalent specifications. If the push message is valid, the PPG delivers them over the PushOTA protocol, either via the OTA WSP (deprecated) or OTA - HTTP (quasi standard for WAP 2.0). The last step is the feedback of the PPG to the PI, either via the PAP function status -query or result -notification.

Push Over The Air Protocol ( PushOTA )

The PushOTA mediates the transport protocol between PPG (gateway ) and the mobile client over WSP (Wireless Session Protocol ) and / or HTTP (W- HTTP). In the context of these two techniques PushOTA " OTA - WSP " or " OTA - HTTP" are mentioned.

OTA - WSP is in principle an additional protocol based on WSP. It extends the WSP functions to push for example, device-specific content (using UAProf ) and supports both connection-oriented and connectionless services ( connectionless or connection- oriented ). OTA - HTTP on the other hand, however, uses the HTTP 1.1 protocol for OTA communication between PPG and client and supports only connection- oriented services.

Once the PPG has received the push by the PI, he can deliver the push on two different methods. A connection- oriented push is used when the mobile client's IP address is known. If the address is unknown, it is called a connectionless push. In this case, the PPG returns a push from the SMS bearer. This method is most commonly used as the client's IP address is known only as long as it is in an active data connection.

Short Message System Centre (SMS -C)

The SMS-C is an essential component when sending a push message from an IP network to a mobile client. The SMS-C removes the TCP / IP layer, in which the Push " encapsulated " and is responsible for the transmission of the final message to the client. Through the process of " de-encapsulation " is the push message for the client no longer a "normal" message, for example to distinguish an SMS.

User Agent Profiles ( UAProf )

With the help of User Agent Profiles ( UAProf ), it is possible to deliver device-specific content. The capabilities of a mobile client are either queried via the Client Capabilities Query PAP and transmitted to the PI or if the client makes a request to the server, such as when he follows a WAP push link to load the appropriate content. The client communicates its capabilities in an XML file.

The UAProf specifications have been developed with WAP 1.2/1.2.1, but only introduced in 2001 with the WAP 2.0 standard. This was necessary because mobile devices have become more and more different in terms of their capabilities began - for example with regard to the display resolution or multimedia features ( and Polyphonic Ringtones, Java functionality, etc.).

The introduction of User Agent Profiles was one of the most important steps for the commercial delivery of WAP Push. Only Thanks to this technical possibility, a customer can get the right one for him application, application etc.. Content providers such as Jesta Digital were among the first service providers who recognized the potential of this marketing technique. Meanwhile, there are also opportunities for smaller companies to deliver their content to device-specific, for example con2mo (free) or Con2Mo Professional ( commercial solution ).

Composition of a push message

A push message (Push Submission) is submitted by the PI to the PPG via PAP. The PPG analyzes the message and performs the necessary transformations and encodings before the news of the PPG is passed over PushOTA.

Each push submission has a header and a body, and includes three different units ( " entities" ), which are described in the following table. The PPG should not modify or remove the original header and body, but can add additional headers that are needed for the necessary OTA services. The original header is either a generic format ( according to HTTP 1.1 specifications) or as a WAP header ( starting with X - WAP prefix). The body may include any MIME content type.

History of WAP push technology

The following table provides a brief overview of the evolution of WAP push technology. It does not refer to WAP in general.

WAP Push in practice

Similarly as for the entire WAP technology, it is difficult to find concrete facts and figures on the use of WAP Push. The potential success of WAP Push can, therefore, be best shown at two points:

• At successfully operating content providers such as Jesta Digital and zed. This use to distribute their content exclusively WAP Push. This seems at first sight somewhat confusing because the client via an SMS keyword requests the content. However, this is not a WAP Pull, since it the push initiator only to prompt to send a WAP push link to the client. The client created by sending the SMS to the content provider above a subscription. More content will therefore sent to the client without his initiative.
• Lack of competition. The only comparable model is the MMS ( see also Main article MMS), which is also based on WAP Push. Images, videos and ring tones can be transmitted via this format. The only difference to WAP Push is that an MMS must always be sent via the MMSC (Multimedia Messaging Service Centre) of the network operator. However, network operators shall MMSCs third party, ie content providers, either not at all or only at high charge to all. Therefore, it is and remains WAP Push the only way for content providers and small businesses to deliver content to clients. In addition, the MMS has to deal with some technical and practical problems. The MMS specifications allow practically unlimited file sizes, but restrict all network operators in Germany, the maximum size of a message to 300 KB - while the content that can be downloaded from a WAP push link that knows no such limitation. Furthermore not support MMS delivery of applications, such as Java MIDlets.