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

2. 10.2 Mobile, bearable multimedia equipment … CEG436: Mobile Computing 2

3. 10.3 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) CEG436: Mobile Computing 3

4. 10.4 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 CEG436: Mobile Computing 4

5. 10.5 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 CEG436: Mobile Computing 5

6. 10.6 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 early experimental systems exist (late 80s) – 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) CEG436: Mobile Computing 6

7. 10.7 File systems - Coda I 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“) 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) CEG436: Mobile Computing 7

8. 10.8 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 States of a client hoarding write disconnected emulating disconnection connection strong connection weak connection CEG436: Mobile Computing 8

9. 10.9 File systems - Little Work Only changes in the cache manager of the client Connection modes and use CEG436: Mobile Computing 9

10. 10.10 File systems - further examples 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 Ficus – not a client/server approach – optimistic approach based on replicates, detection of write conflicts, conflict resolution – 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 – connected/loosely connected/disconnected CEG436: Mobile Computing 10

11. 10.11 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 CEG436: Mobile Computing 11

12. 10.12 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! CEG436: Mobile Computing 12

13. 10.13 WWW example Request to port 80: GET / HTTP/1.0 or: 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 FU-Berlin: Institut für Informatik... non persistent CEG436: Mobile Computing 13

14. 10.14 HTTP 1.0 (old) 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 CEG436: Mobile Computing 14

15. 10.15 HTTP 1.0 (old) 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! CEG436: Mobile Computing 15

16. 10.16 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 CEG436: Mobile Computing 16

17. 10.17 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 CEG436: Mobile Computing 17

18. 10.18 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... CEG436: Mobile Computing 18

19. 10.19 System support for WWW in a mobile world I (some historical) Enhanced browsers – Pre-fetching, caching, off- line use – e.g. Internet Explorer Additional, accompanying application – Pre-fetching, caching, off- line use – e.g. original WebWhacker mobile client browser integrated enhancement web server mobile client browser additional application web server CEG436: Mobile Computing 19

20. 10.20 System support for WWW in a mobile world II (some historical) Client Proxy – Pre-fetching, caching, off-line use – e.g., Caubweb, TeleWeb, Weblicator, WebWhacker, WebEx, WebMirror,... Network Proxy – adaptive content transformation for bad connections, pre-fetching, caching – e.g., TranSend, Digestor mobile client browser network proxy web server mobile client browser client proxy web server CEG436: Mobile Computing 20

21. 10.21 System support for WWW in a mobile world III (some historical) 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 server extensions possible – “channels”, content negotiation,... mobile client browser web server mobile client browser client proxy web server network proxy client proxy network proxy CEG436: Mobile Computing 21

22. 10.22 WAP - Wireless Application Protocol 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 developments 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, …) Forum – was: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired Planet, further information www.wapforum.orgwww.wapforum.org – now: Open Mobile Alliance www.openmobilealliance.org (Open Mobile Architecture + WAP Forum + SyncML + …)www.openmobilealliance.org CEG436: Mobile Computing 22

23. 10.23 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. CEG436: Mobile Computing 23

24. 10.24 WAP 1.x - 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 InternetWAP 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 CEG436: Mobile Computing 24

25. 10.25 WAP - network elements wireless networkfixed network WAP proxy WTA server filter/ WAP proxy web server filter PSTN Internet Binary WML: binary file format for clients Binary WML HTML WML HTML CEG436: Mobile Computing 25

26. 10.26 WAP 2.0 (July 2001) New for developers – XHTML – TCP with “Wireless Profile” – HTTP 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 CEG436: Mobile Computing 26

27. 10.27 WAP 2.0 architecture Service discovery Security services Application framework Protocol framework External services EFI Provisioning Navigation Discovery Service Lookup Crypto libraries Authenti- cation Identification PKI Secure transport Secure bearer Session Transfer Transport Bearer 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 Push OTA Capability Negotiation Synchronisation Cookies CEG436: Mobile Computing 27

28. 10.28 WAP 2.0 example protocol stacks bearer WDP WTLS WTP WSP WAE WAP device bearer WDP WTLS WTP WSP IP TCP TLS HTTP IP TCP TLS HTTP WAE Web serverWAP gateway WAP 1.x Server/Gateway/Client IP TCP‘ TLS HTTP WAE WAP device IP TCP‘ IP TCP IP TCP TLS HTTP WAE Web serverWAP proxy WAP Proxy with TLS tunneling IP TCP‘ HTTP‘ WAE WAP device IP TCP‘ IP TCP IP TCP WAE Web serverWAP proxy WAP HTTP Proxy with profiled TCP and HTTP HTTP‘HTTP IP TCP HTTP WAE WAP device IP TCP WAE Web server IP router WAP direct access HTTP CEG436: Mobile Computing 28

29. 10.29 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) CEG436: Mobile Computing 29

30. 10.30 WDP - Service Primitives 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) CEG436: Mobile Computing 30

31. 10.31 Usage of WDP GSM-SMS GSM-CSD WTLS WDP & Adaptation WDP & Adaptation SMS Wireless Data Gateway WTLS WDP & Adaptation WDP & Adaptation Tunnel Subnetwork SMS Tunnel Subnetwork WAP Proxy WTLS UDP WTLS UDP IP PPP CSD-RF IP Subnetwork IP PPP CSD-RF PSTN Circuit PSTN Circuit Subnetwork Interworking Function Internet Service Provider Remote Access Service PSTN Circuit PSTN Circuit CEG436: Mobile Computing 31

32. 10.32 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 CEG436: Mobile Computing 32

33. 10.33 Secure session, full handshake SEC-Create.req (SA, SP, DA, DP, KES, CS, CM) SEC-Create.ind (SA, SP, DA, DP, KES, CS, CM) originator SEC-SAP peer SEC-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 CEG436: Mobile Computing 33

34. 10.34 SEC-Unitdata - transferring datagrams SEC-Unitdata.req (SA, SP, DA, DP, UD) SEC-Unitdata.ind (SA, SP, DA, DP, UD) sender SEC-SAP receiver SEC-SAP CEG436: Mobile Computing 34

35. 10.35 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) CEG436: Mobile Computing 35

36. 10.36 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 CEG436: Mobile Computing 36

37. 10.37 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) CEG436: Mobile Computing 37

38. 10.38 WTP Class 0 transaction TR-Invoke.req (SA, SP, DA, DP, A, UD, C=0, H) Invoke PDU TR-Invoke.ind (SA, SP, DA, DP, A, UD, C=0, H‘) initiator TR-SAP responder TR-SAP CEG436: Mobile Computing 38

39. 10.39 WTP Class 1 transaction, no user ack & user ack TR-Invoke.req (SA, SP, DA, DP, A, UD, C=1, H) Invoke PDU TR-Invoke.ind (SA, SP, DA, DP, A, UD, C=1, H‘) initiator TR-SAP responder TR-SAP Ack PDU TR-Invoke.req (SA, SP, DA, DP, A, UD, C=1, H) Invoke PDU TR-Invoke.ind (SA, SP, DA, DP, A, UD, C=1, H‘) initiator TR-SAP responder TR-SAP Ack PDU TR-Invoke.res (H‘) TR-Invoke.cnf (H) TR-Invoke.cnf (H) CEG436: Mobile Computing 39

40. 10.40 WTP Class 2 transaction, no user ack, no hold on TR-Invoke.req (SA, SP, DA, DP, A, UD, C=2, H) Invoke PDU TR-Invoke.ind (SA, SP, DA, DP, A, UD, C=2, H‘) initiator TR-SAP responder TR-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‘) CEG436: Mobile Computing 40

41. 10.41 WTP Class 2 transaction, user ack TR-Invoke.req (SA, SP, DA, DP, A, UD, C=2, H) Invoke PDU TR-Invoke.ind (SA, SP, DA, DP, A, UD, C=2, H‘) initiator TR-SAP responder TR-SAP Result PDU TR-Result.ind (UD*, H) Ack PDU TR-Invoke.res (H‘) TR-Invoke.cnf (H) Ack PDU TR-Result.req (UD*, H‘) TR-Result.res (H) TR-Result.cnf (H‘) CEG436: Mobile Computing 41

42. 10.42 WTP Class 2 transaction, hold on, no user ack TR-Invoke.req (SA, SP, DA, DP, A, UD, C=2, H) Invoke PDU TR-Invoke.ind (SA, SP, DA, DP, A, UD, C=2, H‘) initiator TR-SAP responder TR-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‘) CEG436: Mobile Computing 42

43. 10.43 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 CEG436: Mobile Computing 43

44. 10.44 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) CEG436: Mobile Computing 44

45. 10.45 WSP/B session establishment S-Connect.req (SA, CA, CH, RC) Connect PDU S-Connect.ind (SA, CA, CH, RC) client S-SAP server S-SAP ConnReply PDU S-Connect.res (SH, NC) S-Connect.cnf (SH, NC) WTP Class 2 transaction CEG436: Mobile Computing 45

46. 10.46 WSP/B session suspend/resume S-Suspend.req Suspend PDU S-Suspend.ind (R) client S-SAP server S-SAP Reply PDU S-Resume.res WTP Class 2 transaction S-Suspend.ind (R) ~~ S-Resume.req (SA, CA) S-Resume.ind (SA, CA) Resume PDU S-Resume.cnf WTP Class 0 transaction CEG436: Mobile Computing 46

47. 10.47 WSP/B session termination Disconnect PDU S-Disconnect.ind (R) client S-SAP server S-SAP S-Disconnect.ind (R) WTP Class 0 transaction S-Disconnect.req (R) CEG436: Mobile Computing 47

48. 10.48 WSP/B method invoke S-MethodInvoke.req (CTID, M, RU) Method PDU S-MethodInvoke.ind (STID, M, RU) client S-SAP server S-SAP Reply PDU S-MethodInvoke.res (STID) S-MethodInvoke.cnf (CTID) WTP Class 2 transaction S-MethodResult.req (STID, S, RH, RB) S-MethodResult.ind (CTID, S, RH, RB) S-MethodResult.res (CTID) S-MethodResult.cnf (STID) CEG436: Mobile Computing 48

49. 10.49 WSP/B over WTP - method invocation S-MethodInvoke.req S-MethodInvoke.ind client S-SAP server S-SAP S-MethodInvoke.res S-MethodInvoke.cnf S-MethodResult.req S-MethodResult.ind S-MethodResult.res S-MethodResult.cnf TR-Invoke.req initiator TR-SAP TR-Result.ind TR-Invoke.cnf TR-Result.res TR-Invoke.ind responder TR-SAP TR-Invoke.res TR-Result.req TR-Result.cnf Invoke(Method) Result(Reply) Ack PDU CEG436: Mobile Computing 49

50. 10.50 WSP/B over WTP - asynchronous, unordered requests S-MethodInvoke_1.req S-MethodInvoke_1.ind client S-SAP server S-SAP S-MethodInvoke_2.req S-MethodInvoke_3.req S-MethodResult_1.ind S-MethodInvoke_4.req S-MethodResult_3.ind S-MethodResult_4.ind S-MethodResult_2.ind S-MethodInvoke_3.ind S-MethodInvoke_2.ind S-MethodResult_1.req S-MethodResult_2.req S-MethodResult_3.req S-MethodResult_4.req S-MethodInvoke_4.ind CEG436: Mobile Computing 50

51. 10.51 WSP/B - confirmend/non-confirmed push S-Push.req (PH, PB) client S-SAP server S-SAP ConfPush PDU WTP Class 1 transaction S-Push.ind (PH, PB) S-ConfirmedPush.res (CPID) S-ConfirmedPush.ind (CPID, PH, PB) WTP Class 0 transaction Push PDU S-ConfirmedPush.req (SPID, PH, PB) client S-SAP server S-SAP S-ConfirmedPush.cnf (SPID) CEG436: Mobile Computing 51

52. 10.52 WSP/B over WDP S-Unit-MethodInvoke.req (SA, CA, TID, M, RU) client S-SAP server S-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 Unitdata service CEG436: Mobile Computing 52

53. 10.53 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,... CEG436: Mobile Computing 53

54. 10.54 WAE logical model Origin Servers web server other content server GatewayClient other WAE user agents WML user agent WTA user agent encoders & decoders encoded request encoded response with content response with content push content encoded push content CEG436: Mobile Computing 54

55. 10.55 Wireless Markup Language (WML) 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 CEG436: Mobile Computing 55

56. 10.56 WML – example I <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> This is a simple first card! On the next one you can choose... CEG436: Mobile Computing 56

57. 10.57 WML – example II... your favorite pizza! Margherita Funghi Vulcano Your personal pizza parameter is $(PIZZA) ! CEG436: Mobile Computing 57

58. 10.58 WMLScript 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 CEG436: Mobile Computing 58

59. 10.59 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; }; CEG436: Mobile Computing 59

60. 10.60 Wireless Telephony Application (WTA) 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"); CEG436: Mobile Computing 60

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

62. 10.62 Voice box example Service Indication WTA-User-AgentWTA-ServerMobile networkVoice 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 WTA-Gateway Push URL Display deck; user selects WSP Get HTTP Get Respond with content WML Binary WML WSP Get HTTP Get Respond with card for call WML Binary WML Wait for call Setup call CEG436: Mobile Computing 62

63. 10.63 WTAI - example with WML only <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> Please choose your candidate! Your selection: Mickey Donald Pluto CEG436: Mobile Computing 63

64. 10.64 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"); } CEG436: Mobile Computing 64

65. 10.65 WTAI - example with WML and WMLScript II <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> Please choose your candidate! Your selection: Mickey Donald Pluto Status: $Message $No CEG436: Mobile Computing 65

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

67. 10.67 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"> <indication href="http://www.piiiizza4u.de/offer/salad.wml" created="2007-10-30T17:45:32Z" si-expires="2007-10-30T17:50:31Z"> Salad special: The 5 minute offer CEG436: Mobile Computing 67

68. 10.68 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.wm l"> CEG436: Mobile Computing 68

69. 10.69 Examples for WAP protocol stacks (WAP 1.x) WAE WSP WTP UDP IP (GPRS,...) WDP non IP (SMS,...) WTLS WAE user agent WAP standardization outside WAP WTP UDP IP (GPRS,...) WDP non IP (SMS,...) WTLS UDP IP (GPRS,...) WDP non IP (SMS,...) WTLS transaction based application datagram based application typical WAP application with complete protocol stack pure data application with/without additional security 1. 2.3. CEG436: Mobile Computing 69

70. 10.70 i-mode – first of all a business model! Access to Internet services in Japan provided by NTT DoCoMo – Services Email, short messages, web, picture exchange, horoscope,... – Big success (in some countries) – millions of users Many use i-mode as PC replacement For many this was 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 plus proprietary tags, special transport layer (Stop/go, ARQ, push, connection oriented) PDC-P TL HTTP(S) cHTML + tags mobile terminal PDC-P TL mobile networkgatewaycontent provider L1 L2 IP TCP L1 L2 IP TCP L1 L2 IP TCP L1 L2 IP TCP HTTP(S) cHTML + tags CEG436: Mobile Computing 70

71. 10.71 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!) - not successful in e.g. Germany (stopped in 2008) CEG436: Mobile Computing 71

72. 10.72 i-mode protocol stack based on WAP 2.0 user equipmentgateway 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 HTTP SSL TCP IP L2 L1 CEG436: Mobile Computing 72

73. 10.73 i-mode – Technical Requirements FunctionsDescriptionsStatusRequirement WEB AccessPortal Site / Internet AccessMi-mode HTML (cHTML+tags) E-mailInternet e-mail and inter-terminal emailMHTTP 1.1 SecurityEnd-End securityOSSL (Version 2, 3), TLS 1 JavaJava application made availableOCompatible i-mode JAVA Ringing tone downloadRinging melody downloadMSMF based Image downloadStand-by screen downloadMGIF (O: JPEG) Voice call notification during i-mode session Voice termination notified and responded during i- mode communications M3GPP standard system Content charge billingPer content charge billed to userMSpecifications depend on billing system Third party payment collection Content charge collection on behalf of Content ProviderMSpecifications depend on billing system Reverse billingPacket usage charges can be billed to third partyOSpecifications depend on billing system Subscriber ID transmission Hashed subscriber ID from the operator’s portal to the CP transmission on each content access MThe ID gen alg should be secret Num of char per e-mailNumber of characters (byte) per e-mailMTo be defined by operators Char set supportedChar code set supported by browserMTo be defined by operators User AgentBrowser specifications to be notifiedMHTTP 1.1 i-mode buttonDedicated buttonOHard or soft key CEG436: Mobile Computing 73

74. 10.74 Java 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 Java ME (source released as: phone ME / was: J2ME) – Provides a uniform platform – Restricted functionality compared to standard java platform (JVM) CEG436: Mobile Computing 74

75. 10.75 Applications of Java ME Example first cellular phones – NTT DoCoMo introduced i  ppli – 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 CEG436: Mobile Computing 75

76. 10.76 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, … -> MIDlets Hardware (SH4, ARM, 68k,...) Java Virtual Machine (JVM, KVM) Operating system (EPOC, Palm, WinCE) Configurations (CDC, CLDC) Profile (MIDP) Applications CEG436: Mobile Computing 76

77. 10.77 Hardware independent development CEG436: Mobile Computing 77

78. 10.78 Summary Java ME 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 CEG436: Mobile Computing 78

79. 10.79 Middleware Definition RFC2768: – Def 1: Those services found above the transport (i.e., over TCP/IP) layer set of services but below the application environment (i.e., below application-level APIs) – Def 2: A reusable, expandable set of services and functions that are commonly needed by many applications to function well in a networked environment. Industry usage: Software gateway (“glue”) between two apps Generally speaking, middleware provides software services for application programs above the basic operating system and networking services OS and Networking Services Middleware Application Programs API

80. 10.80 Middleware Fundamentals 80 Middleware Goal is to simplify development effort and increase application functionality and robustness – Allow code to run across different platforms – Provide higher level abstractions of services Example functions – Messaging – Distributed object management – Directory services – Location services – User-defined and composite data types – Remote procedure calls (RPC) – Alternate communication abstractions

81. 10.81 Middleware Fundamentals 81 Wireless and Mobile Applications (1) “Resource-poor” mobile devices – Limited memory and buffer space (typically no disk) – Small screen – Low processing capabilities – Limited battery life Location of a mobile device may change frequently due to mobility – Relative to network and other services – Relative to other hosts

82. 10.82 Middleware Fundamentals 82 Wireless and Mobile Applications (2) Capacity of the wireless channel is limited and may vary Communication is often unreliable – Short-term “fades” – high bit errors – Long-term disconnects – disconnected operationForced or voluntary disconnection Disconnected operation (read/write) requires system support – Data caching – Pre-fetching – Integration

83. 10.83 Middleware Fundamentals 83 Desirable Middleware Functionality (1) Optimization – data compression Transformation – data format transformation to suit various device specifications – HTML pages to WML (for WAP 1.0 devices) and vice versa – SOAP/XML for web services From XML to xHTML (for WAP 2.0 and future i-mode devices) From XML to cHTML (for existing i-mode phone devices) Support for security and privacy Support for mobility – Location transparency (ad hoc communication) versus awareness

84. 10.84 Middleware Fundamentals 84 Desirable Middleware Functionality (2) Support for service discovery Support for disconnected operation Context-aware adaptability – Status of the host device, the user, the surrounding environment, and the interactions between the host device and other devices – Essential for pervasive (ubiquitous) computing Platform independence – Same program can be run on a wide variety of devices and platforms

85. 10.85 Middleware Fundamentals 85 Example “Mobile” Middleware (1) Client-server model – Wireless Application Protocol (WAP) – Web services Server – Microsoft’s Mobile Internet Toolkit (MIT) Client – Microsoft’s eMbedded Visual Toolkit (eVT) – Microsoft’s.NET Compact Framework (.NET CF) – Sun’s Java 2 Micro Edition (J2ME)

86. 10.86 Middleware Fundamentals 86 Example “Mobile” Middleware (2) Peer-to-peer and ad hoc model – Intel/Microsoft Universal Plug and Play (UPnP) – Jini/J2ME – Service Location Protocol (SLP)

87. 10.87 Middleware Service: Transcoding Decode and Recode Reduce latency experienced by user – Reduce image’s color depth, resolution to get smaller file Provide access to new types of content PDF  text, Speech  text Client variations along three dimensions: – Network variation bandwidth, latency and error behavior – Hardware variation screen size/resolution, color/grayscale bit depth, memory, CPU – Software variation Applications for specific MIME types (PDF, PS, PPT, AVI, etc.) Codecs for specific encodings (H263, JPEG, etc.)

88. 10.88 Transcoding design issues How: Datatype-specific lossy compression mechanisms: distillation & refinement based on (MIME) type of data Where: at the content server or at a proxy When: static or on- demand

89. 10.89 Issues for Middleware Design Legacy systems and protocols Diverse networks (wireline, indoor & outdoor wireless) Network dynamics: congestion, link errors, failures, attacks Device and platform heterogeneity User mobility Thin-client support Large number of users and devices

90. 10.90 Some middleware design goals for wireless and mobile devices Improve user experience across heterogeneous devices (e.g. PDAs, laptops, desktops) – e.g. transcoding (adaptive content delivery) Provide new services for heterogeneous devices – e.g. application state migration Minimal change to the existing infrastructure and applications: may add/change a few more “boxes” Adaptation to network dynamics (induced by mobility and wireless links) Scalable and secure service Service availability (in the presence of failures, attacks and large user population)

91. 10.91 Distillation and refinement Main idea: high-level semantic types (MIME types) dictate datatype-specific operations – Images: can discard color info, high-frequency components, or pixel resolution – Video: additionally include frame rate reduction – Formatted text: can discard some formatting information Datatype-specific distillation: highly lossy, datatype-specific compression that preserves most of the semantic content of a data object while adhering to a particular set of constraints Datatype-specific refinement: fetching some part (possibly all) of a source object at increased quality, possibly the original representation

92. 10.92 Choices to handle client variations Server ignores variations: – low-end clients may suffer Server use the most basic types & minimal graphics: – high-end client suffers Servers provide multiple formats: – used today by major websites (ESPN, Amazon, Yahoo) – need to categorize clients into discrete classes Progressive encodings: – typically assume that all parts of the encoded documents are equally important On-demand distillation and refinement: – generate on-the-fly based on client characteristics

93. 10.93 A Middleware Design Framework Three-tier model: client – proxy – server Transformation: distillation, filtering, format conversion, etc. Aggregation: collect and collate data from various sources Caching: both original and transformed content Customization: user-customized service (user profiling, adaptive service to each user’s needs or device characteristics)

94. 10.94 Why do we need a proxy ? Advantages for servers: – Servers concentrate on serving high quality content, rather than having to keep multiple versions – Servers do not pay the costs required to do on-demand distillation Advantages for clients: – Low-end clients can rely on the proxy to optimize content from servers designed for high-end clients – Client communicates with a single logical entity—proxy, allowing the client to manage bandwidth at the application level Advantages for both: – Pushing the complexity away from both clients and servers by relocating it into the network infrastructure – Distillation and refinement can be offered as a value-added service by a service provider

95. 10.95 A Scalable Cluster-based Infrastructure Address three issues: incremental scalability, 24x7 availability, and cost effectiveness A cluster based architecture for scalable network services – Exploit the strength of cluster computing – Cluster-based servers BASE data semantics: basically available, soft state, eventual consistency.

96. 10.96 Cluster architecture Front-end Load-balancer Workstation cluster Webserver

97. 10.97 Why do we need clusters? Scalability: – well-suited for networking service workloads that are highly parallel – Clusters can grow incrementally over time High availability: – Natural redundancy due to the independence of the nodes – Hot upgrade: disable a node and upgrade it in place Commodity building blocks: – Use low-end, high-volume PCs rather than high-end, low-volume machines Bad thing about clusters: – Administration; component and system replication (software should decompose into loosely coupled modules); partial failures; shared state

98. 10.98 An example: adaptive transcoding proxy Web server  transcoding proxy  web browser Proxy architecture: – Content analysis – Adaptive transcoding policies: when and how much to transcode – Transformation modules: text modification, images decode & compress Key design goal: – Improve latency experienced by user at heterogeneous devices – fixed quality or fixed delay

99. 10.99 Design Two scenarios: – Store-and-forward image transcoding – Streamed image transcoding Two main issues: – Whether to transcode – How much to transcode

100. 10.100 How to decide whether to transcode? D p = transcoding delay, S = orig size, S p = transcoded size w/o transcoding: – 2*RTT pc + 2*RTT sp + S / min(B pc, B sp ) w/transcoding: – 2*RTT pc + 2*RTT sp + D p + S / B sp + S p /B pc If B pc < B sp, proxy-based transcoding useful when: – D p + S/B sp < (S-S p )/B pc How to predict transcoding delay? B pc B sp clientproxyserver

101. 10.101 Store-and-forward Image Transcoding Prediction – Transcoded image’s output size in bytes: high correlation between output size and the image area (number of pixels)  linear interpolation – Prediction of transcoding delay: approximated by linear function of the input image area Policies: – Fixed-quality transcoder: if (transcoding = feasible), transcode according to user’s parameter vector – Fixed-delay transcoder: if(transcoding=feasible), search space of transcoding parameters to find optimal set that maximizes quality subject to the given response time, transcode using the optimal parameters

102. 10.102 Transcoding internal stages Determine target parameters – In-band or out-of-band data – Use HTTP headers – Use a client profile and/or network conditions Download data and characterize it – E.g. get image’s type, resolution, and color depth Apply heuristics and policies – How to match data’s characteristics to target parameters? – Multi-dimensional constraint satisfaction Execute the transcoding – Typically can use off-the-shelf software

103. 10.103 Streamed image transcoding Perform transcoding under two stability conditions: – No buffer overflow – Output transmission link is not saturated

104. 10.104 Middleware service: Application session handoff (ASH) We want continuous access to our data across these machines Middleware software will integrate data across devices – for immediate access to information anytime, anywhere Move applications across multiple computers

105. 10.105 More application session handoff Applications will have session state – discrete data – multimedia, streaming data Application session handoff: application’s state will move automatically and seamlessly across devices Data will be transcoded for each device

106. 10.106 Broad view of system Application Server High Bandwidth Network Middleware Cluster Wireless Network Clients

107. 10.107 Application session handoff in action Legacy Multimedia DBMS

108. 10.108 Middleware design issues for ASH Client must incorporate application-layer library code to participate with proxy Protocol gateway – client  proxy : custom control protocol + application-specific protocol – Proxy  server: HTTP, SMTP, RTP, etc. Service discovery Data consistency protocols Scalability across cluster of proxies PKI-based security

109. 10.109 Middleware Fundamentals 109 Summary Basics of middleware and unique requirements for wireless and mobile devices Example middleware: WAP, J2ME, and.NET CF

110. 10.110 Summary Middleware provides improved user experience or additional functionality Middleware runs within limits of existing legacy system or protocols New functionality typically implemented at a proxy Clustering provides scalability for proxy services

111. 10.111 Middleware Fundamentals 111 Resources S. Helal, “Pervasive Java,” IEEE Pervasive Computing, Vol. 1, No. 1, Jan.-March 2002, pp. 82-85. S. Helal, “Pervasive Java, Part II,” IEEE Pervasive Computing, Vol. 1, No. 2, April-May 2002, pp. 85-89. C. Neable, “The.NET Compact Framework,” IEEE Pervasive Computing, Vol. 1, No. 4, Oct.-Dec. 2002, pp. 84-87. A. Tripath, “Challenges in designing next-generation middleware systems,” Communications on the ACM, Vol. 45, No. 6, June 2002, pp. 39-42. Open Mobile Alliance, http://www.openmobilealliance.org/, 2003.

112. 10.112 References Sasu Tarkoma, Mobile middleware: architecture, patterns and practice, John Wiley and Sons, 2009 Schiller, Mobile Communications Chapter 10: Support for Mobility