WAP push

WAP Push is a system for distributing various content from a server to a mobile device (client). In principle, the content is "pushed" from the server to the mobile device without any initiative on the part of the client. The server therefore takes over the initiative of the transmission and “pushes” the content to the client.

A so-called WAP push link, which is sent to the cell phone via SMS, leads to a WAP address to which the cell phone dials when reading the SMS (usually subject to a charge), for example for a product download. After Sweden, Great Britain and Australia, such advertising messages also appeared in Germany and Austria in 2006.

Reasons for developing WAP Push

WAP Push was developed in the background of the Internet push technology introduced in the 1990s. However, this technology failed to meet its ambitious goals. The unwillingness of the two largest browser developers, Microsoft and Netscape , to create a uniform standard was seen as a major obstacle .

WAP Push was developed in the background of this failure. Manufacturers and network operators jointly founded the WAP Forum, today part of the Open Mobile Alliance (OMA), in order 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 in wireless usage, and an increase in Average Revenue Per user (ARPU) per month. WAP Push allows carriers and content developers to increase subscriber adoption and usage, and offers enhanced revenue opportunities with improved and new applications. (Wireless service providers assess the success of their Internet offerings by measuring user acceptance of wireless services, increasing usage of the services and increasing the average monthly revenue per user. WAP Push allows service providers and content developers to accept this and usage by the users and offers them increased income opportunities through improved and new applications.)

The WAP push architecture

Sequence of a WAP push process.

A WAP push process is technically carried out in several steps. The WAP push technology contains several instances, the interaction of which is shown in the graphic 'Sequence of a WAP push process'.

Summary

The Push Initiator (PI) communicates with the Push Proxy Gateway (PPG) using the Push Access Protocol (PAP). The PPG uses the Push Over The Air Protocol (PushOTA) to deliver a Uniform Resource Identifier (URI) to the mobile client. This is done via an SMS Center (SMS-C). Now the mobile client has to activate the URI in order to load the content from the content server. The “pull” gateway, which mediates between the mobile client and the content server, is located between these two instances. In practice, however, the PPG and Pull Gateway are often one and the same device.

Push initiator (PI)

The push initiator (PI) is the first instance and therefore the originator of the WAP push process. A PI is basically a program that creates 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 optionally encoded using WBXML. However, the PI sends the push message in plain text to the PPG via PAP. The implementation of the PPG decides whether the message is converted into the much smaller WBXML.

The three possible types are Service Indication (SI), Service Load (SL) and Cache Operation (CO). In the meantime (as of 2008), SL and CO have lost much of their importance and SI is the method that is used most frequently.

Service Indication (SI)

An SI is the most common form of a WAP push message and is often translated as "service message" in German-speaking countries (for example with Nokia devices) or simply displayed as "WAP push" (devices from Sony Ericsson). The SI notifies the client of the availability of an external service using a URI. In other words, the SI is a message that contains a link to specific content (also known as a WAP push link). After receiving the SI, the client has three options: it can open the service, postpone use or delete the SI. The specifications allow the implementation of various conditions or functions for handling the SI on the part of the client, for example regarding the duration of the validity, the deletion behavior and the handling in the event of errors.

Service Load (SL)

If the client receives an SL message, in contrast to SI, it has no way of ignoring the URI. The client is therefore not informed of the receipt of a service and may not even learn that an SL has been received, since this was loaded directly into the cache. Although this is an obvious security problem, the WAP forum waived specific security specifications and only gave a few guidelines to protect clients from abuse. Therefore the acceptance of SL messages is simply deactivated for many mobile clients.

Cache Operation (CO)

A CO allows content that the mobile client still has in the cache to be invalidated. This can become necessary if the service cannot determine the temporal validity of the content in advance and the use of an SI is therefore impractical. An example of this would be mailbox applications. Read or deleted emails can easily be deactivated using CO.

Push Access Protocol (PAP)

With the help of the PAP, content is transmitted from the Push Initiator (PI) to the Push Proxy Gateway (PPG). PAP supports various functions, which are summarized in the following table. PAP uses XML to transmit delivery instructions , while the content itself is MIME- coded.

function	direction	task
Push submission	PI> PPG	Delivery of a push message in the form of an SI, SL or CO (see also composition of a push message)
Push replacement	PI> PPG	Replaces an already requested push on the PPG (only if the message has not yet been delivered to the client)
Push cancellation	PI> PPG	Allows the push to be deleted on the PPG (only if the message has not yet been delivered to the client).
Client Capabilities Query	PI> PPG	Asks the PPG for the capabilities of the client using user agent profiles
Status query	PI> PPG	Queries the status of the delivery of the push message
Result notification	PPG> PI	Allows the PI to ask the sPPG whether the client has accepted the push
Bad message	PPG> PI	The PPG informs the PI if the message initiated by PI is incomprehensible.

Push Proxy Gateway (PPG)

The PPG (or "WAP Gateway") allows communication between PI and mobile client and thus between wireless and wired networks. It “mediates” the different protocols that both entities use (PAP and PushOTA), and is responsible for connecting both entities and for authentication.

Another task is to ensure correct addressing. PIs address mobile clients using plain text, which, however, cannot be used in wireless networks. The PPG has to convert the address from the PI for the client. The PPG has the same task with reverse communication when the client replies to the PI.

The PPG can decide whether the push message (the push submission) can be pushed to the client via PushOTA. This will only be rejected if the submission does not meet the PAP specifications. If the push message is valid, the PPG delivers it via the PushOTA protocol, either via the OTA-WSP (obsolete) or OTA-HTTP ( quasi-standard since WAP 2.0). The last step is the feedback from the PPG to the PI, either via the PAP function status-query or result-notification.

Push Over The Air Protocol (PushOTA)

The PushOTA protocol mediates the transport between PPG (gateway) and the mobile client via WSP (Wireless Session Protocol) and / or HTTP (W-HTTP). In the context of PushOTA, these two technologies are called “OTA-WSP” and “OTA-HTTP”.

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

As soon as the PPG has received the push from the PI, it can deliver the push using two different methods. A connection-oriented push is used when the IP address of the mobile client is known. If the address is unknown, it is called a connectionless push. In this case, the PPG delivers the push via an SMS carrier. This method is most frequently used, as the IP address of the client is only known as long as it is in an active data connection.

Short Message System Center (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 is “encapsulated” and is responsible for delivering the final message to the client. Due to the "decapsulation" process, the push message for the client can no longer be distinguished from a "normal" message, for example 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 from PAP and transmitted to the PI or when the client makes a request to the server, for example when it follows a WAP push link to load the corresponding content. The client transmits its capabilities in an XML file.

The UAProf specifications were already developed with WAP 1.2 / 1.2.1, but only introduced in 2001 with the WAP 2.0 standard. This became necessary because mobile devices began to differ more and more in terms of their capabilities - for example in terms of display resolution or multimedia functions (polyphonic and real ring tones, Java functionality, etc.).

The introduction of User Agent Profiles was one of the most important steps in the commercial spread of WAP Push. It is only thanks to this technical possibility that a customer can get the right application, application, etc. Content providers such as Jesta Digital were among the first service providers to recognize the potential of this marketing technique. In the meantime, there are also options for smaller companies to be able to deliver their content device-specifically, for example con2mo (free) or Con2Mo Professional (commercial solution).

Composition of a push message

A push message (push submission) is sent from the PI to the PPG using PAP. The PPG analyzes the message and carries out the necessary transformations and encodings before the message is forwarded by the PPG via PushOTA.

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

designation	commitment	content
Control entity	Mandatory	Information for the PPG about the extradition
Content entity	Mandatory	The content to be sent to the client
Capability Entity	Optional	The capabilities that the client has according to the PI (formatted according to UAProf specifications).

History of WAP push technology

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

WAP version	year	WAP push development
1.0	1998	No specification of WAP Push
1.1	1999	No specification of WAP Push
1.2	2000	First specifications of WAP Push. Creation of the basic architecture including PPG, PAP and OTA-WSP. All of the following changes do not affect the architecture, but only the details of the execution.
1.2.1	2000	Minor cosmetic changes and corrections.
2.0	2001	Two changes in the Document Type Definition (DTD). Affects the replacement of already pushed content with a new push with the same ID. Introduction of OTA-HTTP.
post 2.0	2001-2002	Minor cosmetic changes and corrections. Proposed changes to the UAProf were not implemented. No further developments regarding WAP Push since September 2002 and none for WAP since November 2002.

WAP Push in practice

Similar to all of WAP technology, it is difficult to find concrete facts and figures about the use of WAP Push. The potential success of WAP Push can therefore best be demonstrated at two points:

To successfully operating content providers such as Jesta Digital and zed . These only use WAP Push to distribute their content. At first glance, this seems a bit confusing, as the client requests the content via an SMS keyword. However, this is not a WAP pull, as it only asks the push initiator to send a WAP push link to the client. The client creates a subscription by sending the SMS to the content providers mentioned above. Further content is therefore transmitted to the client without his initiative.
Lack of competition. The only comparable model is the MMS (see also the main article MMS ), which is also based on WAP Push. This format can also be used to transfer pictures, videos and ring tones. The only difference to WAP Push is that an MMS must always be sent via the network operator's MMSC (Multimedia Messaging Service Center). However, network operators either do not make their MMSCs available to third parties, i.e. content providers, or only at high fees.
Therefore, WAP Push is and will remain the only way for content providers and small businesses to deliver content to clients. In addition, MMS has to contend with some technical and practical problems. The MMS specifications allow in principle unlimited file sizes, but all network operators in Germany limit the maximum size of a message to 300 KB - while the content that can be downloaded via a WAP push link has no such limitation. Furthermore, MMS does not support the delivery of applications such as Java MIDlets.