Mobile Computing Chapter 10 Support for Mobility File

Mobile Computing Chapter 10: Support for Mobility File systems q Data bases q WWW and Mobility q WAP (Wireless Application Protocol), i-mode & Co. q 10. 1

File systems - Motivation Goal q efficient and transparent access to shared files within a mobile environment while maintaining data consistency Problems q q q 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) q data collection in advance (hoarding, pre-fetching) q 10. 2

File systems - consistency problems THE big problem of distributed, loosely coupled systems are all views on data the same? q how and when should changes be propagated to what users? q Weak consistency many algorithms offering strong consistency (e. g. , via atomic updates) cannot be used in mobile environments q invalidation of data located in caches through a server is very problematic if the mobile computer is currently not connected to the network q occasional inconsistencies have to be tolerated, but conflict resolution strategies must be applied afterwards to reach consistency again q Conflict detection content independent: version numbering, time-stamps q content dependent: dependency graphs q 10. 3

File systems for limited connectivity I Symmetry Client/Server or Peer-to-Peer relations q support in the fixed network and/or mobile computers q one file system or several file systems q one namespace for files or several namespaces q Transparency hide the mobility support, applications on mobile computers should notice the mobility q user should notice additional mechanisms needed q Consistency model q optimistic or pessimistic Caching and Pre-fetching single files, directories, subtrees, partitions, . . . q permanent or only at certain points in time q 10. 4

File systems for limited connectivity II Data management of buffered data and copies of data q request for updates, validity of data q detection of changes in data q Conflict solving application specific or general q errors q Several experimental systems exist q 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) 10. 5

File systems - Coda I Application transparent extensions of client and server changes in the cache manager of a client q applications use cache replicates of files q extensive, transparent collection of data in advance for possible future use („Hoarding“) q Consistency system keeps a record of changes in files and compares files after reconnection q if different users have changed the same file a manual reintegration of the file into the system is necessary q optimistic approach, coarse grained (file size) q mobile client application cache 10. 6 server

File systems - Coda II States of a client Hoarding user can pre-determine a file list with priorities q contents of the cache determined by the list and LRU strategy (Last Recently Used) q explicit pre-fetching possible q periodic updating q Comparison of files asynchronous, background q system weighs speed of updating against minimization of network traffic q Cache misses modeling of user patience: how long can a user wait for data without an error message? q function of file size and bandwidth q 10. 7 hoarding disconnection weak connection strong connection write disconnected connection disconnection emulating

File systems - Little Work Only changes in the cache manager of the client q Connection modes and use q 10. 8

File systems - further examples Mazer/Tardo file synchronization layer between application and local file system q caching of complete subdirectories from the server q “Redirector” responses to requests locally if necessary, via the network if possible q periodic consistency checks with bi-directional updating q Ficus not a client/server approach q optimistic approach based on replicates, detection of write conflicts, conflict resolution q 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 q MIo-NFS (Mobile Integration of NFS) NFS extension, pessimistic approach, only token holder can write q connected/loosely connected/disconnected q 10. 9

Database systems in mobile environments Request processing power conserving, location dependent, cost efficient q example: find the fastest way to a hospital q Replication management q 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) q example: with the help of the HLR (Home Location Register) in GSM a mobile user can find a local towing service q Transaction processing “mobile” transactions can not necessarily rely on the same models as transactions over fixed networks (ACID: atomicity, consistency, isolation, durability) q therefore models for “weak” transaction q 10. 10

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 q responses avg. <10 kbyte, header 160 byte, GIF 4. 1 k. Byte, JPEG 12. 8 kbyte, HTML 5. 6 kbyte q but also many large files that cannot be ignored q The Web is no file system Web pages are not simple files to download q static and dynamic content, interaction with servers via forms, content transformation, push technologies etc. q many hyperlinks, automatic loading and reloading, redirecting q a single click might have big consequences! q 10. 11

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: "2 d 8190 -2322 -3 dbfdbaf" Accept-Ranges: bytes Content-Length: 8994 Connection: close Content-Type: text/html non persistent <DOCTYPE HTML PUBLIC "-//W 3 C//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. fuberlin. de/styles/homepage. css "> <!--script language="Java. Script" src="fuinf. js"--> <!--/script--> </head> <body on. Resize="self. location. reload(); ">. . . 10. 12

HTTP 1. 0 and mobility I Characteristics stateless, client/server, request/response q needs a connection oriented protocol (TCP), one connection per request (some enhancements in HTTP 1. 1) q primitive caching and security q Problems designed for large bandwidth (compared to wireless access) and low delay q big and redundant protocol headers (readable for humans, stateless, therefore big headers in ASCII) q uncompressed content transfer q using TCP q huge overhead per request (3 -way-handshake) compared with the content, e. g. , of a GET request l slow-start problematic l q DNS lookup by client causes additional traffic 10. 13

HTTP 1. 0 and mobility II Caching quite often disabled by information providers to be able to create user profiles, usage statistics etc. q dynamic objects cannot be cached q l numerous counters, time, date, personalization, . . . mobility quite often inhibits caches q security problems q l q 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) q can typically not be buffered, very problematic if currently disconnected Many unsolved problems! 10. 14

HTML and mobile devices HTML designed for computers with “high” performance, color highresolution display, mouse, hard disk q typically, web pages optimized for design, not for communication q Mobile devices q often only small, low-resolution displays, very limited input interfaces (small touch-pads, soft-keyboards) Additional “features” animated GIF, Java AWT, Frames, Active. X Controls, Shockwave, movie clips, audio, . . . q many web pages assume true color, multimedia support, highresolution and many plug-ins q Web pages ignore the heterogeneity of end-systems! q e. g. , without additional mechanisms, large high-resolution pictures would be transferred to a mobile phone with a low-resolution display causing high costs 10. 15

Approaches toward WWW for mobile devices Application gateways, enhanced servers simple clients, pre-calculations in the fixed network q compression, filtering, content extraction q automatic adaptation to network characteristics q Examples q q q 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 q heterogeneous devices make approaches more complicated q 10. 16

Some new issues that might help mobility? q Push technology q q HTTP/1. 1 q q q q real pushing, not a client pull needed, channels etc. 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. . . 10. 17

System support for WWW in a mobile world I Enhanced browsers Pre-fetching, caching, off-line use q e. g. Internet Explorer mobile client integrated enhancement q browser web server Additional, accompanying application Pre-fetching, caching, off-line use q e. g. original Web. Whacker q mobile client browser additional application web server 10. 18

System support for WWW in a mobile world II mobile client Client Proxy Pre-fetching, caching, off-line use q e. g. , Caubweb, Tele. Web, Weblicator, Web. Whacker, Web. Ex, Web. Mirror, . . . q browser client proxy web server Network Proxy adaptive content transformation for bad connections, pre-fetching, caching q e. g. , Tran. Send, Digestor q mobile client browser web server 10. 19 network proxy

System support for WWW in a mobile world III Client and network proxy mobile client combination of benefits plus simplified protocols q e. g. , Mobi. Scape, Web. Express q Special network subsystem adaptive content transformation for bad connections, pre-fetching, caching q e. g. , Mowgli q Additional many proprietary server extensions possible q “channels”, content negotiation, . . . 10. 20 browser client proxy web server network proxy mobile client browser client proxy web server network proxy

WAP - Wireless Application Protocol Goals deliver Internet content and enhanced services to mobile devices and users (mobile phones, PDAs) q independence from wireless network standards q open for everyone to participate, protocol specifications will be proposed to standardization bodies q applications should scale well beyond current transport media and device types and should also be applicable to future developments q Platforms q e. g. , GSM (900, 1800, 1900), CDMA IS-95, TDMA IS-136, 3 rd generation systems (IMT-2000, UMTS, W-CDMA, cdma 2000 1 x EV -DO, …) Forum was: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired Planet, further information www. wapforum. org q now: Open Mobile Alliance www. openmobilealliance. org (Open Mobile Architecture + WAP Forum + Sync. ML + …) q 10. 21

WAP - scope of standardization Browser q “micro browser”, similar to existing, well-known browsers in the Internet Script language q similar to Java script, adapted to the mobile environment WTA/WTAI q Wireless Telephony Application (Interface): access to all telephone functions Content formats q e. g. , business cards (v. Card), calendar events (v. Calender) Protocol layers q transport layer, security layer, session layer etc. 10. 22

WAP 1. x - reference model and protocols Internet HTML, Java A-SAP WAP Application Layer (WAE) S-SAP additional services and applications Session Layer (WSP) HTTP TR-SAP Transaction Layer (WTP) SEC-SAP SSL/TLS Security Layer (WTLS) T-SAP TCP/IP, UDP/IP, media Transport Layer (WDP) WCMP Bearers (GSM, CDPD, . . . ) WAE comprises WML (Wireless Markup Language), WML Script, WTAI etc. 10. 23

WAP - network elements fixed network Internet HTML wireless network WML filter WAP proxy Binary WML HTML web server HTML filter/ WAP proxy WTA server Binary WML PSTN Binary WML: binary file format for clients 10. 24

WDP - Wireless Datagram Protocol of the transport layer within the WAP architecture uses directly transports mechanisms of different network technologies q offers a common interface for higher layer protocols q allows for transparent communication using different transport technologies (GSM [SMS, CSD, USSD, GPRS, . . . ], IS-136, TETRA, DECT, PHS, IS-95, . . . ) q Goals of WDP create a worldwide interoperable transport system with the help of WDP adapted to the different underlying technologies q transmission services such as SMS, GPRS in GSM might change, new services can replace the old ones q Additionally, WCMP (wireless Control Message Protocol) is used for control/error report (similar to ICMP in the TCP/IP protocol suite) 10. 25

WDP - Service Primitives T-SAP T-DUnitdata. req (DA, DP, SA, SP, UD) T-SAP T-DUnitdata. ind (SA, SP, UD) T-DUnitdata. req (DA, DP, SA, SP, UD) T-DError. ind (EC) 10. 26

Usage of WDP Wireless Data Gateway WTLS WDP & Adaptation SMS GSM-SMS Tunnel WTLS WDP & Adaptation Tunnel Subnetwork SMS WAP Proxy GSM-CSD WTLS Internet Service Provider Remote Access Service UDP IP PPP CSD-RF Interworking Function CSD-RF PSTN Circuit 10. 27 IP PPP PSTN Circuit Subnetwork WTLS UDP IP Subnetwork

WTLS - Wireless Transport Layer Security Goals q data integrity l q privacy l q prevention of tapping authentication l q prevention of changes in data creation of authenticated relations between a mobile device and a server protection against denial-of-service attacks l protection against repetition of data and unverified data WTLS is based on the TLS (Transport Layer Security) protocol (former SSL, Secure Sockets Layer) q optimized for low-bandwidth communication channels q 10. 28

Secure session, full handshake originator SEC-SAP SEC-Create. req (SA, SP, DA, DP, KES, CM) peer SEC-SAP SEC-Create. ind (SA, SP, DA, DP, KES, CM) SEC-Create. res (SNM, KR, SID, KES‘, CM‘) SEC-Exchange. req SEC-Create. cnf (SNM, KR, SID, KES‘, CM‘) SEC-Exchange. ind SEC-Exchange. res (CC) SEC-Commit. req SEC-Exchange. cnf (CC) SEC-Commit. ind SEC-Commit. cnf 10. 29

SEC-Unitdata - transferring datagrams sender SEC-SAP receiver SEC-SAP SEC-Unitdata. req (SA, SP, DA, DP, UD) SEC-Unitdata. ind (SA, SP, DA, DP, UD) 10. 30

WTP - Wireless Transaction Protocol Goals q different transaction services, offloads applications l q application can select reliability, efficiency support of different communication scenarios class 0: unreliable message transfer l class 1: reliable message transfer without result message l class 2: reliable message transfer with exactly one reliable result message l supports peer-to-peer, client/server and multicast applications q low memory requirements, suited to simple devices (< 10 kbyte ) q efficient for wireless transmission q segmentation/reassembly l selective retransmission l header compression l optimized connection setup (setup with data transfer) l 10. 31

Details of WTP I Support of different communication scenarios q Class 0: unreliable message transfer l q Example: push service Class 1: reliable request An invoke message is not followed by a result message l Example: reliable push service l q Class 2: reliable request/response An invoke message is followed by exactly one result message l With and without ACK l Example: typical web browsing l No explicit connection setup or release is available Services for higher layers are called events 10. 32

Details of WTP II Used Mechanisms q Reliability Unique transaction identifiers (TID) l Acknowledgements l Selective retransmission l Duplicate removal l q q q Optional: concatenation & separation of messages Optional: segmentation & reassembly of messages Asynchronous transactions Transaction abort, error handling Optimized connection setup (includes data transmission) 10. 33

WTP Class 0 transaction initiator TR-SAP TR-Invoke. req (SA, SP, DA, DP, A, UD, C=0, H) responder TR-SAP Invoke PDU 10. 34 TR-Invoke. ind (SA, SP, DA, DP, A, UD, C=0, H‘)

WTP Class 1 transaction, no user ack & user ack initiator TR-SAP TR-Invoke. req (SA, SP, DA, DP, A, UD, C=1, H) responder TR-SAP Invoke TR-Invoke. cnf (H) U Ack PD initiator TR-SAP TR-Invoke. req (SA, SP, DA, DP, A, UD, C=1, H) TR-Invoke. cnf (H) PDU TR-Invoke. ind (SA, SP, DA, DP, A, UD, C=1, H‘) responder TR-SAP Invoke PDU U Ack PD 10. 35 TR-Invoke. ind (SA, SP, DA, DP, A, UD, C=1, H‘) TR-Invoke. res (H‘)

WTP Class 2 transaction, no user ack, no hold on initiator TR-SAP TR-Invoke. req (SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke. cnf (H) responder TR-SAP Invoke PDU U PD Result TR-Invoke. ind (SA, SP, DA, DP, A, UD, C=2, H‘) TR-Result. req (UD*, H‘) TR-Result. ind (UD*, H) TR-Result. res (H) Ack PD U 10. 36 TR-Result. cnf (H‘)

WTP Class 2 transaction, user ack initiator TR-SAP TR-Invoke. req (SA, SP, DA, DP, A, UD, C=2, H) responder TR-SAP Invoke PDU Ack PD TR-Result. ind (UD*, H) PD Result TR-Invoke. res (H‘) TR-Invoke. cnf (H) TR-Result. res (H) U U Ack PD U 10. 37 TR-Invoke. ind (SA, SP, DA, DP, A, UD, C=2, H‘) TR-Result. req (UD*, H‘) TR-Result. cnf (H‘)

WTP Class 2 transaction, hold on, no user ack initiator TR-SAP TR-Invoke. req (SA, SP, DA, DP, A, UD, C=2, H) Invoke responder TR-SAP PDU TR-Invoke. cnf (H) Ack PD TR-Result. ind (UD*, H) PD Result TR-Result. res (H) U U Ack PD U 10. 38 TR-Invoke. ind (SA, SP, DA, DP, A, UD, C=2, H‘) TR-Result. req (UD*, H‘) TR-Result. cnf (H‘)

WSP - Wireless Session Protocol Goals q HTTP 1. 1 functionality l Request/reply, content type negotiation, . . . support of client/server, transactions, push technology q key management, authentication, Internet security services q session management (interruption, resume, . . . ) q Open topics Qo. S support) q Group communication q Isochronous media objects q management q 10. 39

WSP protocols WSP Connection mode (uses WTP) Connectionless mode (uses WDP or WTLS) • Session Management (class 0, 2) • Method Invocation (Kl. 2) • Push • Error Report (in general unreliable) • Push (class 0) • Confirmed Push (class 1) • Session suspend/resume (class 0, 2) 10. 40

WSP/B session establishment client S-SAP S-Connect. req (SA, CH, RC) S-Connect. cnf (SH, NC) server S-SAP Conne ct PDU U ply PD e R n n Co WTP Class 2 transaction 10. 41 S-Connect. ind (SA, CH, RC) S-Connect. res (SH, NC)

WSP/B session suspend/resume client S-SAP S-Suspend. req Suspen d PDU S-Suspend. ind (R) S-Resume. req (SA, CA) S-Resume. cnf server S-SAP S-Suspend. ind (R) WTP Class 0 transaction ~ Resum e PDU DU Reply P WTP Class 2 transaction 10. 42 ~ S-Resume. ind (SA, CA) S-Resume. res

WSP/B session termination client S-SAP S-Disconnect. req (R) S-Disconnect. ind (R) server S-SAP Discon S-Disconnect. ind U (R) nect PD WTP Class 0 transaction 10. 43

WSP/B method invoke client S-SAP S-Method. Invoke. req (CTID, M, RU) server S-SAP Method PDU S-Method. Invoke. res (STID) S-Method. Invoke. cnf (CTID) S-Method. Result. ind (CTID, S, RH, RB) S-Method. Invoke. ind (STID, M, RU) DU Reply P S-Method. Result. res (CTID) S-Method. Result. req (STID, S, RH, RB) S-Method. Result. cnf (STID) WTP Class 2 transaction 10. 44

WSP/B over WTP - method invocation client S-SAP initiator TR-SAP responder TR-SAP server S-SAP S-Method. Invoke. req TR-Invoke. req Inv oke( Method ) TR-Invoke. ind S-Method. Invoke. ind U ck PD A S-Method. Invoke. cnf TR-Invoke. cnf S-Method. Result. ind ly) ult(Rep TR-Invoke. res S-Method. Invoke. res TR-Result. req S-Method. Result. req s TR-Result. ind Re S-Method. Result. res TR-Result. res Ack PD U 10. 45 TR-Result. cnf S-Method. Result. cnf

WSP/B over WTP - asynchronous, unordered requests client S-SAP server S-SAP S-Method. Invoke_1. req S-Method. Invoke_2. ind S-Method. Invoke_1. ind S-Method. Invoke_3. req S-Method. Result_1. req S-Method. Invoke_3. ind S-Method. Result_1. ind S-Method. Result_3. req S-Method. Result_2. req S-Method. Result_3. ind S-Method. Invoke_4. req S-Method. Invoke_4. ind S-Method. Result_4. req S-Method. Result_4. ind S-Method. Result_2. ind 10. 46

WSP/B - confirmend/non-confirmed push client S-SAP S-Push. ind (PH, PB) DU Push P server S-SAP S-Push. req (PH, PB) WTP Class 0 transaction client S-SAP S-Confirmed. Push. ind (CPID, PH, PB) server S-SAP S-Confirmed. Push. req (SPID, PH, PB) U D P ush Conf. P S-Confirmed. Push. res (CPID) S-Confirmed. Push. cnf (SPID) WTP Class 1 transaction 10. 47

WSP/B over WDP S-Unit-Method. Invoke. req (SA, CA, TID, M, RU) S-Unit-Method. Result. ind (CA, SA, TID, S, RH, RB) S-Unit-Push. ind (CA, SA, PID, PH, PB) client S-SAP server S-SAP Method PDU DU Reply P DU Push P WDP Unitdata service 10. 48 S-Unit-Method. Invoke. ind (SA, CA, TID, M, RU) S-Unit-Method. Result. req (CA, SA, TID, S, RH, RB) S-Unit-Push. req (CA, SA, PID, PH, PB)

WAE - Wireless Application Environment Goals network independent application environment for low-bandwidth, wireless devices q integrated Internet/WWW programming model with high interoperability q Requirements device and network independent, international support q manufacturers can determine look-and-feel, user interface q considerations of slow links, limited memory, low computing power, small display, simple user interface (compared to desktop computers) q Components q q q architecture: application model, browser, gateway, server WML: XML-Syntax, based on card stacks, variables, . . . WMLScript: procedural, loops, conditions, . . . (similar to Java. Script) WTA: telephone services, such as call control, text messages, phone book, . . . (accessible from WML/WMLScript) content formats: v. Card, v. Calendar, Wireless Bitmap, WML, . . . 10. 49

WAE logical model Origin Servers web server other content server Gateway response with content encoders & decoders push content Client encoded response with content encoded push content request encoded request 10. 50 WTA user agent WML user agent other WAE user agents

Wireless Markup Language (WML) WML follows deck and card metaphor WML document consists of many cards, cards are grouped to decks q a deck is similar to an HTML page, unit of content transmission q WML describes only intent of interaction in an abstract manner q presentation depends on device capabilities q Features text and images q user interaction q navigation q context management q 10. 51

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> 10. 52

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> 10. 53

WMLScript Complement to WML Provides general scripting capabilities Features q validity check of user input l q access to device facilities l q hardware and software (phone call, address book etc. ) local user interaction l q check input before sent to server interaction without round-trip delay extensions to the device software l configure device, download new functionality after deployment 10. 54

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; }; 10. 55

Wireless Telephony Application (WTA) Collection of telephony specific extensions Extension of basic WAE application model q content push server can push content to the client l client may now be able to handle unknown events l q handling of network events l q table indicating how to react on certain events from the network access to telephony functions l any application on the client may access telephony functions Example q calling a number (WML) wtai: //wp/mc; 07216086415 q calling a number (WMLScript) WTAPublic. make. Call("07216086415"); 10. 56

WTA logical architecture other telephone networks WTA server client WML scripts WTA & WML server WML decks WTA services network operator trusted domain mobile network WTA user agent WAP gateway repository encoders & decoders other servers third party servers firewall 10. 57 device specific functions

Voice box example WTA-User-Agent WTA-Gateway WTA-Server Mobile network Indicate new voice message Voice box server Generate new deck Service Indication Display deck; user selects WSP Get Binary WML Push URL HTTP Get WML Respond with content HTTP Get WML Respond with card for call Play requested voice message Wait for call Call setup Setup call Accept call Voice connection 10. 58

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> 10. 59

WTAI - example with WML and WMLScript I function vote. Call(Nr) { var j = WTACall. Control. setup(Nr, 1); if (j>=0) { WMLBrowser. set. Var("Message", "Called"); WMLBrowser. set. Var("No", Nr); } else { WMLBrowser. set. Var("Message", "Error!"); WMLBrowser. set. Var("No", j); } WMLBrowser. go("show. Result"); } 10. 60

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#vote. Call($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="show. Result" title="Result"> <p> Status: $Message $No </p> </card> </wml> 10. 61

WAP push architecture with proxy gateway Push Access Protocol Content transmission between server and PPG q First version uses HTTP q Push OTA (Over The Air) Protocol Simple, optimized q Mapped onto WSP q Client User Agents Push OTA Protocol Push Proxy Gateway Coding, checking 10. 62 Push Access Protocol Push Initiator Server application

Push/Pull services in WAP I Service Indication Service announcement using a pushed short message q Service usage via a pull q Service identification via a URI q <? 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. piiiizza 4 u. de/offer/salad. wml" created="2002 -10 -30 T 17: 45: 32 Z" si-expires="2000 -10 -30 T 17: 50: 31 Z"> Salad special: The 5 minute offer </indication> </si> 10. 63

Push/Pull services in WAP II Service Loading short message pushed to a client containing a URI q User agent decides whether to use the URI via a pull q Transparent for users, always looks like a push q <? xml version="1. 0"? > <!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1. 0//EN" "http: //www. wapforum. org/DTD/sl. dtd"> <sl href="http: //www. piiiizza 4 u. de/offer/salad. wml"> </sl> 10. 64

Examples for WAP protocol stacks (WAP 1. x) WAP standardization WAE user agent outside WAP WAE WSP transaction based application WTP WTLS datagram based application WTLS UDP WDP IP non IP (GPRS, . . . ) (SMS, . . . ) 1. (GPRS, . . . ) (SMS, . . . ) 2. typical WAP application with complete protocol stack (GPRS, . . . ) (SMS, . . . ) 3. pure data application with/without additional security 10. 65

i-mode – first of all a business model! Access to Internet services in Japan provided by NTT Do. Co. Mo q Services l Email, short messages, web, picture exchange, horoscope, . . . q Big success – more than 30 million users l Many use i-mode as PC replacement l For many this is the first Internet contact l Very simple to use, convenient q Technology l 9. 6 kbit/s (enhancements with 28. 8 kbit/s), packet oriented (PDC-P) l Compact HTML plus proprietary tags, special transport layer (Stop/go, ARQ, push, connection oriented) mobile terminal mobile network c. HTML + tags HTTP(S) TL TL PDC-P TCP IP L 2 L 1 gateway TCP IP L 2 L 1 10. 66 TCP IP L 2 L 1 content provider c. HTML + tags HTTP(S) TCP IP L 2 L 1

Email example: i-mode push with SMS 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… 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. 10. 67 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 server c. HTML HTTP c. HTML SSL HTTP WTCP TCP IP IP L 2 L 2 L 1 L 1 i-mode can use WAP 2. 0/Internet protocols (example: i-mode in Germany over GSM/GPRS) 10. 68

i-mode – technical requirements Functions Descriptions Status WEB Access Portal Site / Internet Access M i-mode HTML (c. HTML+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 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 imode session Voice termination notified and responded during i-mode communications M 3 GPP 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 email Number of characters (byte) per e-mail M To be defined by operators (e. g. 500 byte, 1 K byte, 10 K byte) 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 10. 69 Requirement

i-mode examples I 10. 70

i-mode examples II 10. 71

i-mode examples III 10. 72

WAP 2. 0 (July 2001) New for developers XHTML q TCP with „Wireless Profile“ q HTTP q New applications q q q 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 10. 73

External services EFI Crypto libraries WAE/WTA User Agent (WML, XHTMLMP) Push Provisioning Authentication Identification Service Lookup PKI Secure transport Secure bearer Push OTA Hypermedia transfer (WTP+WSP, HTTP) CSD IPv 6 USSD SMS 10. 74 Streaming MMS Connections (TCP with wireless profile) Datagrams (WDP, UDP) IPv 4 Cookies Synchronisation Transport Navigation Discovery Capability Negotiation GPRS FLEX MPAK . . . Protocol framework Content formats Session Multimedia Messaging (Email) Transfer Security services Bearer Service discovery Application framework WAP 2. 0 architecture

WAP 2. 0 example protocol stacks WAP device WAE WSP WTLS WDP bearer WAP gateway WSP WTLS WDP bearer Web server WAE HTTP TLS TCP IP WAP 1. x Server/Gateway/Client WAP device WAE HTTP TLS TCP‘ IP WAP proxy TCP‘ IP TCP IP WAP device WAE HTTP‘ TCP‘ IP WAP proxy HTTP‘ TCP‘ IP HTTP TCP IP Web server WAE HTTP TCP IP WAP HTTP Proxy with profiled TCP and HTTP Web server WAE HTTP TLS TCP IP WAP Proxy with TLS tunneling WAP device WAE HTTP TCP IP IP router IP IP WAP direct access 10. 75 Web server WAE HTTP TCP IP

Java 2 Platform Micro Edition „Java-Boom expected“ (? ) Desktop: over 90% standard PC architecture, Intel x 86 compatible, typically MS Windows systems q Do really many people care about platform independent applications? q BUT: Heterogeneous, “small“ devices Internet appliances, cellular phones, embedded control, car radios, . . . q Technical necessities (temperature range, form factor, power consumption, …) and economic reasons result in different hardware q J 2 ME Provides a uniform platform q Restricted functionality compared to standard java platform (JVM) q 10. 76

Applications of J 2 ME Example cellular phones NTT Do. Co. Mo introduced i ppli q Applications on PDA, mobile phone, . . . q Game download, multimedia applications, encryption, system updates q Load additional functionality with a push on a button (and pay for it)! q Embedded control Household devices, vehicles, surveillance systems, device control q System update is an important factor q 10. 77

Characteristics and architecture Java Virtual Machine Applications Virtual Hardware (Processor) q KVM (K Virtual Machine) q l Min. 128 k. Byte, typ. 256 k. Byte l Optimized for low performance devices l Might be a co-processor Configurations Subset of standard Java libraries depending technical hardware parameters (memory, CPU) q CLDC (Connected Limited Device Configuration) q l Basic libraries, input/output, security – describes Java support for mobile devices Profiles Interoperability of heterogeneous devices belonging to the same category q MIDP (Mobile Information Device Profile) Profile (MIDP) Configurations (CDC, CLDC) Java Virtual Machine (JVM, KVM) Operating system (EPOC, Palm, Win. CE) q l Defines interfaces for GUIs, HTTP, application support, … 10. 78 Hardware (SH 4, ARM, 68 k, . . . )

Hardware independent development 10. 79

Summary J 2 ME Idea is more than WAP 1. x or i-mode Full applications on mobile phones, not only a browser q Includes system updates, end-to-end encryption q Platform independent via virtualization As long as certain common interfaces are used q Not valid for hardware specific functions q Limited functionality compared to JVM q Thus, maybe an intermediate solution only – until embedded systems, mobile phones are as powerful as today’s desktop systems 10. 80