WAP-Push

WAP Push ist ein System zur Distribution verschiedener Inhalte (Content) von einem Server zu einem Mobilgerät (Client). Der Content wird dabei prinzipiell ohne Initiative seitens des Clients vom Server auf das Mobilgerät „geschoben“. Der Server übernimmt daher die Initiative der Übertragung und „pusht“ den Content zum Client.

Ein so genannter WAP-Push-Link, der per SMS aufs Handy geschickt wird, führt zu einer WAP-Adresse, zu der sich das Handy mit dem Lesen der SMS (in der Regel kostenpflichtig) einwählt, zum Beispiel für einen Produkt-Download. Nach Schweden, Großbritannien und Australien kamen 2006 auch in Deutschland und Österreich solche Werbebotschaften auf.^[1][2]

Gründe für die Entwicklung von WAP Push

WAP Push wurde im Hintergrund der in den 1990er vorgestellten Internet Push Technologie entwickelt. Diese Technik konnte ihre hochgesteckten Ziele jedoch nicht erfüllen. Als großes Hindernis wurde die fehlende Bereitschaft der beiden größten Browserentwickler, Microsoft und Netscape, gesehen, einen einheitlichen Standard zu schaffen.^[3]

WAP Push wurde im Hintergrund dieses Scheiterns entwickelt. Hersteller und Netzbetreiber gründeten gemeinsam das WAP Forum, heute Teil der Open Mobile Alliance (OMA), um einen einheitlichen Standard zu schaffen.^[4]

Openwave, Mitgründer des WAP Forums, formulierte den Wert und das Potential von WAP Push im Jahr 2001 folgendermaßen: 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.^[5]

Die WAP-Push-Architektur

Ablauf eines WAP-Push-Vorgangs.

Ein WAP-Push-Vorgang wird technisch in mehreren Schritten ausgeführt. Die WAP-Push-Technologie beinhaltend mehrere Instanzen, deren Interaktion miteinander in der nebenstehenden Grafik gezeigt wird.

Zusammenfassung

Der Push Initiator (PI) kommuniziert mit dem Push Proxy Gateway (PPG) mit Hilfe des Push Access Protocol (PAP). Der PPG nutzt das Push Over-The-Air Protocol (PushOTA) um einen Uniform Resource Identifier (URI) an den mobilen Client auszuliefern. Dies geschieht über ein SMS Centre (SMS-C). Nun muss der mobile Client die URI aktivieren, um den Content vom Content Server laden zu können. Zwischen diesen beiden Schritten ist noch der „Pull“ Gateway, der zwischen mobilem Client und Content Server vermittelt. In der Praxis sind PPG und Pull Gateway jedoch häufig ein Gerät.^[6]

Push Initiator (PI)

Der Push Initiator (PI) ist die erste Instanz und daher der Urheber des WAP-Push-Vorgangs. Ein PI ist grundsätzlich ein Programm, dass eine Push-Nachricht gemäß PAP-Spezifikationen erstellt. Die Push-Nachricht kann dabei drei verschiedene Formen annehmen, die alle in XML 1.0 verfasst sind und optional über WBXML kodiert sind. Der PI sendet die Push-Nachricht allerdings in reinem Text zu dem PPG über PAP. Die Implementierung des PPG entscheidet, ob die Nachricht in das wesentlich kleinere WBXML umgewandelt wird.

Die drei möglichen Typen sind Service Indication (SI), Service Load (SL) und Cache Operation (CO). Mittlerweile (Stand 2008) haben SL und CO stark an Bedeutung verloren und SI ist die Methode die häufigsten genutzt wird.

Service Indication (SI)

Eine SI ist die am häufigsten auftretende Form einer WAP-Push-Nachricht und wird im deutschen Sprachraum häufig mit „Dienstmitteilung“ übersetzt (beispielsweise Nokia Endgeräte) oder einfach als „WAP Push“ angezeigt (Endgeräte von Sony Ericsson). Die SI benachrichtig den Client über die Verfügbarkeit eines externen Services mittels eines Uniform Resource Identifiers (URI). In anderen Worten: die SI ist ein Nachricht, die einen Link zu einem bestimmten Content enthält (auch bekannt als WAP Push Link). Der Client hat nach dem Empfang der SI drei Möglichkeiten: er kann den Service öffnen, die Nutzung verschieben oder die SI löschen. Die Spezifikationen erlauben dabei die Implementierung verschiedener Bedingungen beziehungsweise Funktionen zur Handhabung der SI seitens des Clients, beispielsweise über die Dauer der Gültigkeit, Löschverhalten und Handhabung bei Fehlern.^[7]

Service Load (SL)

Empfängt der Client eine SL-Nachricht, hat er im Gegensatz zu SI, keine Möglichkeiten die URI zu ignorieren. Der Client wird somit nicht über den Empfang eines Services informiert und erfährt Möglicherweise nicht einmal, dass eine SL empfangen wurde, da diese direkt in den Cache geladen wurden. Obwohl dies ein offensichtliches Sicherheitsproblem darstellt, verzichtete das WAP Forum auf konkrete Sicherheitsspezifikationen und gab nur einige Richtlinien zum Schutz von Clients vor Missbrauch. Daher ist die Annahme von SL-Nachrichten bei vielen mobilen Clients deaktiviert.^[8]

Cache Operation (CO)

Eine CO erlaubt das ungültig machen von Content, das der mobile Client gecacht hat. Dies kann notwendig werden, wenn der Service die zeitliche Gültigkeit des Contents nicht im Voraus bestimmten kann und die Nutzung einer SI somit nicht praktikabel ist. Ein Beispiel hierfür wären Mailbox-Anwendungen. Gelesene oder gelöschte Mails können so leicht deaktiviert werden.^[9]

Push Access Protocol (PAP)

Mithilfe des PAPs wird Content vom Push Initiator (PI) and den Push Proxy Gateway (PPG) übertragen. PAP unterstützt verschiedene Funktionen, welche die folgende Tabelle zusammenfasst. PAP nutzt für die Übermittlung der Zustellinstruktionen XML, während die Inhalte selbst MIME-kodiert werden.^[10]

Funktion	Richtung	Aufgabe
Push Submission	PI > PPG	Auslieferung einer Push-Nachricht in Form einer SI, SL oder CO (siehe auch Zusammensetzung einer Push-Nachricht)
Push Replacement	PI > PPG	Ersetzt einen bereits angeforderten Push auf dem PPG (nur wenn die Nachricht noch nicht zum Client ausgeliefert wurde)
Push Cancellation	PI > PPG	Erlaubt das Löschen des Pushs auf dem PPG (nur wenn die Nachricht noch nicht zum Client ausgeliefert wurde).
Client Capabilities Query	PI > PPG	Erfragt beim PPG die Capabilities des Clients mit Hilfe von User Agent Profiles
Status Query	PI > PPG	Erfragt den Status über die Auslieferung der Push-Nachricht
Result Notification	PPG > PI	Erlaubt dem PI die Nachfrage an den sPPG, ob der Client den Push akzeptiert hat
Bad Message	PPG > PI	Der PPG informiert den PI wenn die von PI initiierte Nachricht unverständlich ist.

Push Proxy Gateway (PPG)

Der PPG (oder „WAP Gateways“) erlaubt die Kommunikation zwischen PI und mobilem Client und daher zwischen kabellosen („wireless“) und drahtgebunden („wired“) Netzwerken. Er „vermittelt“ die unterschiedlichen Protokolle die beide Instanzen nutzen (PAP und PushOTA) und ist sowohl verantwortlich für die Verbindung beider Instanzen als auf für die Authentifizierung.

Eine weitere Aufgabe ist das Sicherstellen der korrekten Adressierung. PIs adressieren mobile Clients über Reintext, der allerdings nicht in kabellosen Netzwerken genutzt werden kann. Der PPG muss die Adresse vom PI für den Client umwandeln. Die gleiche Aufgabe hat der PPG bei rückwärts gerichteter Kommunikation, wenn der Client dem PI antwortet.

Der PPG kann entscheiden, ob die Push-Nachricht (die Push Submission) via PushOTA an den Client gepusht werden kann. Dies wird nur abgelehnt, wenn die Submission nicht den PAP Spezifikationen entspricht. Ist die Push-Nachricht gültig, liefert der PPG sie über das PushOTA Protokoll aus, entweder über die OTA-WSP (veraltet) oder OTA-HTTP (quasi Standard seit WAP 2.0). Der letzte Schritt ist die Rückmeldung des PPG zum PI, entweder über die PAP-Funktion status-query oder result-notification.^[11]

Push Over The Air Protocol (PushOTA)

Das PushOTA Protokoll vermittelt den Transport zwischen PPG (Gateway) und dem mobilen Client über WSP (Wireless Session Protocol) und/oder HTTP (W-HTTP). Im Kontext von PushOTA werden diese beiden Techniken „OTA-WSP“ beziehungsweise „OTA-HTTP“ genannt.

OTA-WSP ist prinzipiell ein zusätzliches Protokoll, das auf WSP aufsetzt. Es erweitert die WSP-Funktionen um beispielsweise gerätespezifischen Content zu pushen (mittels UAProf) und unterstützt sowohl verbindungsorientierte als auch verbindungslose Dienste (connectionless beziehungsweise connection-oriented). OTA-HTTP dagegen nutzt dagegen das HTTP 1.1 Protokoll für OTA-Kommunikation zwischen PPG und Client und unterstützt nur connection-oriented Dienste.

Sobald der PPG den Push vom PI erhalten hat, kann er den Push über zwei unterschiedlichen Methoden ausliefern. Ein connection-oriented Push wird dann genutzt, wenn die IP Adresse des mobilen Clients bekannt ist. Ist die Adresse unbekannt, spricht man von einem connectionless Push. In diesem Fall, liefert der PPG den Push über einen SMS-Träger aus. Diese Methode wird am häufigsten genutzt, da die IP Adresse des Clients nur dann bekannt ist, solange sich dieser in einer aktiven Datenverbindung befindet.^[12]

Short Message System Centre (SMS-C)

Der SMS-C ist eine essentielle Komponente beim Senden einer Push-Nachricht von einem IP-Netzwerk zu einem mobilen Client. Der SMS-C entfernt die TCP/IP-Schicht, in die der Push „eingekapselt“ ist und ist verantwortlich für die Übermittlung der endgültigen Nachricht an den Client. Durch den Vorgang der „Entkapselung“ ist die Push-Nachricht für den Client nicht mehr von einer „normalen“ Nachricht, beispielsweise einer SMS zu unterscheiden.^[3]

User Agent Profiles (UAProf)

Siehe auch Hauptartikel UAProf für technische Erläuterungen

Mit Hilfe von User Agent Profiles (UAProf) ist es möglich, Content gerätespezifisch auszuliefern. Die Fähigkeiten eines mobilen Clients werden entweder über die Client Capabilities Query von PAP abgefragt und an den PI übermittelt oder wenn der Client eine Anfrage an den Server stellt, beispielsweise wenn er einem WAP Push Link folgt, um den entsprechenden Content zu laden. Der Client übermittelt seine Capabilities in einer XML-Datei.^[13]

Die UAProf-Spezifikationen wurden bereits mit WAP 1.2/1.2.1 entwickelt, aber erst 2001 mit dem WAP 2.0 Standard eingeführt. Dies wurde notwendig, da Mobilgeräte sich hinsichtlich ihrer Capabilities immer weiter zu unterscheiden begannen – beispielsweise hinsichtlich Displayauflösung oder Multimedia-Funktionen (Polyphone und Real-Klingeltöne, Java-Funktionalität etc.).

Die Einführung von User Agent Profiles war einer der wichtigsten Schritte zur kommerziellen Verbreitung von WAP Push. Nur Dank dieser technischen Möglichkeit, kann ein Kunde die für ihn passende Anwendung, Applikation etc. erhalten. Content-Provider wie beispielsweise Jamba gehörten zu den ersten Dienstleistern, die das Potential dieser Vermarktungstechnik erkannten. Mittlerweile gibt es auch für kleinere Unternehmen Möglichkeiten, um ihren Content Gerätespezifisch ausliefern zu können, beispielsweise con2mo^[14] (kostenlos) beziehungsweise Con2Mo Professional^[15] (kommerzielle Lösung).

Zusammensetzung einer Push-Nachricht

Eine Push-Nachricht (Push Submission) wird vom PI mittels PAP an den PPG übermittelt. Der PPG analysiert die Nachricht und führt die notwendigen Transformationen und Kodierungen aus, bevor die Nachricht vom PPG über PushOTA weitergegeben wird.

Jede Push Submission besitzt einen Header und einen Body und beinhaltet drei verschiedene Einheiten („entities“), die in der folgenden Tabelle beschrieben sind. Der PPG sollte den Original Header und Body nicht entfernen oder modifizieren, kann aber zusätzliche Header hinzufügen, die für die notwendigen OTA-Dienste notwendig sind. Der Original-Header ist entweder Generisch formatiert (nach HTTP 1.1 Spezifikationen) oder als WAP-Header (beginnend mit X-WAP Präfix). Der Body kann jeglichen MIME-Content Typ beinhalten.^[16]

Bezeichnung	Einsatz	Inhalt
Control-Entity	Obligatorisch	Informationen für den PPG über die Auslieferung
Content-Entity	Obligatorisch	Der Content der an den Client gesendet werden soll
Capability-Entity	Optional	Die Capabilities, die der Client nach Ansicht des PIs besitzt (formatiert nach UAProf-Spezifikationen).

Historie der WAP-Push-Technologie

Die folgende Tabelle gibt einen kurzen Überblick über die Evolution der WAP-Push-Technologie. Sie bezieht sich nicht auf WAP im Allgemeinen.

WAP Version	Jahr	WAP-Push-Entwicklung
1.0	1998	Keine Spezifikation von WAP Push
1.1	1999	Keine Spezifikation von WAP Push
1.2	2000	Erste Spezifikationen von WAP Push. Schaffung der grundsätzlichen Architektur einschließlich PPG, PAP und OTA-WSP. Alle folgenden Änderungen betreffen nicht die Architektur, sondern nur Feinheiten in der Ausführung.
1.2.1	2000	Geringe kosmetische Änderungen und Korrekturen.
2.0	2001	Zwei Änderungen in der Document Type Definition (DTD). Betrifft das Ersetzen von bereits gepushten Inhalt mit einem neuen Push mit der gleichen ID. Einführung von OTA-HTTP.
post 2.0	2001–2002	Geringe kosmetische Änderungen und Korrekturen. Vorgeschlagene Änderungen der UAProf wurden nicht durchgesetzt. Seit September 2002 keine weiteren Entwicklungen bezüglich WAP Push und seit November 2002 keine für WAP.

WAP Push in der Praxis

Ähnlich wie für die gesamte WAP Technologie ist es schwierig, konkrete Zahlen und Fakten über die Nutzung von WAP Push zu finden. Der mögliche Erfolg von WAP Push kann daher am besten an zwei Punkten gezeigt werden:

• An erfolgreich operierenden Content-Providern wie Jamba und zed. Diese nutzen zur Verbreitung ihrer Contents ausschließlich WAP Push. Dies scheint auf den ersten Blick etwas verwirrend, da der Client über ein SMS-Keyword den Content anfordert. Dies ist jedoch kein WAP Pull, da es den Push Initiator lediglich dazu auffordert, einen WAP Push Link an den Client zu schicken. Der Client erstellt durch das Senden der SMS an die oben genannten Content-Provider ein Abonnement. Weitere Contents werden dem Client daher ohne seine Initiative übermittelt.
• Fehlende Konkurrenz. Das einzige vergleichbare Modell ist die MMS (siehe auch Hauptartikel MMS), das auch auf WAP Push basiert. Über dieses Format können ebenfalls Bilder, Videos und Klingeltöne übertragen werden. Der einzige Unterschied zu WAP Push ist, dass eine MMS immer über den MMSC (Multimedia Messaging Service Center) des Netzbetreibers geschickt werden muss. Netzbetreiber stellen allerdings ihre MMSCs Dritten, also Content-Providern, entweder gar nicht oder nur zu hohen Gebühren zur Verfügung.
  Daher ist und bleibt WAP Push die einzige Möglichkeit für Content Provider und kleine Unternehmen, um Content an Clients auszuliefern. Zusätzlich hat die MMS mit einigen technischen und praktischen Problemen zu kämpfen. Die MMS-Spezifikationen erlauben prinzipiell unbegrenzte Dateigrößen, allerdings begrenzen alle Netzbetreiber in Deutschland die maximale Größe einer Nachricht auf 300 KB – während der Content, der über einen WAP Push Link heruntergeladen werden kann, keine solche Limitierung kennt. Des Weiteren unterstützt MMS nicht die Auslieferung von Applikationen, beispielsweise Java MIDlets.

Siehe auch

• Wireless Application Protocol
• Bluetooth-Marketing

Weblinks

• Homepage der Open Mobile Alliance (OMA)
• Sämtliche Spezifikationen zu WAP und WAP Push
• SIC! Software – Anbieter von Software zur Content-Auslieferung über WAP Push

Einzelnachweise

1. ↑ "Mobilfunk: Kostenfalle WAP-Spam", PC-Welt vom 23. November 2006
2. ↑ "Spam am Handy per WAP-Push"
3. ↑ ^{a b} http://epubl.luth.se/1402-1617/2002/107/LTU-EX-02107-SE.pdf Tommay Wall - Service Development for WAP Push Delivery to Mobile Devices
4. ↑ http://www.openmobilealliance.org/Technical/wapindex.aspx Technische Spezifikationen zu WAP Push
5. ↑ http://developer.openwave.com/docs/WAP_Push_1201.pdf Openwave - The value of WAP Push
6. ↑ http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-250-pusharchoverview-20010703-a.pdf WAP Push Architecture
7. ↑ http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-167-serviceind-20010731-a.pdf?doc=wap-167-serviceind-20010731-a.pdf Service Indication Specification
8. ↑ http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-168-serviceload-20010731-a.pdf Service Loading Specification
9. ↑ http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-175-cacheop-20010731-a.pdf Cache Operation Specification
10. ↑ http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-247-pap-20010429-a.pdf Push Access Protocol Specification
11. ↑ http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-249-ppgservice-20010713-a.pdf Push Proxy Gateway Specification
12. ↑ http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-235-pushota-20010425-a.pdf Push OTA Protocol Specification
13. ↑ http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-248-uaprof-20011020-a.pdf UAProf Specification
14. ↑ http://www.con2mo.de con2mo – kostenloses System zur Content-Auslieferung
15. ↑ http://www.sic-software.com/index.php?option=com_content&view=article&id=30&Itemid=18&lang=de Con2Mo Professional – Kommerzielles System zur Endgerät-spezifischen Auslieferung von Content
16. ↑ http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-251-pushmessage-20010322-a.pdf Push Message Specification