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.

Gründe für die Entwicklung von WAP Push

WAP Push wurde im Hintergrund der in den 1990er Jahren 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.

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.

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. (Betreiber von drahtlosen Diensten beurteilen den Erfolg ihrer Internetangebote durch die Messung der Annahme der drahtlosen Dienste durch die Nutzer, die Erhöhung der Nutzung der Dienste und die Erhöhung der durchschnittlichen monatlichen Einnahmen pro Nutzer. WAP Push erlaubt es den Dienstleistern und Entwicklern von Inhalten die Annahme und Nutzung durch die Benutzer zu erhöhen und bietet ihnen vermehrte Einnahmemöglichkeiten durch verbesserte und neue Applikationen.)

Die WAP-Push-Architektur

Ablauf eines WAP-Push-Vorgangs.

Ein WAP-Push-Vorgang wird technisch in mehreren Schritten ausgeführt. Die WAP-Push-Technologie beinhaltet mehrere Instanzen, deren Interaktion miteinander in der Grafik 'Ablauf eines WAP-Push-Vorgangs' 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 den URI aktivieren, um den Content vom Content Server laden zu können. Zwischen diesen beiden Instanzen befindet sich der „Pull“ Gateway, der zwischen mobilem Client und Content Server vermittelt. In der Praxis sind PPG und Pull Gateway jedoch häufig ein und dasselbe Gerät.

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, das 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 am 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 (so beispielsweise bei Nokia Endgeräten) oder einfach als „WAP Push“ angezeigt (Endgeräte von Sony Ericsson). Die SI benachrichtigt den Client über die Verfügbarkeit eines externen Services mittels eines URI. In anderen Worten: die SI ist eine 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, das Löschverhalten und die Handhabung bei Fehlern.

Service Load (SL)

Empfängt der Client eine SL-Nachricht, so hat er, im Gegensatz zu SI, keine Möglichkeit, den URI zu ignorieren. Der Client wird somit nicht über den Empfang eines Services informiert und erfährt möglicherweise nicht einmal, dass ein SL empfangen wurde, da dieser direkt in den Cache geladen wurde. 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 einfach deaktiviert.

Cache Operation (CO)

Eine CO erlaubt das Ungültigmachen von Content, den der Mobile-Client noch im Cache hat. Dies kann notwendig werden, wenn der Service die zeitliche Gültigkeit des Contents nicht im Voraus bestimmen 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 mittels CO leicht deaktiviert werden.

Push Access Protocol (PAP)

Mithilfe des PAPs wird Content vom Push Initiator (PI) an 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.

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 Gateway“) erlaubt die Kommunikation zwischen PI und mobilem Client und damit 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 auch 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 (Quasistandard 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.

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 unterschiedliche 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.

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.

User Agent Profiles (UAProf)

→ Hauptartikel: User Agent Profile

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.

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 Jesta Digital 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 (kostenlos) beziehungsweise Con2Mo Professional (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.

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 Jesta Digital 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

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