File Systems — Motivation ‰

Goal: – Efficient and transparent access to shared files within a mobile environment, while maintaining data consistency

‰

10. Support for Mobility File Systems and Data Bases WWW WAP and i-mode

Problems: – Limited resources of mobile computers (memory, CPU, ...) – Low bandwidth, variable bandwidth, temporary disconnection – High heterogeneity of hardware and software components (no standard PC architecture) – Wireless network resources and mobile computer are not very reliable – Standard file systems (e.g., NFS, network file system) are very inefficient, almost unusable

‰

Solutions: – Replication of data (copying, cloning, caching) – Data collection in advance (hoarding, pre-fetching)

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 1

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

File Systems — Consistency Problems ‰

THE big problem of distributed, loosely coupled systems:

File Systems for Limited Connectivity (1) ‰

– Are all views on data the same? – How and when should changes be propagated to what users? ‰

‰

Conflict detection:

‰

M10 – 3

Client/Server or Peer-to-Peer relations Support in the fixed network and/or mobile computers One file system or several file systems One namespace for files or several namespaces

Transparency: – Hide the mobility support, applications on mobile computers should not notice the mobility – User should not notice additional mechanisms needed

‰

Consistency model:

‰

Caching and pre-fetching:

– Optimistic or pessimistic – Single files, directories, sub-trees, partitions, ... – Permanent or only at certain points in time

– Content independent: version numbering, time-stamps – Content dependent: dependency graphs © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Symmetry: – – – –

Weak consistency: – Many algorithms offering strong consistency (e.g., via atomic updates) cannot be used in mobile environments – Invalidation of data located in caches through a server is very problematic, if the mobile computer is currently not connected to the network – Occasional inconsistencies have to be tolerated, but conflict resolution strategies must be applied afterwards to reach consistency again

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

File Systems for Limited Connectivity (2) ‰

Data management:

‰

‰

‰

Several experimental systems exist, e.g.: – Coda (Carnegie Mellon University) – Little Work (University of Michigan) – Ficus (UCLA)

‰

Consistency: – System keeps a record of changes in files and compares files after reconnection – If different users have changed the same file a manual reintegration of the file into the system is necessary – Optimistic approach, coarse grained (file size) Mobile Client

Many systems use ideas from distributed file systems such as, e.g., AFS (Andrew File System) from 1988

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Application-transparent extensions of client and server: – Changes in the cache manager of a client – Applications use cache replicates of files – Extensive, transparent collection of data in advance for possible future use („Hoarding“)

Conflict solving: – Application-specific or general – Errors

M10 – 4

File Systems — Coda (1)

– Management of buffered data and copies of data – Request for updates, validity of data – Detection of changes in data ‰

M10 – 2

M10 – 5

Application

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Cache

Server

M10 – 6

1

File Systems — Coda (2) ‰

‰

Hoarding: Client States

– Contents of cache determined by the list and LRU strategy (Last Recently Used) – Periodic updating

‰

hoarding

– Explicit pre-fetching possible disconnection

Connected Method

write disconnected

– System weighs speed of updating against minimization of network traffic

Cache misses:

Connection modes and use:

strong connection

weak connection

Comparison of files: – Asynchronous, background

‰

Changes performed in the cache manager of the client only: – Re-write of data into the server resolves conflicts

– User can pre-determine a file list with priorities

‰

File systems — Little Work

normal

Partially Connected delayed write to the server continuous bandwidth

Network continuous requirements high bandwidth Application office, WLAN packet radio

connection disconnection emulating

– Modeling of user patience: how long can a user wait for data without an error message? ‰

– Function of file size and bandwidth © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 7

‰

Mazer/Tardo 1994: – – – –

‰

Ficus from 1990/1992:

‰

MIo-NFS (Mobile Integration of NFS) from 1995: – NFS extension, pessimistic approach, only token holder can write – Connected/loosely connected/disconnected

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 9

The HTTP protocol (Hypertext Transfer Protocol) and the HTML language (Hypertext Markup Language) of the Web have not been designed for mobile applications and mobile devices: – Thus creating many problems!

‰

Typical transfer sizes: – – – –

‰

HTTP request: 100-350 byte Responses average less than 10 kbyte, header of 160 byte GIF 4.1 kbyte, JPEG 12.8 kbyte, HTML 5.6 kbyte But also many large files that cannot be ignored

The Web is no file system: – Web pages are not simple files to download – Static and dynamic content, interaction with servers via forms, content transformation, push technologies etc. – Many hyperlinks, automatic loading and reloading, redirecting – A single click might have big consequences!

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 11

M10 – 8

Request processing:

‰

Replication management:

‰

Location management:

– Similar to file systems – Tracking of mobile users to provide replicated or location-dependent data in time at the right place (minimize access delays) – Example: with the help of the HLR (Home Location Register) in GSM a mobile user can find a local towing service ‰

Transaction processing: – “Mobile” transactions can not necessarily rely on the same models as transactions over fixed networks: • ACID: atomicity, consistency, isolation, durability • Therefore, models address “weak” transactions

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

World Wide Web (WWW) and Mobility ‰

independent

– Power conserving, location-dependent, cost efficient – Example: find the fastest way to a hospital

– Not a client/server approach – Optimistic approach based on replicates, detection of write conflicts, conflict resolution within directories – Use of „gossip“ protocols: • A mobile computer does not necessarily need to have a direct connection to a server, with the help of other mobile computers updates can be propagated through the network -> Problem of slow propagation of data changes

cellular systems (e.g., GSM) with costs per call

Database Systems in Mobile Environments ‰

File synchronization layer between application and local file system Caching of complete subdirectories from the server “Redirector” responses to requests locally if necessary, via the network if possible Periodic consistency checks with bi-directional updating

Disconnected abort at cache miss none

Developed in 1993/95

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

File Systems — Further Examples

Fetch only optimistic replication of files connection on demand

M10 – 10

WWW Example Request to port 80: or:

GET / HTTP/1.0 GET / HTTP/1.1 Host: www.inf.fu-berlin.de

Response from server HTTP/1.1 200 OK Date: Wed, 30 Oct 2002 19:44:26 GMT Server: Apache/1.3.12 (Unix) mod_perl/1.24 Last-Modified: Wed, 30 Oct 2002 13:16:31 GMT ETag: "2d8190-2322-3dbfdbaf" Accept-Ranges: bytes Content-Length: 8994 Connection: close Content-Type: text/html

non persistent

FU-Berlin: Institut für Informatik ... © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 12

2

HTTP 1.0 and Mobility (1) ‰

Characteristics:

HTTP 1.0 and Mobility (2) ‰

– Stateless, client/server, request/response – Needs a connection-oriented protocol (TCP), one connection per request (some enhancements in HTTP 1.1) – Primitive caching and security ‰

– Quite often disabled by information providers to be able to create user profiles or usage statistics – Dynamic objects cannot be cached at all: • Numerous counters, time, date, personalization, ... – Mobility quite often inhibits caches – Security problems:

Problems: – Designed for large bandwidth (compared to wireless access) and low delay – Large and redundant protocol headers: • Readable for humans, stateless, therefore, large headers in ASCII – Uncompressed content transfer – Using TCP: • Huge overhead per request (3-way-handshake) compared with the content, e.g., of a GET request • Slow-start problematic – DNS lookup by client causes additional traffic

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

• How to use SSL/TLS together with proxies? – Today: • Many user-customized pages, dynamically generated on request, CGI or ASP ‰

HTML:

– Can typically not be buffered, very problematic if currently disconnected ‰

‰

Mobile devices:

‰

‰

Additional “features”:

Web pages ignore the heterogeneity of end-systems! – E.g., without additional mechanisms, large high-resolution pictures would be transferred to a mobile phone with a low-resolution display causing high costs

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 15

New Issues in Support of Mobility ‰

Push technology:

‰

Problems: – Proprietary approaches, require special enhancements for browsers – Heterogeneous devices make approaches more complicated M10 – 16

System Support for WWW in a Mobile World (1) ‰

Enhanced browsers:

Mobile Client

– No pre-fetching, some caching, off-line use – E.g., Internet Explorer, Netscape

HTTP/1.1 (1997): Client/server use the same connection for several request/response transactions Multiple requests at beginning of session, several responses in same order Enhanced caching of responses (useful if equivalent responses!) Semantic transparency (not visible to client and server) not always achievable: disconnected, performance, availability -> most up-to-date version... – Several more tags and options for controlling caching (e.g., public/private, maxage, no-cache) – Relaxing of transparency on app. request or with warning to user – Encoding/compression mechanism, integrity check, security of proxies, authentication, authorization...

Examples:

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

– Real pushing, not a client pull needed, channels ‰

Application gateways, enhanced servers:

– Picture scaling, color reduction, transformation of the document format, e.g., PS to TXT – Detail studies, clipping, zoom – Headline extraction, automatic abstract generation – HDML (handheld device markup language): simple language similar to HTML requiring a special browser – HDTP (handheld device transport protocol): transport protocol for HDML, developed by Unwired Planet

AWT: Abstract Window Toolkit

– Animated GIF, Java AWT, Frames, ActiveX Controls, Shockwave, movie clips, audio, ... – Many web pages assume true color, multimedia support, high-resolution and many plug-ins ‰

M10 – 14

– Simple clients, pre-calculations in the fixed network – Compression, filtering, content extraction – Automatic adaptation to network characteristics

– Often only small, low-resolution displays, very limited input interfaces: • Small touch-pads, soft-keyboards

Many unsolved problems!

Approaches toward WWW for Mobile Devices

– Designed for computers with “high” performance, color high-resolution display, mouse, hard disk – Typically, web pages optimized for design, not for communication ‰

CGI: Common Gateway Interface ASP: Application Service Provider

POSTing (i.e., sending to a server):

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 13

HTML and Mobile Devices ‰

Caching:

Integrated Enhancement

Browser

– – – –

‰

Web Server

‰

Additional, accompanying application: – Pre-fetching, caching, off-line use – E.g., original WebWhacker – Non-transparent for Browser: two access potentials available!

Cookies: Stateful sessions, not really integrated...

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 17

Mobile Client Browser Additional Application

Web Server © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 18

3

System Support for WWW in a Mobile World (2) ‰

Client Proxy:

‰

Mobile Client

– Pre-fetching, caching, off-line use – E.g., Caubweb, TeleWeb, Weblicator, WebWhacker, WebEx, WebMirror, … – Transparent! – Strategies: Load all pages being hyper-linked, load pages w/o graphics, or load based on keyword

System Support for WWW in a Mobile World (3)

Client Proxy

‰

Network Proxy: Browser

– Adaptive content transformation for bad connections, pre-fetching, caching – E.g., TranSend, Digestor

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Network Proxy

‰

Web Server

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 19

Goals:

Network Proxy

Browser

Web

Client Proxy

Network Proxy

M10 – 20

WAP — Scope of Standardization ‰

Browser: – “Micro browser”, similar to existing, well-known browsers in the Internet

‰

Script language: – Similar to Java script, adapted to the mobile environment

‰

WTA/WTAI: – Wireless Telephony Application (Interface): access to all telephone functions

Platforms: – E.g., GSM (900, 1800, 1900), CDMA IS-95, TDMA IS-136, 3rd generation systems (IMT-2000, UMTS, W-CDMA, cdma2000 1x EV-DO, …)

‰

Web Server

– “Channels”, content negotiation, change of protocols Server

– Deliver Internet content and enhanced services to mobile devices and users such as mobile phones and PDAs – Independence from wireless network standards – Open for everyone to participate, protocol specifications will be proposed to standardization bodies – Applications should scale well beyond current transport media and device types and should also be applicable to future developments ‰

Client Proxy

Mobile Client

Additionally, many proprietary server extensions possible:

WAP — Wireless Application Protocol ‰

Browser

Special network subsystem: – Adaptive content transformation for bad connections, pre-fetching, caching – E.g., Mowgli

Mobile Client ‰

Mobile Client

– Combination of benefits plus simplified protocols – E.g., MobiScape, WebExpress

Browser

Web Server

Client and network proxy:

‰

Content formats: – E.g., business cards (vCard), calendar events (vCalender)

Forum: – Was: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired Planet, further information http://www.wapforum.org – Now: Open Mobile Alliance http://www.openmobilealliance.org (Open Mobile Architecture + WAP Forum + SyncML + …)

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

‰

Protocol layers:

‰

WAP 1.0 in 1998, 1.1 in 05/1999, 1.2 in 11/1999

– Transport layer, security layer, session layer

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 21

WAP 1.x — Reference Model and Protocols Internet HTML, Java

M10 – 22

WAP — Network Elements

WAP

A-SAP

Fixed Network

Application Layer (WAE) S-SAP

Additional Services and Applications

Internet

Wireless Network WML

HTML Filter

WAP Proxy

Binary WML

Session Layer (WSP) HTTP

TR-SAP

HTML

WML HTML

Transaction Layer (WTP) Web Server

SEC-SAP SSL/TLS

Security Layer (WTLS)

HTML

Filter/ WAP Proxy

T-SAP TCP/IP, UDP/IP, Media

Transport Layer (WDP)

WTA Server

WCMP

Binary WML

PSTN Bearers (GSM, CDPD, ...) Binary WML: binary file format for clients

WAE comprises of WML (Wireless Markup Language), WML Script, WTAI © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Binary WML

M10 – 23

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 24

4

WDP — Wireless Datagram Protocol ‰

WDP — Service Primitives

Protocol of the transport layer within the WAP architecture: – Uses directly transports mechanisms of different network technologies – Offers a common interface for higher layer protocols – Allows for transparent communication using different transport technologies (GSM [SMS, GPRS, ...], IS-136, TETRA, DECT, ...)

‰

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

T-DUnitdata.ind (SA, SP, UD)

Goals of WDP: T-DUnitdata.req (DA, DP, SA, SP, UD)

– Create a world-wide interoperable transport system with the help of WDP adapted to the different underlying technologies – Transmission services such as SMS, GPRS in GSM might change, new services can replace the old ones ‰

T-SAP

T-DError.ind (EC) DA: Destination Address SA: Source Address DP: Destination Port SP: Source Port UD: User Data EC: Error Code

Additionally, the WCMP (Wireless Control Message Protocol) is used for control/error report (similar to ICMP in the TCP/IP protocol suite)

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 25

Usage of WDP

GSM-SMS Short Message Service

WTLS — Wireless Transport Layer Security

Wireless Data Gateway

WTLS WTLS WDP WDP && Adaptation Adaptation SMS SMS

Tunnel Tunnel

WTLS WTLS WDP WDP && Adaptation Adaptation Tunnel Tunnel

Subnetwork Subnetwork

Subnetwork Subnetwork

SMS SMS

‰

Circuit-switched Data

Internet Service Provider Remote Access Service

UDP UDP IP IP PPP PPP CSD-RF CSD-RF

IP IP

Interworking Function CSD-RF CSD-RF

PSTN PSTN Circuit Circuit

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

PPP PPP PSTN PSTN Circuit Circuit

• Prevention of changes in data – Privacy: • Prevention of tapping – Authentication: • Creation of authenticated relations between a mobile device and a server – Protection against denial-of-service attacks

UDP UDP

Subnetwork Subnetwork

Secure Session with a Full Handshake Peer SEC-SAP

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

‰

WTLS: – Is based on the TLS (Transport Layer Security) protocol (formerly on SSL, Secure Sockets Layer) – Optimized for low-bandwidth communication channels

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 27

Originator SEC-SAP

• Protection against repetition of data and unverified data

WTLS WTLS IP IP

Subnetwork Subnetwork

Goals: – Data integrity:

WAP Proxy

GSM-CSD WTLS WTLS

M10 – 26

M10 – 28

SEC-Unitdata — Transferring Datagrams

SEC: Session Create

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

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

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

KES. Key Exchange Suite KR: Key Refresh CS: Cipher Suite CM: Compression Method CC: Client Certificate SEC-Exchange.cnf (CC) SEC-Commit.ind

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

Receiver SEC-SAP

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

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

Unreliable, however, secured datagram transfer!

SEC-Commit.cnf © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 29

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 30

5

WTP — Wireless Transaction Protocol ‰

Goals:

Details of WTP (1) ‰

– Different transaction services, offloads applications:

– Class 0: unreliable message transfer:

• Application can select reliability, efficiency – Support of different communication scenarios:

• Example: push service – Class 1: reliable request:

• Class 0: unreliable message transfer • Class 1: reliable message transfer without result message • Class 2: reliable message transfer with exactly one reliable result message – Supports peer-to-peer, client/server, and multicast applications – Low memory requirements, suitable for simple devices (< 10 kbyte ) – Efficient for wireless transmission: • Segmentation/reassembly • Selective retransmission • Header compression • Optimized connection setup (setup with data transfer)

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Support of different communication scenarios:

• An invoke message is not followed by a result message • Example: reliable push service – Class 2: reliable request/response: • An invoke message is followed by exactly one result message • With and without ACK • Example: typical web browsing ‰

No explicit connection setup or release is available

‰

Services for higher layers are called “events”

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 31

Details of WTP (2) ‰

M10 – 32

WTP Class 0 Transaction

Used Mechanisms: – Reliability: • • • •

Unique transaction identifiers (TID) Acknowledgements Selective retransmission Duplicate removal

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

– Optional: concatenation & separation of messages – Optional: segmentation & reassembly of messages

Responder TR-SAP

Invoke PDU

– Asynchronous transactions – Transaction abort, error handling – Optimized connection setup (includes data transmission)

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

A: Acknowledgement Request Flag C: Class Type (here 0) H: Transaction Identification (local validity only)

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 33

WTP Class 1 Transaction — No User Ack and User Ack — Initiator TR-SAP TR-Invoke.req (SA, SP, DA, DP, A, UD, C=1, H) TR-Invoke.cnf (H)

Ack PD

TR-Invoke.cnf (H) © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Initiator TR-SAP TR-Invoke.req (SA, SP, DA, DP, A, UD, C=2, H)

U

Initiator TR-SAP TR-Invoke.req (SA, SP, DA, DP, A, UD, C=1, H)

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

Responder TR-SAP

M10 – 34

WTP Class 2 Transaction — No User Ack, No Hold-on —

Responder TR-SAP

Invoke PDU

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

TR-Invoke.cnf (H)

Responder TR-SAP

Invoke PDU

Result

PDU

Ack PD

U

TR-Invoke.ind (SA, SP, DA, DP, A, UD, C=2, H‘) TR-Result.req (UD*, H‘)

TR-Result.ind (UD*, H) Invoke PDU

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

TR-Result.res (H)

TR-Invoke.res (H‘) Ack PD

TR-Result.cnf (H‘)

U

M10 – 35

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 36

6

WTP Class 2 Transaction — Hold-on, No User Ack —

WTP Class 2 Transaction — User Ack Initiator TR-SAP TR-Invoke.req (SA, SP, DA, DP, A, UD, C=2, H)

Responder TR-SAP

Initiator TR-SAP

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

Invoke PDU

TR-Invoke.res (H‘)

TR-Invoke.cnf (H)

U Ack PD

TR-Result.ind (UD*, H)

PDU Result

TR-Result.res (H)

Ack PD

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

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

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

Ack PD

TR-Result.ind (UD*, H)

PDU Result

TR-Result.res (H)

Ack PD

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 37

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

U

TR-Invoke.cnf (H)

WSP — Wireless Session Protocol ‰

Invoke PD

TR-Result.cnf (H‘)

U

Responder TR-SAP

U

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

Hold-on time

TR-Result.cnf (H‘)

U

M10 – 38

WSP Protocols

Goals: – HTTP 1.1 functionality:

WSP

• Request/reply, content type, parameter negotiation • Difference: Stateless HTTP and state-oriented in WSP – Bypass: Cookies for storing session-relevant data on clients, with clientspecific profiles, return to point of last activity, or location-independent

– – – – – ‰

Support of client/server, transactions, push technology Key management, authentication, Internet security services Session management (interruption, resume,...) Capability negotiation (use of protocol versions or max. SDU size) Content coding: binary, types, compound objects

• Session Management (class 0, 2)

• Method Invocation

• Method Invocation (class 2)

• Push

• Session suspend/resume (class 0, 2)

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 39

WSP/B Session Establishment WSP/B: Wireless Session Protocol/Browsing with Specialization on Web Usage Client S-SAP

S-Connect.cnf (SH, NC)

WTP: Class 0: unreliable message transfer Class 1: reliable request Class 2: reliable request/response

• Confirmed Push (class 1)

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

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

(in general unreliable)

• Push (class 0)

QoS support Group communication Isochronous media objects Management

Server S-SAP

Conne ct PDU

ep ly ConnR

PDU

WTP Class 2 Transaction

S-SAP -> TR-SAP and vice versa © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Connectionless mode (uses WDP or WTLS)

• Error Report

Open topics: – – – –

Connection-oriented mode (uses WTP)

M10 – 41

WSP/B Session Suspend/Resume Suspend all activities for some time (disconnection):

S-Suspend.req

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

CA: Client Address SA: Server Address CH: Client Header RC: Requested Capabilities SH: Server Header NC: Negotiated Capabilities

M10 – 40

S-Suspend.ind (R)

S-Resume.req (SA, CA)

S-Resume.cnf

Client S-SAP

Server S-SAP

Susp e nd

PDU

~R

~ esum e

Rep ly

PDU

PDU

WTP Class 2 Transaction © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

S-Suspend.ind (R)

WTP Class 0 Transaction

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

R: Reason

M10 – 42

7

WSP/B Session Termination

WSP/B Method Invoke (Full Transaction) Client S-SAP

Client S-SAP S-Disconnect.req (R)

Discon nect P DU

S-Disconnect.ind (R)

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

Server S-SAP

Meth od PDU

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

Use of WTP ACK (Class 2) PDU Rep ly

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

WTP Class 0 Transaction

S-MethodResult.res (CTID)

WSP/B over WTP — Method Invocation Client S-SAP

Initiator TR-SAP

WTP Class 2 Transaction

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 43

Responder TR-SAP

Server S-SAP

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

S-MethodResult.cnf (STID)

R: Reasons on, e.g., network errors, protocol errors, user requirements, congestion

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

RU: Request URI M: Method RH: Response Header RB: Response Body

S-MethodInvoke.res (STID)

S-MethodInvoke.cnf (CTID)

S-Disconnect.ind (R)

Server S-SAP

STID: Server Transaction ID CTID: Client Transaction ID S: Status

M10 – 44

WSP/B over WTP — Asynchronous, Unordered Requests —

Non-transparent use of WTP by WSP! Pull approach

Client S-SAP

Server S-SAP

.res and .cnf omitted Pull approach

S-MethodInvoke_1.req S-MethodInvoke_2.req

S-MethodInvoke.req

S-MethodInvoke.cnf S-MethodResult.ind

TR-Invoke.req Invo ke(Met h od ) TR-Invoke.ind

S-MethodInvoke.ind

TR-Invoke.res

S-MethodInvoke.res

TR-Invoke.cnf TR-Result.ind

Ack PD

U

Rep Result(

TR-Result.req

ly)

S-MethodInvoke_2.ind

S-MethodResult.req

S-MethodInvoke_1.ind S-MethodInvoke_3.req

S-MethodResult_1.req S-MethodInvoke_3.ind

S-MethodResult_1.ind

S-MethodResult_3.req S-MethodResult_2.req

S-MethodResult_3.ind S-MethodInvoke_4.req

S-MethodResult.res

TR-Result.res

Ack PD

U

TR-Result.cnf

S-MethodResult.cnf

S-MethodInvoke_4.ind S-MethodResult_4.req

S-MethodResult_4.ind S-MethodResult_2.ind

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 45

WSP/B — Confirmed/Non-confirmed Push Client S-SAP

S-Push.ind (PH, PB)

Server S-SAP

DU Push P

Client S-SAP

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

Server S-SAP

DU ush P ConfP

S-ConfirmedPush.res (CPID)

WSP/B over WDP Application (sensor data) with no requirements on sessions, ACKs, storage of state, and reliability. WTLS may be included.

S-Push.req (PH, PB)

WTP Class 0 Transaction

PH: Push Header PB: Push Body CPID: Client Push ID SIPD: Server Push ID

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

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

S-Unit-MethodResult.ind (CA, SA, TID, S, RH, RB) S-Unit-Push.ind (CA, SA, PID, PH, PB)

S-ConfirmedPush.cnf (SPID)

M10 – 47

Cient S-SAP

Server S-SAP

Meth od PDU

PD Rep ly

U

DU Push P

RU: Request URI M: Method TID: Transaction ID S: Status PID: Push ID

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)

WDP Unitdata Service

WTP Class 1 Transaction © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 46

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 48

8

WAE — Wireless Application Environment ‰

WAE Logical Model

Goals:

Cf. M8-24: Minimizing bandwidth on air interface and resource consumption on mobile device.

– Network-independent application environment for low-bandwidth, wireless devices – Integrated Internet/WWW programming model with high interoperability ‰

Origin Servers

Other Content Server

Components: – – – –

Architecture: application model, browser, gateway, server WML: XML-Syntax, based on card stacks, variables, ... WMLScript: procedural, loops, conditions, ... (similar to JavaScript) WTA: telephone services, such as call control, text messages, phone book, ... (accessible from WML/WMLScript) – Content formats: vCard, vCalendar, Wireless Bitmap, WML, ... © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 49

Client

Encoders & Decoders

encoded push content

request

encoded request

Other WAE User Agents

M10 – 50



Reference to XML (WML derived from)



Keyword



Features:

First card: present text Upon “accept” on do

‰

WML User Agent

WML — Example (1)

WML follows deck and card metaphor: – – – –

WTA User Agent

encoded response with content

push content

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Wireless Markup Language (WML) ‰

response with content

Web Server

– Device and network-independent, international support – Manufacturers can determine look-and-feel, user interface – Considerations of slow links, limited memory, low computing power, small display, simple user interface (compared to desktop computers) ‰

Gateway

Requirements:



– Text and images:



• Text input, passwords, options, bullets, ... – Navigation:

This is a simple first card!

• Address (URL) storage, hyperlinks – Context management:

On the next one you can choose ...






• Variables for inter-card and inter-deck exchange © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 51

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

WML — Example (2) Second second card ... your favorite pizza! Selection of pizza! Variable PIZZA set Margherita Funghi Vulcano Your personal pizza parameter is $(PIZZA)! Coding of WML in binary form: E.g., 4B=‘href=“http://’ © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 53

Get second card



• Page description, presentation client-dependent – User interaction:

M10 – 52

WMLScript ‰

WMLScript: – – – – –

‰

Complement to WML Provides general scripting capabilities Based on JavaScript Small byte code interpreter (WMLScript Compiler, e.g., located on Gateway) Efficient data exchange on air interface

Features: – Validity check of user input: • Check input before sent to server – Access to device facilities: • Hardware and software (phone call or address book) – Local user interaction: • Interaction without round-trip delay – Extensions to the device software: • Configure device, download new functionality after deployment

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 54

9

WMLScript — Example

Wireless Telephony Application (WTA) ‰

function pizza_test(pizza_type) {

‰

var taste = "unknown";

Collection of telephony specific extensions Extension of basic WAE application model: – Content push:

if (pizza_type = "Margherita") {

• Server can push content to the client • Client may now be able to handle unknown events – Handling of network events:

taste = "well... "; } else {

• Table indicating how to react on certain events from the network – Access to telephony functions:

if (pizza_type = "Vulcano") { taste = "quite hot";

• Any application on the client may access telephony functions

}; ‰

};

Example: – Calling a number (WML): wtai://wp/mc;07216086415 – Calling a number (WMLScript): WTAPublic.makeCall("07216086415");

return taste; };

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 55

WTA Logical Architecture

M10 – 56

Voice Box Example

Other Telephone Networks

WTA User Agent

WTA Server

WTA Gateway

Client WML Scripts

WML Decks

WTA User Agent

Display deck; user selects Ask for all details

WSP Get

HTTP Get WML

Binary WML

WAP Gateway

WTA Services Network Operator Trusted Domain

Encoders & Decoders Other Servers

Repository

Display deck; user selects Select one call

Devicespecific Functions

WSP Get

WML

Respond with card for call Play requested voice message

Wait for call

Call setup Setup call

Accept call

Firewall

M10 – 57

WTAI — Example with WML only Please choose your candidate! Your selection: Mickey Donald Pluto © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

HTTP Get

Binary WML

Accept call

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

Respond with content

Setup call

Third Party Servers

M10 – 59

Voice Box Server

Push URL

Message exists Service Indication

Mobile Network

WTA & WML Server

WTA Server Mobile Network Indicate new voice message Generate new deck

Accept call Voice connection

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 58

WTAI — Example with WML and WMLScript (1) function voteCall(Nr) { var j = WTACallControl.setup(Nr,1); if (j>=0) { WMLBrowser.setVar("Message", "Called"); WMLBrowser.setVar("No", Nr); } else { WMLBrowser.setVar("Message", "Error!"); WMLBrowser.setVar("No", j); } WMLBrowser.go("showResult"); }

© 2005 Burkhard Stiller and Jochen Schiller FU Berlin

M10 – 60

10

WTAI — Example with WML and WMLScript (2) Please choose your candidate! Your selection: Mickey Donald Pluto Status: $Message $No © 2005 Burkhard Stiller and Jochen Schiller FU Berlin

WAP Push Architecture with Proxy Gateway ‰

Push Access Protocol: – Content transmission between server and PPG (Push Proxy Gateway) – First version uses HTTP

‰

Push OTA (Over The Air) Protocol: – Simple, optimized – Mapped onto WSP

User Agents

‰

Push Initiator Server Application

M10 – 62

Push/Pull Services in WAP (2)

Mobile device “fully” loaded due to recent action Push initiator may simply perform a “Service Indication”:

‰ ‰

– Service announcement using a pushed short message – Service usage via a pull – Service identification via an URI






Keyword



Service offer

created="2002-10-30T17:45:32Z"

Service expiration

si-expires="2000-10-30T17:50:31Z">

Reference to XML (WML derived from)