mobilkommunikation kapitel 10: mobilitätsunterstützung · prof. dr.-ing. jochen schiller, mc...

Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/ MC SS05 10.1

Mobilkommunikation Kapitel 10: Mobilitätsunterstützung

DateisystemeDatenbankenWWW und Mobilität WAP (Wireless Application Protocol), i-mode & Co.


Mobile, tragbare Multimedia-Ausstattung …


Dateisysteme – Motivation

Zieleffizienter und transparenter Zugriff auf geteilte Daten in einer mobilen Umgebung unter Wahrung der Konsistenz

Problemebeschränkte Ressourcen der Mobilrechner (Speicher, CPU, ...)eingeschränkte und stark schwankende Bandbreite des Netzes, teilweise totale Abkopplunghochgradige Heterogenität der Komponentenes kann sich nicht auf Netzressourcen oder Mobilrechner verlassen werdenStandarddateisysteme nicht nur ineffizient, sie versagen!

IdeenReplikation von Daten (Vervielfachung, Kopieren, Caching)vorausschauendes Sammeln von Daten (Hoarding, pre-fetching)


Dateisysteme - Konsistenzproblematik

DAS Hauptproblem bei verteilten, lose gekoppelten Systemensind alle Sichten auf Daten gleich?wie und wann werden welche Änderungen an Daten an welche Teilnehmer propagiert?

Schwache Konsistenzviele Algorithmen für starke Konsistenz (z.B. durch Atomizität der Aktualisierungen) unbrauchbar in mobiler Umgebungungültig erklären von Daten im Cache durch den Server problematisch bei Abkopplungzeitweise Inkonsistenzen werden daher in Kauf genommen, nachfolgende Konfliktlösungen

Konflikterkennungeninhaltsunabhängig: Versionsnummern, Zeitstempelinhaltsabhängig: Abhängigkeitsgraphen


Dateisysteme für eingeschränkte Ankopplung I

SymmetrieClient/Server oder Peer-to-Peer BeziehungUnterstützung auf Festnetz- und/oder Mobilseiteein einziges oder mehrere Dateisystemedurchgängiger Namensraum für Dateien oder mehrere

Transparenzverbergen der Mobilitätsunterstützung gegenüber Anwendungen auf der Mobilseiteverbergen der Mechanismen gegenüber Benutzern

Konsistenzmodelloptimistisch oder pessimistisch

Caching und Pre-fetchingeinzelne Dateien, Verzeichnisse, Unterbäume, Partitionen, ...permanent oder nur zu gewissen Zeitpunkten


Dateisysteme für eingeschränkte Ankopplung II

DatenhaltungVerwaltung der gepufferten Daten, Kopien von DatenAnforderungen an Erneuerung, Gültigkeit der DatenErkennung von Änderungen in Datenbeständen

Konfliktbehandlunganwendungsspezifisch oder allgemeinFehlerfälle

Verschiedene experimentelle Systeme existieren seit längerem, Beispiele sind Coda (Carnegie Mellon University), Little Work (University of Michigan), Ficus (UCLA) etc.

Viele Systeme beruhen auf Ideen von verteilten Dateisystemen wiebeispielsweise AFS (Andrew File System)


Dateisysteme - Coda I

Anwendungstransparente Erweiterungen von Client und ServerÄnderungen im Cache Manager des ClientAnwendungen arbeiten auf Cache-Replikaten von Dateienumfangreiches, transparentes, vorausschauendes Sammeln von Dateien für eventuelle spätere Nutzung („Hoarding“)

KonsistenzÄnderungen an Dateien werden mitprotokolliert, Dateien bei Wiederankoppluung verglichenwurde eine Datei von verschiedenen Nutzern geändert, so schlägt der Abgleich fehl und manuelle Reintegration ist nötigoptimistischer Ansatz, grobgranular (Dateigröße)

Mobiler Client

CacheAnwendung Server


Dateisysteme - Coda II

HoardingBenutzer kann Dateiliste vorgeben (mit Prioritäten)Cache-Inhalt bestimmt durch Liste und LRU-Strategie (Last RecentlyUsed)explizites pre-fetching möglichperiodische Aktualisierung

Datenabgleichasynchron, im HintergrundAbwägen zwischen Geschwindigkeit der Aktualisierung und Minimierung des Netzverkehrs

Cache MissesModellierung der „Benutzergeduld“, wie lange kann ein Nutzer auf Daten warten ohne Fehlermeldung?Funktion von Größe und Bandbreite

Hoarding

WriteDisconnected

Emulating

Disconnection

Disconnection

Connection

Strongconnection

Weakconnection

Zustände des Client


Dateisysteme - Little Work

Lediglich Änderungen am Cache-Verwalter des ClientVerbindungsmodi und Einsatzarten

Connected(vollgekoppelt)

PartiallyConnected(teilgekoppelt)

Fetch only Disconnected(abgekoppelt)

Methode normal VerzögertesSchreiben zumServer

OptimistischeReplikation vonDateien

Abbruch beiCache miss

Netzanfor-derungen

kontinuierlichhoheBandbreite

kontinuierlich anforderungs-gesteuert

keine

Umgebung Büro, WLAN FunkanbindungniedrigerBandbreite wieBündelfunk

ZellenbasierteMobilfunksystemewie GSM mitKosten pro Ruf

unabhängig


Dateisysteme - weitere Beispiele

Mazer/TardoSynchronisationsschicht zwischen Anwendung und lokalem Dateisystemkomplette Unterverzeichnisse werden vom Server übernommen„Redirector“ erfüllt Anfragen lokal wenn nötig, über das Netzwerk wenn möglichperiodische Konsistenzprüfung mit bidirektionalem Abgleich

Ficuskein Client/Server-Ansatzoptimistisches Arbeiten mit Replikaten, Erkennung von Schreibkonflikten, KonfliktauflösungVerwendung von sog. „Gossip“-Protokollen (Gerüchte): ein Mobilrechner muß nicht unbedingt Kontakt mit einem Server haben - andere Mobilrechner reichen, um Änderungen schrittweise weiterzureichen

MIo-NFS (Mobile Integration of NFS)NFS-Erweiterung, pessimistischer Ansatz, nur Token-Halter kann schreibenverbunden, lose verbunden, abgetrennt


Datenbanken in mobilen Umgebungen

Anfragebearbeitungenergiesparend, ortsabhängig, kostensparendz.B. finde schnellsten Weg zum Krankenhaus

Replikationsverwaltungvgl. Dateisysteme

LokationsverwaltungVerfolgung mobiler Nutzer damit replizierte, unter Umständen ortsabhängige Daten rechtzeitig am richtigen Ort bereitgestellt werden können (Minimierung der Zugriffsverzögerung)vgl. z.B. HLR (Home Location Register) in GSM kann helfen, lokale Pannenhilfe zu finden

Transaktionsbearbeitung„mobile“ Transaktionen können nicht unbedingt auf den gleichen Modellen wie solche in Festnetzen beruhen (Atomizität, Konsistenz, Isolation, Persistenz)daher u.a. Arbeiten zu „schwachen“ Transaktionen


WWW und Mobilität

Protokoll (HTTP, Hypertext Transfer Protocol) und Sprache (HTML, Hypertext Markup Language) des Web wurden nicht für mobile Anwendungen entworfen, daraus resultieren zahlreiche Probleme!

Typische DatengrößenHTTP request: 100-350ByteAntworten typ. <10kByte, Kopf 160Byte, GIF 4,1kByte, JPEG 12,8kByte, HTML 5,6kByteaber auch viele sehr große Dateien, nicht vernachlässigbar

Das Web ist kein Dateisystem!Web-Seiten sind nicht nur einfach Dateien, die geladen werdenstatische und dynamische Inhalte, Interaktion mit Servern über Formulare, Inhaltstransformation, push-Strategienzahlreiche Querverweise, kein transparenter Datenstrom, automatisches Nachladenein Klick auf eine Datei kann große Konsequenzen haben!

WWW-Beispiel

Request to port 80: GET / HTTP/1.0or: GET / HTTP/1.1

Host: www.inf.fu-berlin.deResponse from serverHTTP/1.1 200 OKDate: Wed, 30 Oct 2002 19:44:26 GMTServer: Apache/1.3.12 (Unix) mod_perl/1.24Last-Modified: Wed, 30 Oct 2002 13:16:31 GMTETag: "2d8190-2322-3dbfdbaf"Accept-Ranges: bytesContent-Length: 8994Connection: closeContent-Type: text/html

<DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html>

<head><title>FU-Berlin: Institut für Informatik</TITLE><base href="http://www.inf.fu-berlin.de"><link rel="stylesheet" type="text/css" href="http://www.inf.fu-berlin.de/styles/homepage.css">

</head>

<body onResize="self.location.reload();">...

non persistent


HTTP 1.0 und Mobilität I

Eigenschaftenzustandslos, Client/Server, Anfrage/Antworterfordert verbindungsorientiertes Protokoll, eine Verbindung pro Anfrage (meist TCP eingesetzt) – Verbesserungen in HTTP/1.1primitive Caching- und Sicherheitsmodelle

Problemeentworfen für große Bandbreiten und geringe Verzögerungengroße und redundante Protokollköpfe (lesbar für Menschen, kein gespeicherter Zustand erfordert stets umfangreiche Köpfe)unkomprimierte Übertragung von Inhaltenmit TCP

großer Overhead pro Anfrage durch 3-Wege-Handshake verglichen mit dem eigentlichen Inhalt (z.B. GET request)slow-start Problematik

DNS-lookup durch Client erzeugt zusätzlichen Verkehr


HTTP 1.0 und Mobilität II

Cachingoftmals von Dienstanbietern verhindert damit Benutzungsstatistiken erstellt werden könnendynamische Objekte können nicht im Cache abgelegt werden

zahlreiche Zähler, Datum, Personalisierungen, ...Mobilität macht oft Caches unmöglichSicherheitsproblematik

wie verhält sich SSL im Zusammenhang mit ProxysSehr viele Seiten werden erst nach Anforderung nutzerabhängig erstellt (CGI, ASP, ...)

POST (d.h. Senden zum Server)kann i.allg. nicht gepuffert werden, damit problematisch falls gerade abgekoppelt

Genügend ungelöste Fragen!


HTML und mobile Endgeräte

HTML entworfen für Endgeräte höherer Leistung, Farbdisplay, MausOptimierung der „Ästhetik“, nicht des Kommunikationsaufwandes

Mobile Endgerätehaben oft nur kleine Anzeigen niedriger Auflösung und sehr eingeschränkte Eingabemöglichkeiten

weitere „Features“animierte GIFs, Java AWT, Frames, ActiveX Controls, Shockwave, Filmclips, Audio, ...heute schon werden Echtfarbendarstellung, Multimedia-Unterstützung, hohe Auflösungen beim Entwurf von Web-Seiten vorausgesetzt

Die Mehrzahl der HTML-Seiten enthält FehlerBrowser müssen sehr leistungsfähig sein, um diese Fehler „auszugleichen“

Heterogenität der Endgeräte wird weitgehend ignoriert!also werden z.B. auch große Bilder automatisch zum Mobiltelefon mit geringer Auflösung unter hohen Kosten übertragen !


Ansätze in Richtung Web für mobile Endgeräte

Anwendungs-Gateways, erweiterte Servereinfache Clients, Vorberechnungen im FestnetzKompression, Filterung, Inhaltsextraktionautomatische Anpassung an Netzwerkgegebenheiten

BeispieleSkalierung von Grafiken, Farbreduktion, Änderung des Dokumentenformats (z.B. PS nach TXT)Detailbetrachtungen, Ausschnitte, Zoom Extraktion von Überschriften, Zusammenfassung des TextesHDML: einfache, HTML-ähnliche Sprache mit speziellem BrowserHDTP: passendes Protokoll, entwickelt von Unwired Planet

Problemeproprietäre Ansätze, erfordern eine Menge spezieller Zusätze für Browsergroße Geräteheterogenität erschwert Ansätze


Neue Techniken, die der Mobilität helfen?

Push-Technikechtes push, kein Client-Pull, channels etc.

HTTP/1.1client/server nutzen die selbe Verbindung für mehrere Anfragen/Antwortenmehrere Anfragen zu Beginn einer Sitzung möglich, die Antworten kommen dann in der Anfragereihenfolgeerweiterte Zwischenspeicherung von Antworten möglich (falls Antworten identisch)semantische Transparenz ist nicht immer machbar: abgetrennt, geringe Leistung, Verfügbarkeitneue tags und Optionen um das Caching besser zu steuern (public/private, max-age, no-cache etc.)Konsistenz kann auf Nutzerwunsch abgeschwächt werdenKodierung/Kompression, Integritätsprüfung, Sicherheit von Proxies, Authentisierung, Authentifikation...

Cookies: nun..., Sitzungen mit Zustand, nicht richtig integriert


Systemunterstützung für WWW im Mobilen I

Erweiterte BrowserPre-fetching, caching und abgekoppelte Nutzungz.B. Internet Explorer

Zusätzliche, begleitende AnwendungPre-fetching, caching und abgekoppelte Nutzungz.B. ursprünglicher WebWhacker

Mobiler Client

Browser

Integrierte Erweiterung

WebServer

Mobiler Client

BrowserBegleitendeAnwendung

WebServer


Systemunterstützung für WWW im Mobilen II

Mobiler Client

BrowserClientProxy

WebServer

Client ProxyPre-fetching, caching und abgekoppelte Nutzungz.B. Caubweb, TeleWeb, Weblicator,WebWhacker, WebEx, WebMirror,...

Netzwerk ProxyAdaptive Inhaltstransformation bei schlechter Verbindung, pre-fetching, cachingz.B. TranSend, Digestor

Mobiler Client

Browser

NetzwerkProxy

WebServer


Systemunterstützung für WWW im Mobilen III

Client und Netzwerk ProxyKombination der Nutzen plusProtokollvereinfachungenz.B. MobiScape, WebExpress

Spezielles Netzwerk SubsystemAdaptive Inhaltstransformation bei schlechter Verbindung, pre-fetching, cachingz.B. Mowgli

Zusätzlich viele Server-Erweiterungenmachbar

„Channels“, Inhaltsaushandlung, ...

Mobiler Client

Browser ClientProxy

WebServer

NetzwerkProxy

Mobiler Client

Browser

WebServer

ClientProxy

NetzwerkProxy


WAP - Wireless Application Protocol

ZieleInternet-Inhalte und erweiterte Dienste sollen zu mobilen Endgeräten (Telefone, PDA, ...) geliefert werdenUnabhängigkeit von Standards drahtloser Netzeoffen für alle, Vorschläge („weltweite Protokollspezifikation“) werden Standardisierungsgremien vorgelegtAnwendungen sollen über aktuelle Transportmedien, Gerätetypen hinweg skalieren und auch auf zukünftige Entwicklungen anwendbar sein

Plattformenbeispielsweise GSM (900, 1800, 1900), CDMA IS-95, TDMA IS-136, Systeme der 3. Generation wie IMT-2000, UMTS, W-CDMA, cdma2000 1x EV-DO

ForumFrüher: WAP-Forum, mitgegründet von u.a. Ericsson, Motorola, Nokia, Unwired Planet, weitere Informationen unter www.wapforum.orgJetzt: Open Mobile Alliance www.openmobilealliance.org(Open Mobile Architecture + WAP Forum + SyncML + …)

http://www.wapforum.org/

http://www.openmobilealliance.org/


WAP - Standardisierungsinhalte

Browser„Micro-Browser“, ähnlich der bekannten Browser vom Internet

Script-Spracheähnlich zu Java-Script, angepasst an das mobile Umfeld

WTA/WTAIWireless Telephony Application (Interface): Zugriff auf Telefonfunktionalitäten

Inhaltsformatez.B. Visitenkarten (vCard), Kalenderereignisse (vCalender)

ProtokollstapelTransport-, Sicherheits- und Sitzungsschicht


WAP 1.x - Schichtenarchitektur und Protokolle

Internet WAP

WAE beinhaltet z.B. WML (Wireless Markup Language), WML Script, WTAI

Trägerdienste (GSM, CDPD, ...)

Security Layer (WTLS)

Session Layer (WSP)

Application Layer (WAE)

Transport Layer (WDP)TCP/IP,UDP/IP,Medien

SSL/TLS

HTML, Java

Transaction Layer (WTP)

Weitere Dienste undAnwendungen

A-SAP

S-SAP

TR-SAP

SEC-SAP

T-SAP

HTTP

WCMP


WAP - Netzwerkelemente

MobilnetzFestnetz

WAPProxy

WTAServer

Filter/WAPProxyWeb

Server

Filter

Telefonnetz

Internet

Binary WML

Binary WML

Binary WML

HTML

HTML

HTML WML

WMLHTML

Binary WML: Binäres Datenformat für Klienten


WDP - Wireless Datagram Protocol

Protokoll der Transportschicht der WAP-Architekturliegt direkt auf den Übertragungsdiensten der verschiedenen Netzwerktechnologienbietet eine einheitlich Schnittstelle für die Protokolle höherer Schichtenerlaubt transparente Kommunikation über unterschiedliche Übertragungsdienste (GSM [SMS, CSD, USSD, GPRS, ...], IS-136, TETRA, DECT, PHS, IS-95, ...)

Mit Hilfe von WDP, das nach unten entsprechend des Übertragungsdienstes angepasst ist, soll ein global interoperablesTransportsystem geschaffen werden.

Übertragungsdienste wie z.B. SMS, GPRS von GSM können sich ändern, weiterentwickeln

Zusätzlich dient WCMP (Wireless Control Message Protocol) ähnlich wie ICMP der Steuerung/Fehleranzeige


WDP - Dienstprimitive

T-SAP T-SAPT-DUnitdata.req(DA, DP, SA, SP, UD) T-DUnitdata.ind

(SA, SP, UD) T-DUnitdata.req(DA, DP, SA, SP, UD)

T-DError.ind(EC)


Einsatz von WDP

GSM-SMS

GSM-CSD

WTLSWTLS

WDP &Adaptation

WDP &Adaptation

SMSSMS

Wireless Data GatewayWTLSWTLS

WDP &Adaptation

WDP &Adaptation

TunnelTunnel

SubnetworkSubnetwork

SMSSMS TunnelTunnel


WAPProxy

WTLSWTLS

UDPUDP

WTLSWTLS

UDPUDP

IPIP

PPPPPP

CSD-RFCSD-RF

IPIP


IPIP

PPPPPP

CSD-RFCSD-RF PSTNCircuitPSTNCircuit


InterworkingFunction

Internet Service ProviderRemote Access Service

PSTNCircuitPSTNCircuit


WTLS - Wireless Transport Layer Security

ZieleDatenintegrität

Verhindern von Änderungen an DatenPrivatheit

Verhindern des Mithörens des DatenstromsAuthentifikation

Aufbau von authentifizierten Beziehungen zwischen mobilem Endgerät und einem Server

Schutz vor Denial-of-Service AttackenWiederholungen von Daten und nicht verifizierbare Daten werden abgelehnt

WTLS basiert auf dem TLS (Transport Layer Security) - Protokoll (ehemals SSL, Secure Sockets Layer), hier optimiert für schmalbandige Kommunikationskanäle


Aufbau einer sicheren Sitzung

SEC-Create.req(SA, SP, DA, DP, KES, CS, CM)

SEC-Create.ind(SA, SP, DA, DP, KES, CS, CM)

originatorSEC-SAP

peerSEC-SAP

SEC-Create.cnf(SNM, KR, SID, KES‘, CS‘, CM‘)

SEC-Create.res(SNM, KR, SID, KES‘, CS‘, CM‘)

SEC-Exchange.req

SEC-Exchange.ind

SEC-Exchange.res(CC)SEC-Commit.req SEC-Exchange.cnf

(CC)SEC-Commit.ind

SEC-Commit.cnf


SEC-Unitdata - Datenübertragung (Datagramm)

SEC-Unitdata.req(SA, SP, DA, DP, UD) SEC-Unitdata.ind

(SA, SP, DA, DP, UD)

senderSEC-SAP

receiverSEC-SAP


WTP - Wireless Transaction Protocol

Leichtgewichtiges, transaktionsorientiertes Protokoll

ZieleUnterstützung transaktionsorientierter Dienste

Beispiel: Browser mit typischem Request/Response-VerhaltenVerbesserte Zuverlässigkeit über DatagrammdiensteUnterstützung verschiedener Kommunikationsformen

Anwendung bestimmt Grad der ZuverlässigkeitSpeicherplatzschonendEffizienz bezüglich der Luftschnittstelle

Nachrichtenorientiert statt byteorientiert


WTP im Detail I

Unterstützung verschiedener KommunikationsformenKlasse 0: unzuverlässiges Request

Beispiel: Push-Dienst

Klasse 1: zuverlässiges RequestAuf eine invoke-Nachricht folgt keine result-NachrichtBeispiel: Verlässlicher Push-Dienst

Klasse 2: zuverlässiges Request/ResponseAuf eine invoke-Nachricht folgt genau eine result-NachrichtMit/Ohne ACKBeispiel: Typisches Web-Browsing

Es gibt keinen expliziten Verbindungsaufbau/-abbau!

Dienste für die nächsthöhere Schicht werden als Events bezeichnet


WTP im Detail II

Verwendete Mechanismen:Verlässlichkeit durch

Eindeutige Transaktionsidentifikatoren (TID)ACKsSelektive ÜbertragungswiederholungBeseitigung von duplizierten Nachrichten

Optional: Concatenation & Separation von Nachrichten

Optional: Segmentierung & Reassemblierung

Asynchrone Transaktionen

Transaktionsabbruch, Fehlerbehandlung

Optimierte Verbindungsaufbauten (Aufbau mit Datenübertragung)


WTP Klasse 0 Transaktion

TR-Invoke.req(SA, SP, DA, DP, A, UD, C=0, H) Invoke PDU

TR-Invoke.ind(SA, SP, DA, DP, A, UD, C=0, H‘)

initiatorTR-SAP

responderTR-SAP


WTP Klasse 1 Transaktion, ohne/mit ACK



initiatorTR-SAP

responderTR-SAP

Ack PDUTR-Invoke.cnf(H)



initiatorTR-SAP

responderTR-SAP

Ack PDU

TR-Invoke.res(H‘)

TR-Invoke.cnf(H)


WTP Klasse 2 Transaktion, ohne ACK, ohne hold on



initiatorTR-SAP

responderTR-SAP

Result PDU

TR-Result.req(UD*, H‘)

TR-Result.ind(UD*, H)

Ack PDU

TR-Invoke.cnf(H)

TR-Result.res(H)

TR-Result.cnf(H‘)


WTP Klasse 2 Transaktion, mit ACK



initiatorTR-SAP

responderTR-SAP

Result PDUTR-Result.ind(UD*, H)

Ack PDU

TR-Invoke.res(H‘)

TR-Invoke.cnf(H) Ack PDU


TR-Result.res(H)

TR-Result.cnf(H‘)


WTP Klasse 2 Transaktion, mit hold on, ohne ACK



initiatorTR-SAP

responderTR-SAP

Result PDU


TR-Result.ind(UD*, H)

Ack PDU

Ack PDUTR-Invoke.cnf(H)

TR-Result.res(H)

TR-Result.cnf(H‘)


WSP - Wireless Session Protocol

ZieleHTTP 1.1 Funktionalität

Request/reply, Verhandlung über Inhaltstypen, ...Unterstützung von Client/Server, Transaktionen (simultan, asynchron), Push-TechnikSchlüsselverwaltung, Authentifikation, Internet-SicherheitsdiensteVerwaltung von Sitzungen (Unterbrechung, Wiederaufnahme,...)

Offene PunkteUnterstützung von QoSGruppenkommunikationIsochrone Multimedia-ObjekteVerwaltung


WSP - Protokolle

WSP

Connectionless mode(über WDP oder WTLS)

Connection mode(über WTP)

• Method Invocation• Push

• (generell unzuverlässig)

• Sitzungsmanagement (Klasse 0, 2)

• Method Invocation (Kl. 2)

• Benarichtigung bei Fehlern

• Push (Kl. 0)

• Bestätigter Push (Kl. 1)

• Sitzungsunterbrechung/-aufnahme (Kl. 0, 2)


WSP/B Sitzungsaufbau

S-Connect.req(SA, CA, CH, RC) Connect PDU

S-Connect.ind(SA, CA, CH, RC)

clientS-SAP

serverS-SAP

ConnReply PDU

S-Connect.res(SH, NC)

S-Connect.cnf(SH, NC)

WTP Class 2transaction


WSP/B Sitzungsunterbrechung/-wiederaufnahme

S-Suspend.req Suspend PDUS-Suspend.ind(R)

clientS-SAP

serverS-SAP

Reply PDUS-Resume.res


~ ~

S-Suspend.ind(R)

S-Resume.req(SA, CA) S-Resume.ind

(SA, CA)Resume PDU

S-Resume.cnf



WSP/B Sitzungsbeendigung

Disconnect PDUS-Disconnect.ind(R)

clientS-SAP

serverS-SAP

S-Disconnect.ind(R) WTP Class 0

transaction

S-Disconnect.req(R)


WSP/B Methodenaufruf

S-MethodInvoke.req(CTID, M, RU) Method PDU

S-MethodInvoke.ind(STID, M, RU)

clientS-SAP

serverS-SAP

Reply PDU

S-MethodInvoke.res(STID)

S-MethodInvoke.cnf(CTID)


S-MethodResult.req(STID, S, RH, RB)

S-MethodResult.ind(CTID, S, RH, RB)

S-MethodResult.res(CTID) S-MethodResult.cnf

(STID)


WSP/B über WTP - Methodenaufruf

S-MethodInvoke.reqS-MethodInvoke.ind

clientS-SAP

serverS-SAP

S-MethodInvoke.res

S-MethodInvoke.cnfS-MethodResult.req

S-MethodResult.ind

S-MethodResult.resS-MethodResult.cnf

TR-Invoke.req

initiatorTR-SAP

TR-Result.ind

TR-Invoke.cnf

TR-Result.res

TR-Invoke.ind

responderTR-SAP

TR-Invoke.res

TR-Result.req

TR-Result.cnf

Invoke(Method)

Result(Reply)

Ack PDU

Ack PDU


WSP/B über WTP - asynchrone, ungeordnete Anfragen

S-MethodInvoke_1.req

S-MethodInvoke_1.ind

clientS-SAP

serverS-SAP



S-MethodResult_1.ind







S-MethodResult_1.req

S-MethodResult_2.reqS-MethodResult_3.req

S-MethodResult_4.reqS-MethodInvoke_4.ind


WSP/B - bestätigter/nicht bestätigter push

S-Push.req(PH, PB)

clientS-SAP

serverS-SAP

ConfPush PDU

S-Push.ind(PH, PB)


Push PDU

S-ConfirmedPush.req(SPID, PH, PB)


S-ConfirmedPush.res(CPID)

S-ConfirmedPush.ind(CPID, PH, PB)

clientS-SAP

serverS-SAP

S-ConfirmedPush.cnf(SPID)


WSP/B über WDP

S-Unit-MethodInvoke.req(SA, CA, TID, M, RU)

clientS-SAP

serverS-SAP

S-Unit-MethodResult.ind(CA, SA, TID, S, RH, RB)

S-Unit-Push.ind(CA, SA, PID, PH, PB)

S-Unit-MethodInvoke.ind(SA, CA, TID, M, RU)

S-Unit-MethodResult.req(CA, SA, TID, S, RH, RB)

S-Unit-Push.req(CA, SA, PID, PH, PB)

Method PDU

Reply PDU

Push PDU

WDP Unitdataservice


WAE - Wireless Application Environment

Zielenetzwerkunabhängige Anwendungsumgebung für schmalbandige drahtlose Geräteintegriertes Internet/WWW-Programmiermodell hoher Interoperabilität

Anforderungengeräte- und netzwerkunabhängig, internationale Unterstützungherstellerbestimmbare Mensch-Maschine-SchnittstelleBeachtung von langsamen Verbindungen, geringem Speicher, begrenzter Rechenleistung, kleinem Bildschirm, einfache Eingabe

KomponentenArchitektur: Anwendungsmodell, Browser, Gateway, ServerWML: XML-Syntax, basiert auf Karteikartenmetapher, Variablen, ...WMLScript: prozedural, Schleifen, Bedingungen, ... (ähnlich JavaScript)WTA: Telefonanwendungen wie Rufsteuerung, Textnachrichten, Telefonbuch, ... (von WML/WMLScript zugreifbar)Inhaltsformate: vCard, vCalendar, Wireless Bitmap, WML, ...


WAE logisches Modell

Ursprungs-Server Gateway Client

andereWAE

user agents

WMLuser agent

WTAuser agent

Kodierer&

Dekodierer

webserver

andereserver

Anfrage

AntwortmitInhalt

pushInhalt

kodierteAnfrage

kodierteAntwortmitInhalt

kodierterpushInhalt


Wireless Markup Language (WML)

WML folgt einer Stapel/Blatt (Skat) [deck] und Karten [card] MetapherWML-Dokumente bestehen aus vielen Karten, Karten werden zu Stapeln gruppiertein Stapel ist einer HTML-Seite ähnlich und stellt eine Übertragungseinheit darWML beschreibt nur die Absicht einer Interaktion in einer abstrakten Artdie Umsetzung/Präsentation hängt dann von den Gerätefähigkeiten ab

EigenschaftenTexte, BilderBenutzerinteraktionNavigationInhaltsverwaltung


WML – Beispiel I

<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>

<card id="Karte_eins" title="Einfaches Beispiel"><do type="accept">

<go href="#Karte_zwei"/></do>

<p>Dies ist eine einfache erste Karte!<br/>

Auf der folgenden Karte kann eine ...</p>

</card>


WML – Beispiel II

<card id="Karte_zwei" title="Pizzawahl"><do type="accept" label="weiter">

<go href="#Karte_drei"/></do><p>... Pizza bestellt werden!<select value="Mar" name="PIZZA">

<option value="Mar">Margherita</option><option value="Fun">Funghi</option><option value="Vul">Vulcano</option>

</select></p>

</card><card id="Karte_drei" title="Die Pizza!">

<p>Ihr Pizzaparameter ist <b>$(PIZZA)</b>!</p>

</card></wml>


WMLScript

Ergänzung zu WML

Stellt allgemeine Skript-Fähigkeiten zur Verfügung

EigenschaftenGültigkeitsüberprüfung von Benutzereingaben

Überprüfung der Eingabe bevor diese an einen Server gesendet wirdZugriff auf Gerätefunktionen

Hardware und Software (Telefonanruf, Adressbuch etc.)lokale Benutzerinteraktion

Interaktion ohne Verzögerung (RTT)Erweiterung der Geräte-Software

Gerätekonfiguration, Laden neuer Funktionen nach der Auslieferung


WMLScript - Beispiel

function pizza_test(pizza_typ){

var geschmack="unbekannt";if (pizza_typ="Mar") {

geschmack="Na ja ...";}else {

if (pizza_typ="Vul") {geschmack="Gut scharf";

};};return geschmack;

};


Wireless Telephony Application (WTA)

Sammlung telefonspezifischer ErweiterungenErweiterung des Standard-WAE-Anwendungsmodells

content pushein Server kann Inhalte direkt auf einen Client schiebender Client kann nun evtl. bisher unbekannte Ereignisse verarbeiten

Behandlung von Netzereignisseneine Tabelle zeigt auf, wie auf bestimmte Ereignisse vom Netz zu reagieren ist

Zugang zu Telefonfunktionenjede Anwendung auf dem Client kann auf Telefonfunktionen zugreifen

BeispielRufen einer Nummer (WML)wtai://wp/mc;07216086415

Rufen einer Nummer (WMLScript)WTAPublic.makeCall("07216086415");


WTA logische Architektur

WeitereServer

Client

Repository

WTA-User-Agent

WTA-Gateway

Codierer&

Decodierer

Andere Telefonnetze

WTA-Server

WTA & WMLserver

WML-Skripte

WML-Stapel

WTA-Dienste

MobilesNetz

FirewallDrittanbieterServer

Gesichertes Netzdes Betreibers

Gerätespez.Funktionen


Voice box - Beispiel

Service Indication

WTA-User-Agent WTA-Server Mobilnetz Sprachbox

Erzeugeneuen Inhalt

Anzeige;Nutzerwahl

Verbindungs-aufbau

AkzeptiereRuf

Sprachverbindung

Anzeige einer neuen Sprachnachricht

Spiele angefragte Sprachnachricht ab

Verbindungsaufbau

Rufannahme Rufannahme

WTA-Gateway

Push URL

Anzeige;Nutzerwahl WSP Get HTTP Get

Antworte mitInhaltWMLBinary WML

WSP Get HTTP GetAntworte mitKarte für RufWMLBinary WML

Warte aufRuf

Verbindungsaufbau


WTAI - Beispiel: nur WML

<?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml"><wml>

<card id="Karte_eins" title="Telewahl"><do type="accept">

<go href="#Karte_zwei"/></do><p> Bitte geben Sie Ihren Kandidaten an! </p>

</card><card id="Karte_zwei" title="Ihre Wahl">

<do type="accept"><go href="wtai://wp/mc;$wahlnr"/>

</do><p> Ihre Auswahl:<select name="wahlnr">

<option value="01376685">Mickey</option><option value="01376686">Donald</option><option value="01376687">Pluto</option>

</select></p>

</card></wml>


WTAI - Beispiel: WML und WMLScript I

function wahlanruf(Nr) {

var j = WTAVoiceCall.setup(Nr,1);if (j>=0) {

WMLBrowser.setVar("Nachricht", "Angerufen:");WMLBrowser.setVar("No", Nr);

}

else {WMLBrowser.setVar("Nachricht", "Fehlschlag!");

WMLBrowser.setVar("No", j);}WMLBrowser.go("Ergebniskarte");

}


WTAI - Beispiel: WML und WMLScript II

<?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml"><wml>

<card id="Karte_eins" title="Telewahl"><do type="accept"> <go href="#Karte_zwei"/> </do><p> Bitte geben Sie Ihren Kandidaten an! </p>

</card><card id="Karte_zwei" title="Ihre Wahl">

<do type="accept"><go href="/meinescripts#wahlanruf($wahlnr)"/> </do>

<p> Ihre Auswahl:<select name="wahlnr">

<option value="01376685">Mickey</option><option value="01376686">Donald</option><option value="01376687">Pluto</option>

</select> </p></card><card id="Ergebniskarte" title="Ergebnis">

<p> Status: $Nachricht $No </p></card>

</wml>


WAP-Push-Architektur mit Proxy-Gateway

Push Access ProtocolÜbertragung von Inhalten zwischen Server und PPGerste Variante nutzt HTTP

Push OTA (Over The Air) ProtocolEinfach, optimiertwird auf WSP abgebildet

Client

User Agents

Push Proxy Gateway

Codierung,Überprüfung

Push OTAProtocol

Push Initiator

PushAccessProtocol

Server-Anwendung


Push/Pull-Dienste in WAP I

Service IndicationKurze Mitteilung über einen Dienst durch einen PushNutzung des Dienstes durch einen PullIdentifikation durch URI

<?xml version="1.0"?><!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN""http://www.wapforum.org/DTD/si.dtd">

<si><indication href="http://www.piiiizza4u.de/angebot/salat.wml"

created="2000-02-29T17:45:32Z"si-expires="2000-02-29T17:50:31Z">Salat-Spezial: Das 5-Minuten-Angebot

</indication></si>


Push/Pull-Dienste in WAP II

Service LoadingKurze Push-Nachricht an den Client mit URINutzeragent entscheidet über Nutzung der URI durch PullTransparent für einen Nutzer, sieht immer wie ein Push aus

<?xml version="1.0"?>

<!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN""http://www.wapforum.org/DTD/sl.dtd">

<sl

href="http://www.piiiizza4u.de/angebot/salat.wml"></sl>


Beispiele für WAP-Protokollstapel (WAP 1.x)

WAP-Standardisierung

WAE user agentaußerhalb WAP

WAE

WSP transaktionsbasierteAnwendungen

WTP WTP datagrammbasierteAnwendungen

UDP

IP(GPRS, ...)

WDP

non IP(SMS, ...)

WTLS

UDP

IP(GPRS, ...)

WDP

non IP(SMS, ...)

WTLS

UDP

IP(GPRS, ...)

WDP

non IP(SMS, ...)

WTLS

Reine Datenanwendungen evtl. ohne zusätzlich benötigte Sicherheit

typische WAP-Anwendung mit

komplettem Protokollstapel


i-mode – vor allem ein Geschäftsmodell!

Zugang zu Internet-Diensten in Japan/NTT DoCoMoDienste

Email, Kurznachrichten, Web, Austausch von Bildern, Horoskope, ...Sehr großer Erfolg, über 30 Mio. Nutzer

Für viele ist dies ein PC-Ersatz, PC-Dichte in Japan „relativ“ niedrigErmöglichte für viele ersten Internet-KontaktSehr einfach und bequem in der Handhabung

Technik9,6 kbit/s (Erweiterungen bis zu 28,8 kbit/s), paketorientiert (PDC-P)Compact HTML plus proprietäre tags, spezielle Transportschicht (stop&go, ARQ, push, verbindungsorientiert)

Mobiles Endgerät Mobilnetz Gateway Inhalteanbieter

PDC-P

TLHTTP(S)

cHTML + tags

PDC-P

TL

L1L2IP

TCP

L1L2IP

TCP

L1L2IP

TCP

L1L2IP

TCPHTTP(S)

cHTML + tags


i-mode push mit SMS

Anwendung

WSP

WTP

WDP

SMS

Netzbetreiber schickt eine SMS mit Push-Nachrichtfalls eine email vorliegt. Danach erfolgt ein HTTP-Get mit der email als Antwort, falls ein Nutzer die email lesen möchte.

i-mode ist ein Geschäftsmodell:- Inhalteanbieter bekommen >80%der Gebühren.

- technologieunabhängig(GSM/GPRS in Europa,PDC-P in Japan – aber auch UMTS!)

Häufiges Missverständnis:WAP war kein Erfolg, i-mode istunterschiedlich und ein Erfolg – falschaus technischer Sicht, richtig auswirtschaftlicher Sicht…


i-mode Protokollstapel auf WAP 2.0 basierend

Endgerät Gateway Server

cHTML

HTTP

WTCP

IP

L2

L1

SSL

WTCP

IP

L2

L1

TCP

IP

L2

L1

cHTML

HTTPSSL

TCP

IP

L2

L1

i-mode kann WAP –Protokolle nutzen (z.B.: i-mode in Deutschland über GSM/GPRS)


i-mode – Technische Anforderungen

Functions Descriptions Status Requirement

WEB Access Portal Site / Internet Access M i-mode HTML (cHTML+tags)

E-mail Internet e-mail and inter-terminal email M HTTP 1.1

Security End-End security O SSL (Version 2, 3), TLS 1

Java Java application made available O Compatible i-mode JAVA

Ringing tone download Ringing melody download M SMF based

Image download Stand-by screen download M GIF (O: JPEG)

Voice call notification during i-mode session

Voice termination notified and responded during i-mode communications

M 3GPP standard system

Content charge billing Per content charge billed to user M Specifications depend on each operator’s billing system

Third party payment collection Content charge collection on behalf of Content Provider M Specifications depend on each operator’s billing system

Reverse billing Packet usage charges can be billed to third party O Specifications depend on each operator’s billing system

Subscriber ID transmission Hashed subscriber ID from the operator’s portal to the CP transmission on each content access

M The ID generation algorithm should be determined by each operator and has to be secret

Number of characters per e-mail

Number of characters (byte) per e-mail M To be defined by operators (e.g. 500 byte, 1K byte, 10K byte)

Character code set supported Character code set supported by browser and used to develop content M To be defined by operators

User Agent Browser specifications to be notified M HTTP 1.1

i-mode button Dedicated button O Hard or soft key


i-mode Beispiele I


i-mode Beispiele II


i-mode Beispiele III


WAP 2.0 (Juli 2001)

Neu für EntwicklerXHTMLTCP mit „Wireless Profile“HTTP

Neue AnwendungenFarbgrafikAnimationLaden großer DateienOrtsabhängige DiensteSynchronisation mit PIMsPop-up/kontextsensitive Menüs

Ziel: Integration von WWW, Internet, WAP, i-mode


WAP 2.0 Architektur

Dienste-lokalisierung

Sicherheits-dienste

Anw

endu

ngs-

rahm

enw

erkMultimedia Messaging

(Email)

WAE/WTA User Agent (WML, XHTML)

Inhalts-formate

PushExterne Dienste EFI

Provisioning

NavigationDiscovery

ServiceLookup

Krypto-Bibliotheken

Authenti-fizierung

Identifikation

PKI

GesicherterTransport

GesicherteTräger

Pro

toko

llrah

men

wer

k

Sitz

ung

Tran

sfer

Tran

spor

tTr

ägerIPv4

IPv6

CSD

SMS

USSD

FLEX

GUTS

MPAK

...

...

Datagramme(WDP, UDP)

Verbindungen(TCP mit

wireless profile)

Hypermedia Transfer (WTP+WSP, HTTP)

Strea-ming

MMSNach-richten

PushOTA

Capability Negotiation

Synchronisation Cookies


WAP 2.0 Protokollstapel

WAP-Gateway Web-ServerWAP-Gerät

TrägerWDPWTLSWTPWSPWAE

TrägerWDPWTLSWTPWSP

IPTCPTLS

HTTP

IPTCPTLS

HTTP

WAEWAP-Proxy Web-ServerWAP-Gerät

IPTCP‘HTTPWAE

IPTCP‘

IPTCP

IPTCP

WAEHTTP HTTP HTTP

WAP 1.x Server/Gateway/Client WAP HTTP Proxy mit angepasstem TCP

WAP-Proxy Web-ServerWAP-GerätWeb-ServerWAP-Gerät

IPTCP‘TLS

HTTPWAE

IPTCP‘

IPTCP

IPTCPTLS

HTTPWAE

IPTCP‘HTTPWAE

IP IP IPTCP

WAEIP-Router HTTP

WAP Proxy mit TLS-Tunneling WAP Direkter Zugriff


Java 2 Platform Micro Edition

„Java-Boom erwartet“ (?)Desktop-Bereich: über 90% Standard-PC-Architektur, Intel-x86-kompatibel, meist MS-Windows-SystemeWas soll hier Plattformunabhängigkeit helfen?

ABER: Heterogene, „kleine“ GeräteInternet Appliances, Mobilfunktelefone, eingebettete Steuerungen, Autoradios, ...Aus technischer Notwendigkeit (Temperatur, Platz, Leistungsaufnahme, ...) und Kostengründen unterschiedliche Hardware benötigt

J2MEBereitstellung einer einheitlichen PlattformTeilweise eingeschränkter Funktionsumfang im Vergleich zu Standard-Java-Plattform


Anwendungen von J2ME

Beispiel MobiltelefoneNTT DoCoMo führt iαppli einAnwendungen auf PDA, Handy, ...Laden von Spielen, Multimedia-Anwendungen, Verschlüsselung, SystemaktualisierungenZusatzfunktionen gegen Geld auf Knopfdruck laden

Eingebettete SteuerungenHausgeräte, Fahrzeuge, Überwachungssysteme, GerätesteuerungenVorrangig Systemaktualisierung


Kenndaten und Architektur

Java Virtual MachineVirtuelle Hardware (Prozessor)KVM (K Virtual Machine)

Min. 128 kByte, typ. 256 kByteOptimiert für leistungsschwache GeräteKann durch Coprozessor realisiert sein

KonfigurationenUntermenge der Bibliotheken bzgl. Standard-Java in Abhängigkeit der techn. Parameter (Speicher, CPU)CLDC (Connected Limited Device Configuration)

Basis-Bibliotheken, Eingabe/Ausgabe, Sicherheit, Umfang der Java-Unterstützung für mobile Geräte

ProfileInteroperabilität auch über heterogene Geräte hinweg, welche jedoch einer Kategorie angehörenMIDP (Mobile Information Device Profile)

Definiert Schnittstellen für grafische Oberfläche, HTTP, Anwendungsunterstützung, ...

Hardware(SH4, ARM, 68k, ...)

Java Virtual Machine(JVM, KVM)

Betriebssystem(EPOC, Palm, WinCE)

Konfigurationen(CDC, CLDC)

Profile(MIDP)

Anwendungen


Hardware-unabhängige Entwicklung


Zusammenfassung J2ME

Idee geht über WAP 1.x oder i-mode hinausVollständige Anwendungen auf Mobiltelefonen, nicht nur BrowserAuch Systemaktualisierungen, Ende-zu-Ende-Verschlüsselung

Plattformunabhängigkeit durch VirtualisierungSolange bestimmte Schnittstellen eingehalten werdenNicht bei Hardware-spezifischen Funktionen

Eingeschränkte Funktionalität im Vergleich zu JVMÜbergangslösung, bis auch eingebettete Systeme/Mobiltelefone etc. gleiche Leistungsfähigkeit wie heutige Desktopsysteme besitzen

mobilkommunikation kapitel 10: mobilitätsunterstützung · prof. dr.-ing. jochen schiller, mc...

Documents