mobile communications chapter 10: support for mobility file systems data bases www and mobility ...

Mobile Communications Chapter 10: Support for Mobility

File systems Data bases WWW and Mobility WAP (Wireless Application Protocol), i-mode & Co.

File systems - Motivation

Goal efficient and transparent access to shared files within a mobile environment

while maintaining data consistency

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)

File systems - consistency problems

THE big problem of distributed, loosely coupled systems are all views on data the same? how and when should changes be propagated to what users?

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

Conflict detection content independent: version numbering, time-stamps content dependent: dependency graphs

File systems for limited connectivity I

Symmetry 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 optimistic or pessimistic

Caching and Pre-fetching single files, directories, subtrees, partitions, ... permanent or only at certain points in time

File systems for limited connectivity II

Data management management of buffered data and copies of data request for updates, validity of data detection of changes in data

Conflict solving application specific or general errors

Several experimental systems exist Coda (Carnegie Mellon University), Little Work (University of Michigan),

Ficus (UCLA) etc.

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

mobile client

File systems - Coda I

Coda is the successor of AFS and offers two different types of replication: Server replication and caching on clients.

Coda is transparent extension of client’s cache manager. Applications use cached replicates of files. Coda offers extensive mechanisms for pre-fetching of files while still

connected, called “Hoarding“. While the client is disconnected, applications work on the replicates, called

emulating.

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 working on whole files.

cacheapplication server

File systems - Coda II

Hoarding user can pre-determine a file list with

priorities contents of the cache determined by

the list and LRU strategy (Last Recently Used)

explicit pre-fetching possible periodic updating

Comparison of files asynchronous, background system weighs speed of updating

against minimization of network traffic

Cache misses modeling of user patience: how long

can a user wait for data without an error message?

function of file size and bandwidth

hoarding

writedisconnected

emulating

disconnection

disconnection

connection

strongconnection

weakconnection

States of a client

File systems - Little Work

Only changes in the cache manager of the client More client states to maintain consistency:

Connected PartiallyConnected

Fetch only Disconnected

Method normal delayed writeto the server

optimisticreplication of files

abort at cachemiss

Networkrequirements

continuoushighbandwidth

continuousbandwidth

connection ondemand

none

Application office, WLAN packet radio cellular systems(e.g., GSM) withcosts per call

independent

File systems - further examples

Ficus not a client/server approach optimistic use of replicates, detection of write conflicts, conflict resolution

on directories use of „gossip“ protocols: a mobile computer does not necessarily need

to have direct connection to a server, with the help of other mobile computers updates can be propagated through the network

MIo-NFS (Mobile Integration of NFS) NFS extension, pessimistic approach, only token holder can write Three different modes:

Connected: The server handles all access to files. loosely connected: Clients use local replicates, exchange tokens, and

update files via the network. Disconnected: The client uses only local replicates. Writing is only

allowed if the client is token-holder.

File systems - further examples

Rover Relocatable dynamic objects are objects that can be dynamically

loaded into a client computer from a server to reduce client-server communication.

Queued remote procedure calls allow for non-blocking RPCs when a host is disconnected.

Requests and responses are exchanged as soon as a connection is available.

Conflict resolution is done in the server and is application specific.

Mobiware A mobile middleware environment using CORBA and Java.

Mazer/Tardo 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

Database systems in mobile environments

Request processing power conserving, location dependent, cost efficient example: find the fastest way to a hospital

Replication management similar to file systems

Location management 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 for “weak” transaction

World Wide Web and mobility

Protocol (HTTP, Hypertext Transfer Protocol) and language (HTML, 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 avg. <10 kbyte, header 160 byte, GIF 4.1kByte, 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!

WWW example

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 and mobility I

Characteristics 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

Problems designed for large bandwidth (compared to wireless access) and

low delay big and redundant protocol headers (readable for humans,

stateless, therefore big 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

HTTP 1.0 and mobility II

Caching quite often disabled by information providers to be able to create user

profiles, usage statistics etc. dynamic objects cannot be cached

numerous counters, time, date, personalization, ... mobility quite often inhibits caches security problems

how to use SSL/TLS together with proxies? today: many user customized pages, dynamically generated on request via

CGI, ASP, ...

POSTing (i.e., sending to a server) can typically not be buffered, very problematic if currently disconnected

Many unsolved problems!

HTML and mobile devices

HTML designed for computers with “high” performance, color high-

resolution display, mouse, hard disk typically, web pages optimized for design, not for communication

Mobile devices often only small, low-resolution displays, very limited input

interfaces (small touch-pads, soft-keyboards)

Additional “features” 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

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

Approaches toward WWW for mobile devices

Application gateways, enhanced servers simple clients, pre-calculations in the fixed network compression, filtering, content extraction automatic adaptation to network characteristics

Examples 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

Problems proprietary approaches, require special enhancements for browsers heterogeneous devices make approaches more complicated

Some new issues that might help mobility?

Push technology real pushing, not a client pull needed, channels etc.

HTTP/1.1 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 always achievable: disconnected,

performance, availability -> most up-to-date version... several more tags and options for controlling caching

(public/private, max-age, no-cache etc.) relaxing of transparency on app. request or with warning to user encoding/compression mechanism, integrity check, security of

proxies, authentication, authorization... Cookies: well..., stateful sessions, not really integrated...

mobile client

browser

integratedenhancement

System support for WWW in a mobile world I

Enhanced browsers Pre-fetching, caching, off-line use e.g. Internet Explorer, Netscape

Additional, accompanying application Pre-fetching, caching, off-line use e.g. original WebWhacker Problem – not transparent, two different

ways of accessing content: Directly to the web server Via the additional application

webserver

mobile client

browseradditionalapplication

webserver

System support for WWW in a mobile world II

Client Proxy acts as server for the browser and as client for the web server. Pre-fetching, caching, off-line use e.g., Caubweb, TeleWeb, Weblicator,

WebWhacker, WebEx, WebMirror

Network Proxy supports a mobile client on the network side. adaptive content transformation

for bad connections, pre-fetching, caching

e.g., TranSend, Digestor

mobile client

browser

networkproxy

webserver

mobile client

browserclientproxy

webserver

System support for WWW in a mobile world III

Client and network proxy combination of benefits plus

simplified protocols e.g., MobiScape, WebExpress

Special network subsystem adaptive content transformation

for bad connections, pre-fetching, caching

e.g., Mowgli

Additional many proprietary serverextensions possible “channels”, content negotiation, ...

mobile client

browser

webserver

mobile client

browserclientproxy

webserver

networkproxy

clientproxy

networkproxy

WAP - Wireless Application Protocol

WAP (Wireless Application Protocol) a specification for a set of communication protocols to standardize the way

that wireless devices, such as cellular telephones and radio transceivers, can be used for Internet access, including e-mail, the World Wide Web, newsgroups, and Internet Relay Chat (IRC).

Goals deliver Internet content and enhanced services to mobile devices and users

(mobile phones, 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 developmentsPlatforms

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

Forum was: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired

Planet, further information www.wapforum.org now: Open Mobile Alliance www.openmobilealliance.org

(Open Mobile Architecture + WAP Forum + SyncML + …)

http://www.wapforum.org/

http://www.openmobilealliance.org/

http://www.openmobilealliance.org/

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

Content formats e.g., business cards (vCard), calendar events (vCalender)

Protocol layers transport layer, security layer, session layer etc.

WAP 1.x - reference model and protocols

Bearers (GSM, CDPD, ...)

Security Layer (WTLS)

Session Layer (WSP)

Application Layer (WAE)

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

SSL/TLS

HTML, Java

HTTP

Internet WAP

WAE comprises WML (Wireless Markup Language), WML Script, WTAI etc.

Transaction Layer (WTP)

additional services and applications

WCMP

A-SAP

S-SAP

TR-SAP

SEC-SAP

T-SAP

WAPThe Wireless Application Environment (WAE) - Application layer

a general-purpose application environment based on a combination of World Wide Web (WWW) and mobile telephony technologies. WAE includes a micro-browser environment containing the following functionalities:

Wireless Markup Language (WML) A lightweight markup language, similar to HTML, but optimized for use in hand-held mobile terminals;

WMLScript A lightweight scripting language, similar to JavaScript

Wireless Telephony Application (WTA) Telephony services and programming interfaces.

Wireless Session Protocol (WSP) - Session layer gives the functionality of HTTP but in a more optimized way.

Wireless Transaction Protocol (WTP) – Session layer runs on top of a datagram service and provides as a light-weight

transaction-oriented protocol. Wireless Transport Layer Security (WTLS) – Transport layer

a security protocol analogous to the industry-standard Transport Layer Security (TLS) protocol, formerly known as Secure Sockets Layer (SSL) in WWW model.

Wireless Datagram Protocol (WDP) – Transport layer The Transport layer protocol in the WAP architecture is referred to as the

Wireless Datagram Protocol (WDP).

WAP - network elements

wireless networkfixed network

WAPproxy

WTAserver

filter/WAPproxyweb

server

filter

PSTN

Internet

Binary WML: binary file format for clients

Binary WML

Binary WML

Binary WML

HTML

HTML

HTML WML

WMLHTML

WDP - Wireless Datagram Protocol

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, CSD, USSD, GPRS, ...], IS-136, TETRA, DECT, PHS, IS-95, ...)

Goals of WDP create a worldwide 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

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

WDP - Service Primitives

T-SAP T-SAP

T-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)

Usage of 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 PSTNCircuitPSTN

CircuitSubnetworkSubnetwork

InterworkingFunction

Internet Service ProviderRemote Access Service

PSTNCircuitPSTN

Circuit

WTLS - Wireless Transport Layer Security

Goals data integrity

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

protection against repetition of data and unverified data

WTLS is based on the TLS (Transport Layer Security) protocol (former SSL,

Secure Sockets Layer) optimized for low-bandwidth communication channels

Secure session, full handshake

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 - transferring datagrams

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

(SA, SP, DA, DP, UD)

senderSEC-SAP

receiverSEC-SAP

WTP - Wireless Transaction Protocol

Goals different transaction services, offloads applications

application can select reliability, efficiency support of different communication scenarios

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, suited to simple devices (< 10kbyte ) efficient for wireless transmission

segmentation/reassembly selective retransmission header compression optimized connection setup (setup with data transfer)

Details of WTP I

Support of different communication scenarios

Class 0: unreliable message transfer Example: push service

Class 1: reliable request 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

Details of WTP II

Used Mechanisms Reliability

Unique transaction identifiers (TID) Acknowledgements Selective retransmission Duplicate removal

Optional: concatenation & separation of messages Optional: segmentation & reassembly of messages Asynchronous transactions Transaction abort, error handling Optimized connection setup (includes data transmission)

WTP Class 0 transaction

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

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

initiatorTR-SAP

responderTR-SAP

WTP Class 1 transaction, no user ack & user ack



initiatorTR-SAP

responderTR-SAP

Ack PDU



initiatorTR-SAP

responderTR-SAP

Ack PDU

TR-Invoke.res(H‘)

TR-Invoke.cnf(H)

TR-Invoke.cnf(H)

WTP Class 2 transaction, no user ack, no 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 Class 2 transaction, user 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 Class 2 transaction, hold on, no user 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

Goals HTTP 1.1 functionality

Request/reply, content type negotiation, ... support of client/server, transactions, push technology key management, authentication, Internet security services session management (interruption, resume,...)

Open topics QoS support) Group communication Isochronous media objects management

WSP protocols

WSP

Connection mode(uses WTP)

Connectionless mode(uses WDP or WTLS)

• Session Management (class 0, 2)

• Method Invocation (Kl. 2)

• Error Report

• Push (class 0)

• Confirmed Push (class 1)

• Session suspend/resume (class 0, 2)

• Method Invocation

• Push

(in general unreliable)

WSP/B session establishment

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 session suspend/resume

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 session termination

Disconnect PDUS-Disconnect.ind(R)

clientS-SAP

serverS-SAP

S-Disconnect.ind(R) WTP Class 0

transaction

S-Disconnect.req(R)

WSP/B method invoke

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 over WTP - method invocation

S-MethodInvoke.req

S-MethodInvoke.ind

clientS-SAP

serverS-SAP

S-MethodInvoke.res

S-MethodInvoke.cnfS-MethodResult.req

S-MethodResult.ind

S-MethodResult.res

S-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 over WTP - asynchronous, unordered requests

S-MethodInvoke_1.req

S-MethodInvoke_1.ind

clientS-SAP

serverS-SAP



S-MethodResult_1.ind







S-MethodResult_1.req





WSP/B - confirmend/non-confirmed push

S-Push.req(PH, PB)

clientS-SAP

serverS-SAP

ConfPush PDU


S-Push.ind(PH, PB)

S-ConfirmedPush.res(CPID)

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


Push PDU

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

clientS-SAP

serverS-SAP

S-ConfirmedPush.cnf(SPID)

WSP/B over 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

Goals network independent application environment for low-bandwidth,

wireless devices integrated Internet/WWW programming model with high interoperability

Requirements 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)

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

Origin Servers

WAE logical model

webserver

other contentserver

Gateway Client

otherWAE

user agents

WMLuser agent

WTAuser agent

encoders&

decoders

encodedrequest

request

encodedresponsewithcontent

responsewithcontent

pushcontent

encodedpushcontent

Wireless Markup Language (WML)

WML (Wireless Markup Language) is a language that allows the text portions of Web pages to be presented on cellular telephones and personal digital assistants (PDAs) via wireless access.

WML follows deck and card metaphor WML document consists of many cards, cards are grouped to decks a deck is similar to an HTML page, unit of content transmission WML describes only intent of interaction in an abstract manner presentation depends on device capabilities

Features text and images user interaction navigation context management

WML – example 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="card_one" title="simple example">

<do type="accept">

<go href="#card_two"/>

</do>

<p>

This is a simple first card!

<br/>

On the next one you can choose ...

</p>

</card>

WML – example II

<card id="card_two" title="Pizza selection"> <do type="accept" label="cont"> <go href="#card_three"/> </do> <p> ... your favorite pizza! <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="card_three" title="Your Pizza!"> <p> Your personal pizza parameter is <b>$(PIZZA)</b>! </p> </card></wml>

WMLScript

WMLScript is the scripting language used in WML pages .

Complement to WML

Provides general scripting capabilities

Features validity check of user input

check input before sent to server access to device facilities

hardware and software (phone call, address book etc.) local user interaction

interaction without round-trip delay extensions to the device software

configure device, download new functionality after deployment

WMLScript - example

function pizza_test(pizza_type) {

var taste = "unknown";

if (pizza_type = "Margherita") {

taste = "well... ";

}

else {

if (pizza_type = "Vulcano") {

taste = "quite hot";

};

};

return taste;

};

Wireless Telephony Application (WTA)

The Wireless Telephony API is an API and framework for accessing telephony and network services.

Collection of telephony specific extensions

Extension of basic WAE application model content push

server can push content to the client client may now be able to handle unknown events

handling of network events table indicating how to react on certain events from the network

access to telephony functions 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");

WTA logical architecture

otherservers

client

repository

WTAuser agent

WAP gateway

encoders&

decoders

other telephone networks

WTA server

WTA & WMLserver

WMLscripts

WMLdecks

WTAservices

mobilenetwork

firewallthird party

servers

network operatortrusted domain

devicespecific

functions

Voice box example

Service Indication

WTA-User-Agent WTA-Server Mobile network Voice box server

Generate new deck

Display deck;user selects

Call setup

Accept call

Voice connection

Indicate new voice message

Play requested voice message

Setup call

Accept call Accept call

WTA-Gateway

Push URL

Display deck;user selects

WSP Get HTTP Get

Respond with contentWMLBinary WML

WSP Get HTTP Get

Respond with cardfor callWMLBinary WML

Wait for call

Setup call

WTAI - example with WML only

<?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="card_one" title="Tele voting"> <do type="accept"> <go href="#card_two"/> </do> <p> Please choose your candidate! </p> </card> <card id="card_two" title="Your selection"> <do type="accept"> <go href="wtai://wp/mc;$dialno"/> </do> <p> Your selection: <select name="dialno"> <option value="01376685">Mickey</option> <option value="01376686">Donald</option> <option value="01376687">Pluto</option> </select> </p> </card></wml>

WTAI - example with WML and WMLScript I

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");

}

WTAI - example with WML and 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="card_one" title="Tele voting"> <do type="accept"> <go href="#card_two"/> </do> <p> Please choose your candidate! </p> </card> <card id="card_two" title="Your selection"> <do type="accept"> <go href="/myscripts#voteCall($dialno)"/> </do> <p> Your selection: <select name="dialno"> <option value="01376685">Mickey</option> <option value="01376686">Donald</option> <option value="01376687">Pluto</option> </select> </p> </card> <card id="showResult" title="Result"> <p> Status: $Message $No </p> </card></wml>

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

Client

User Agents

Push Proxy Gateway

Coding,checking

Push OTAProtocol

Push Initiator

PushAccessProtocol

Serverapplication

Push/Pull services in WAP I

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


<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"

"http://www.wapforum.org/DTD/si.dtd">

<si>

<indication href="http://www.piiiizza4u.de/offer/salad.wml"

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

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

Salad special: The 5 minute offer

</indication>

</si>

Push/Pull services in WAP II

Service Loading short message pushed to a client containing a URI User agent decides whether to use the URI via a pull Transparent for users, always looks like a push


<!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN"

"http://www.wapforum.org/DTD/sl.dtd">

<sl

href="http://www.piiiizza4u.de/offer/salad.wml">

</sl>

Examples for WAP protocol stacks (WAP 1.x)

WAE

WSP

WTP

UDP

IP (GPRS, ...)

WDP

non IP(SMS, ...)

WTLS

WAE user agentWAP standardization

outside WAP

WTP

UDP

IP (GPRS, ...)

WDP

non IP(SMS, ...)

WTLS

UDP

IP (GPRS, ...)

WDP

non IP(SMS, ...)

WTLS

transaction basedapplication

datagram basedapplication

typical WAP application with

complete protocol stack

pure data application with/without

additional security

1. 2. 3.

i-mode – first of all a business model!

i-mode is a proprietary packet-based information service for mobile phones by NTT DoCoMo.

Access to Internet services in Japan provided by NTT DoCoMo Services

Email, short messages, web, picture exchange, horoscope, ... Big success – more than 30 million users

Many use i-mode as PC replacement For many this is the first Internet contact Very simple to use, convenient

Technology 9.6 kbit/s (enhancements with 28.8 kbit/s), packet oriented (PDC-P) Compact HTML (cHTML) plus proprietary tags, special transport layer (Stop/go, ARQ,

push, connection oriented)

PDC-P

TLHTTP(S)

cHTML + tags

mobile terminal

PDC-P

TL

mobile network gateway content provider

L1L2IP

TCP

L1L2IP

TCP

L1L2IP

TCP

L1L2IP

TCPHTTP(S)

cHTML + tags

Email example: i-mode push with SMS

application

WSP

WTP

WDP

SMS

Operator sends an SMS containing a push message if a new email has arrived. If the user wants to read the email, an HTTP get follows with the email as response.

Popular misconception:WAP was a failure, i-mode is different and a success – wrong from a technology point of view, right from a business point of view…

i-mode as a business model:- content providers get >80% of the revenue.- independent of technology (GSM/GPRS in Europe, PDC-P in Japan – but also UMTS!)

i-mode protocol stack based on WAP 2.0

user equipment gateway

i-mode can use WAP 2.0/Internet protocols (example: i-mode in Germany over GSM/GPRS)

server

cHTML

HTTP

WTCP

IP

L2

L1

SSL

WTCP

IP

L2

L1

TCP

IP

L2

L1

cHTML

HTTPSSL

TCP

IP

L2

L1

i-mode – technical requirements

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 examples I

i-mode examples II

i-mode examples III

WAP 2.0 (July 2001)

WAP 2.0 supports: XHTML with a mobile profile (XHTMLMP) TCP with „Wireless Profile“ HTTP

WAP 2.0 framework consists of: Bearer networks: GPRS Transport services: TCP, WDP or UDP Transfer services: HTTP, Multi-media messaging Service (MMS) Session services: push OTA (Over The Air)

New applications Color graphics Animation Large file download Location based services Synchronization with PIMs Pop-up/context sensitive menus

Goal: integration of WWW, Internet, WAP, i-mode

WAP 2.0 architecture

Servicediscovery

Securityservices

App

lica

tion

fram

ewo

rkP

roto

col f

ram

ewo

rk

External services EFI

Provisioning

NavigationDiscovery

ServiceLookup

Cryptolibraries

Authenti-cation

Identification

PKI

Securetransport

Securebearer

Se

ssio

nT

ran

sfe

rT

ran

spo

rtB

ea

rer

Multimedia Messaging (Email)

WAE/WTA User Agent (WML, XHTMLMP)

Content formats

Push

IPv4

IPv6

CSD

SMS

USSD

FLEX

GPRS

MPAK

...

...

Datagrams(WDP, UDP)

Connections(TCP with

wireless profile)

Hypermedia transfer (WTP+WSP, HTTP)

Strea-ming

MMS

PushOTA

Capability Negotiation

Synchronisation Cookies

WAP 2.0 example protocol stacks

bearerWDPWTLSWTPWSPWAE

WAP device

bearerWDPWTLSWTPWSP

IPTCPTLS

HTTP

IPTCPTLS

HTTP

WAE

Web serverWAP gateway

WAP 1.x Server/Gateway/Client

IPTCP‘TLS

HTTPWAE

WAP device

IPTCP‘

IPTCP

IPTCPTLS

HTTPWAE

Web serverWAP proxy

WAP Proxy with TLS tunneling

IPTCP‘

HTTP‘WAE

WAP device

IPTCP‘

IPTCP

IPTCP

WAE

Web serverWAP proxy

WAP HTTP Proxy with profiled TCP and HTTP

HTTP‘ HTTP HTTP

IPTCP

HTTPWAE

WAP device

IP IP IPTCP

WAE

Web server

IP router

WAP direct access

HTTP

Java 2 Platform Micro Edition

„Java-Boom expected“ (?) Desktop: over 90% standard PC architecture, Intel x86 compatible, typically

MS Windows systems Do really many people care about platform independent applications?

BUT: Heterogeneous, “small“ devices Internet appliances, cellular phones, embedded control, car radios, ... Technical necessities (temperature range, form factor, power consumption,

…) and economic reasons result in different hardware

J2ME Provides a uniform platform Restricted functionality compared to standard java platform (JVM)

Applications of J2ME

Example cellular phones NTT DoCoMo introduced ippli Applications on PDA, mobile phone, ... Game download, multimedia applications,

encryption, system updates Load additional functionality with a push on a

button (and pay for it)!

Embedded control Household devices, vehicles, surveillance

systems, device control System update is an important factor

Characteristics and architecture

Java Virtual Machine Virtual Hardware (Processor) KVM (K Virtual Machine)

Min. 128 kByte, typ. 256 kByte Optimized for low performance devices Might be a co-processor

Configurations Subset of standard Java libraries depending technical

hardware parameters (memory, CPU) CLDC (Connected Limited Device Configuration)

Basic libraries, input/output, security – describes Java support for mobile devices

Profiles Interoperability of heterogeneous devices belonging to the

same category MIDP (Mobile Information Device Profile)

Defines interfaces for GUIs, HTTP, application support, …

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

Java Virtual Machine(JVM, KVM)

Operating system(EPOC, Palm, WinCE)

Configurations(CDC, CLDC)

Profile(MIDP)

Applications

Hardware independent development

Summary J2ME

Idea is more than WAP 1.x or i-mode Full applications on mobile phones, not only a

browser Includes system updates, end-to-end encryption

Platform independent via virtualization As long as certain common interfaces are used Not valid for hardware specific functions

Limited functionality compared to JVM Thus, maybe an intermediate solution only – until

embedded systems, mobile phones are as powerful as today’s desktop systems

mobile communications chapter 10: support for mobility file systems data bases www and mobility ...

Documents

distributed file systems

reliablestandard file

timefile systems

file list

network file system

shared files

dependency graphsfile

prefetchingsingle files