Startseite : Archiv : Heft 31 : Artikel
Artikel aus Mobile Times 31
Was bedeutet eigentlich Datenübertragung? Was kann man damit machen? Und vor allem: Wie geht das denn nun? Diese Fragen wollen wir versuchen in unserer neuen Serie zu beantworten.
In der letzten Folge (>>) haben wir die Entwicklung mobiler Datenübertragung von der Brieftaube bis SMS nachgezeichnet. Doch SMS hat bei allen Vorteilen auch einige Nachteile. Der am störendsten empfundene Nachteil ist die Nachrichtenlänge von 160 Zeichen, was für Kurzmitteilungen zwar ausreicht, aber nicht für Briefe oder das Betrachten von Internet-Seiten.
Für Internet gibt es zwar andere Lösungen, aber die erfordern mehr als nur ein Telephon. Denn wenn man über GSM-Daten auf das Internet zugreift, so benötigt man einen Computer oder ein Handy mit integrierter Organizer-Funktion, um die Daten zu interpretieren. Außerdem muß die Telephonnummer für Daten freigeschaltet sein.
Die Lösung dafür ist WAP (Wireless Application Protocol = Protokoll für drahtlose Anwendungen). WAP kann auf beide Notwendigkeiten verzichten. Der integrierte Computer ist nicht notwendig, da bei WAP die Intelligenz nicht im Endgerät sitzt, sondern im Netzwerk. Und eine Freischaltung für Daten ist zwar empfehlenswert, aber nicht unbedingt nötig, da WAP auch andere Übertragungswege benutzen kann. Alles was man wirklich bräuchte, wäre ein WAP-fähiges Handy und ein WAP-Gateway bei dem Netzwerkbetreiber.
"Bräuchte" deshalb, da das, was man wirklich braucht, von den Einstellungen des Netzbetreibers abhängt. Denn WAP beinhaltet zwar als unterste Ebene WDP (Wireless Datagram Protocol), womit von WAP aus gesehen die unterschiedlichsten Übertragungswege gleichberechtigt behandelt werden können, aber ob der Netzbetreiber das unterstützt, ist schon wieder eine andere Frage. Eine Möglichkeit wäre es, SMS als Trägermedium zu verwenden, was möglich ist, da SMS ja über die Kontrollkanäle direkt übertragen wird. Der Nachteil ist nur, daß selbst einfache WAP-Anwendungen viele SMS-Nachrichten als Träger benötigen, weswegen auch nur ein Betreiber (SBC in den USA) diese Variante erforscht.
Die meisten Netzbetreiber (so auch A1 und max.) verwenden CSD oder GSM-Daten als Trägermedium. Der Nachteil daran ist die Zeitverzögerung, da für jede Anfrage erst eine Verbindung zwischen dem Handy und dem Gateway aufgebaut werden muß, was im Durchschnitt etwa 30 Sekunden dauert. Zudem wird als Protokoll V.110 und noch nicht ISDN verwendet, so daß nach Perioden der Inaktivität (also wenn man eine Seite liest und dabei keine Knöpfe drückt) der Anruf beendet wird, und wenn dann doch ein Knopf gedrückt wird, ein neuerlicher Anruf getätigt werden muß.
Ein weiteres mögliches Trägermedium, das derzeit noch nicht überall eingeführt ist, wäre USSD, das sowohl mit SMS als auch mit CSD gewisse Ähnlichkeiten hat. Wie bei SMS werden die Informationen nicht über die Gesprächskanäle, sondern über die Signalkanäle verschickt, weswegen jede USSD-Nachricht auch mit 182 Zeichen beschränkt ist. Jedoch werden USSD-Nachrichten im Unterschied zu SMS-Nachrichten nicht gespeichert und weitergeleitet, sondern es wird wie bei CSD eine Sitzung eingeleitet, die offen bleibt, bis man selbst, eine Anwendung oder eine Zeitüberschreitung auflegen. Der Vorteil für WAP wäre, daß die Übertragungen bis zu siebenmal schneller als SMS wären, und man auch kein spezielles Menü aufrufen muß, sondern die Befehle direkt auf dem Hauptbildschirm des Mobiltelephons eingeben kann. Damit ist aber auch der Nachteil verbunden, denn auf dem Hauptbildschirm gibt man normalerweise die Telephonnummer ein, die man für normale Telephongespräche wählen will. Damit eine USSD-Nachricht auch als solche erkannt wird, sind Sonderzeichen nötig: "*" und "#" werden verwendet um die speziellen USSD-Befehle von normalen Telephonnummern zu unterscheiden. Das erinnert fatal an die GSM-Service-Befehle (siehe MOBILE TIMES 7 bis 9) - und das ist auch kein Wunder, denn diese Service-Befehle werden heute als "USSD Stufe 1" bezeichnet, während Stufe 2 die interaktive Erweiterung ist, die für das SIM-Toolkit und WAP verwendet werden kann. Ein weiterer Vorteil ist, daß SMS und Daten nicht in allen GSM-Netzen vorhanden sind - USSD dagegen schon, denn es ist ein integraler Bestandteil von GSM.
Eine vierte Möglichkeit für einen WAP-Träger wäre GPRS. Im Unterschied zu den ersten drei Möglichkeiten ist das aber noch nirgends in Praxis anzutreffen. Erst im Laufe dieses Jahres sollen GSM-Netzwerken auf diese neue Technik aufgerüstet werden, die mit maximal 177,2 kbps nicht nur deutlich schneller ist als die drei anderen Möglichkeiten, sondern auch virtuelle Verbindungen unterstützt, bei denen der Kunde scheinbar mit dem Netzwerk verbunden ist, und auch sofort ohne Verbindungsaufbau Daten senden und empfangen kann, aber trotzdem das Netzwerk nicht belastet, und daher auch nicht dafür zahlen muß.
Das Problem für die Praxis ist hier ein finanzielles: in dem Moment, wo von der virtuellen Verbindung auf eine reale Verbindung umgeschaltet wird, fallen natürlich Gebühren an. Wenn man nun über einen Nachrichtendienst verfügt, so hat man bisher eine monatliche Fixgebühr bezahlt, und bekam die Nachrichten als SMS. Würde man sie aber über GPRS bekommen, so müßte man für jede Nachricht die Gesprächsgebühren bezahlen. Der schlimmstmögliche Fall wäre, wenn man für ungebetene Werbezusendungen zahlen müßte. Daher gibt es derzeit noch keine Endgeräte, die eine Aktivierung der virtuellen Verbindung vom anderen Ende aus gestatten. Solange dieses Problem nicht gelöst ist, scheint es, als wäre eine WAP-Sitzung, die vom Handy aus gestartet wird, die einzige Art GPRS konsumentenfreundlich zu benutzen.
Wir wissen jetzt, daß es vier mögliche Übertragungswege für Daten gibt, die durch WDP zu einer einheitlichen Oberfläche werden. Dadurch können die eigentlichen WAP-Anwendungen darauf aufbauen, ohne sich darum zu kümmern, wie die Daten denn nun tatsächlich unterwegs sind. Darauf liegt als nächste Ebene WTLS, die Sicherheitsebene. Hier werden die Daten auf ihre Richtigkeit geprüft und die Identität des Anwenders kontrolliert, denn schließlich will man nicht, daß die eigenen Daten auf einem fremden Telephon landen.
Als weitere Ebene gibt es nun das Transaktionsprotokoll WTP, das WAP-Äquivalent zu HTTP im Internet - nur etwas simplifiziert, da die Bandbreiten für Mobiltelephone kleiner sind, als diejenigen die im Festnetz zur Verfügung stehen. WTP unterstützt auch das Zusammenführen mehrerer PDU bezeichneter Dateneinheiten zu einer, was ja nötig ist, denn nicht nur SMS oder USSD als übertragen Information in kleinen Häppchen, sondern auch GPRS und CSD zerlegen die Daten in kleine Pakete. Außerdem sorgt WTP durch verzögerte Bestätigung dafür, daß die Gesamtzahl an nötigen Übertragungen reduziert wird. Als Kunde spart man sich Gesprächsgebühren, und der Netzbetreiber kann auf seinen beschränkten Frequenzen mehr Kunden unterbringen.
Darüber liegt noch das Sitzungsprotokoll WSP, das die Verbindung zwischen WAE und zwei verschiedenen Sitzungsdiensten herstellt, wobei mit einer Sitzung eine komplette Verbindung vom Einschalten bis zum Auflegen gemeint ist. Einer der beiden Dienste greift dann auf WTP zu - das ist der Dienst der wohl häufiger verwendet werden wird, da dies die Sitzung mit Verbindung ist, während der andere Dienst für Sitzungen ohne Verbindung ist, bei denen nur gespeicherte Daten betrachtet werden.
Ganz obenauf ist die eigentliche Anwendungsumgebung WAE - das Einzige, was man im realen Betrieb von all den WAP-Ebenen sehen sollte. WAE entspricht dem Internet Explorer oder Netscape beim Internet, und interpretiert sowohl WML als auch WMLScript, die Handyäquivalente von HTML und JavaScript. Damit sind im Prinzip fast alle Funktionen möglich, die auch im Internet zur Verfügung stehen, nur eben speziell angepaßt für das Handy und sein kleineres Display.
Eine dritte Funktion der WAE soll die Telephonanwendung WTA werden. Damit würden die Funktionen des SIM-Toolkits in WAP integriert werden. Für den Anwender würde es zweifellos komfortabler sein, wenn er direkt von der einfachen WAP-Oberfläche aus auf diese Funktionen zugreifen kann, jedoch hat man sich derzeit noch nicht darauf geeinigt, wie es in die Praxis umgesetzt werden soll, und es sieht im Moment auch nicht so aus, als ob das bald der Fall sein würde.
Unter "Push-Operationen" versteht man, wenn dem Handy ohne Anforderung durch den Benutzer Daten zugespielt werden. Solche Operationen kommen sowohl bei SMS als auch bei Netzwerkupdates via SIM-Toolkit vor. Bei WAP soll das zum Beispiel nicht nur für Nachrichtendienste verwendet werden, sondern auch um Konfigurationsdaten an das Handy zu übertragen. Der derzeitige Vorschlag sieht vor, SMS dafür zu verwenden, bis die noch offenen Fragen geklärt sind.
Ein weiteres Problem ist die Sicherheit. WML verwendet durch WTLS automatisch nur sichere, verschlüsselte Verbindungen, was für die Abwicklung von Bankgeschäften oder Einkäufen mit dem Handy sehr sinnvoll ist. Im WAP-Gateway werden aber die WTLS-Daten entschlüsselt, und dann für die Weiterleitung an die Bank, das Kino oder wohin sonst auch immer als HTTPS wieder verschlüsselt. Auf dem Gateway selbst liegen die Daten in unverschlüsselter Form vor, und zwar sowohl die vom Handy empfangenen, als auch die Daten aus dem Internet - ein Problem das bei Internet-Providern nicht auftritt, da hier die Daten unterwegs nicht entschlüsselt werden müssen.
Ein weiteres Manko ist, daß WAP noch keine Kompression für den Text enthält, sondern nur für die Formatierungsbefehle. Da die Größe einer "Deck" genannten Seite auf 1400 Byte limitiert ist, stellt das eine kleine Einschränkung dar. Klein deshalb, da einerseits WSP zwischen Gateway und Handy einen größeren Umfang der Datenpakete aushandeln kann, wenn beide Seiten dazu fähig sind, andererseits WTP Nachrichten uns Seiten in kleinere Pakete zerlegen und dann wieder zusammensetzen kann.
Etwas, das viele Anwender nicht so sehr stören dürfte, ist, daß "Cookies" von WAP noch nicht unterstützt werden. Wenn man aber personalisierte Webseiten wie etwa den persönlichen "Standard" schätzt, dann ist das ein Problem, da die Informationen für die Personalisierung als Cookies abgelegt werden. Zudem vergeben viele Anbieter Zugriffsberechtigungen für kostenpflichtige Seiten als Cookies, womit diese Seiten derzeit für Handyaner trotz WAP nicht verfügbar sind.
Schließlich muß ja auch noch das Handy WAP-fähig sein, was nicht nur ein größeres Display erfordert, damit man die Seiten auch lesen kann, sondern erfordert auch mehr internen Speicher, um die Seiten zu erfassen und zu verarbeiten. Außerdem will man ja auf SIM-Toolkit und SMS nicht verzichten, weshalb sowohl WAP-Handys als auch die neuen Gateways der Netzbetreiber alle drei Technologien unterstützen müssen.
Bei all diesen kleineren Nachteilen hat WAP aber auch einen gewaltigen Vorteil. Denn WAP ist mehr als nur Internet auf dem GSM-Handy: es stellt diese Funktionalität auch auf TDMA-Netzwerken, die GPRS unterstützen, sowie allen CDMA-Netzwerken zur Verfügung. Und auch das zukünftige UMTS wird WAP unterstützen können - was aber alles kein wirkliches Wunder ist, da man auf das Internet ja auch von allen Computern zugreifen kann, egal ob sie unter Windows, MacOS, UNIX oder Linux laufen.
Über die praktischen Anwendungen von WAP mehr in der nächsten Folge in MOBILE TIMES 32. (>>)
Michael Köttl
CDMA | Code Division Multiple Access |
CSD | Circuit Switched Data |
GPRS | General Packet Radio Service |
GPRS | General Packet Radio Service |
GSM | Global System for Mobiles |
HDML | Handheld Device Markup Language |
HDTP | Handheld Device Transport Protocol |
HLR | Home Location Register |
HTML | HyperText Markup Language |
HTTP | HyperText Transport Protocol |
HTTPS | HyperText Transport Protocol Security |
PDU | Protocol Data Unit |
TLS | Transport Layer Security |
UDP | User Datagram Protocol |
UMTS | Universal Mobile Telephone System |
USSD | Unstructured Supplementary Services Data |
WAE | Wireless Application Environment |
WAP | Wireless Application Protocoll |
WDP | Wireless Datagram Protocol |
WML | Wireless Markup Language |
WSP | Wireless Session Protocol |
WTA | Wireless Telephony Application |
WTLS | Wireless Transport Layer Security |
WTP | Wireless Transaction Protocol |
Letzte Überarbeitung: Montag, 10. Februar 2003 Text © 2000 by Mobile Times; HTML © 2002-2003 by Mobile Times |