C10 support for-mobility

5,753 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
5,753
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
184
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

C10 support for-mobility

  1. 1. Mobile Communications Chapter 10: Support for Mobility  File systems  Data bases  WWW and Mobility  WAP (Wireless Application Protocol), i-mode & Co.Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  2. 2. File systems - MotivationGoal  efficient and transparent access to shared files within a mobile environment while maintaining data consistencyProblems  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 unusableSolutions  replication of data (copying, cloning, caching)  data collection in advance (hoarding, pre-fetching)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  3. 3. File systems - consistency problemsTHE 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 againConflict detection  content independent: version numbering, time-stamps  content dependent: dependency graphsProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  4. 4. File systems for limited connectivity ISymmetry  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 namespacesTransparency  hide the mobility support, applications on mobile computers should not notice the mobility  user should not notice additional mechanisms neededConsistency model  optimistic or pessimisticCaching and Pre-fetching  single files, directories, subtrees, partitions, ...  permanent or only at certain points in timeProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  5. 5. File systems for limited connectivity IIData management  management of buffered data and copies of data  request for updates, validity of data  detection of changes in dataConflict solving  application specific or general  errorsSeveral 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)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  6. 6. File systems - Coda IApplication 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) mobile client application cache serverProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  7. 7. File systems - Coda II States of a client Hoarding  user can pre-determine a file list with priorities  contents of the cache determined by hoarding strong the list and LRU strategy (Last connection Recently Used) weak  explicit pre-fetching possible disconnection connection  periodic updating write Comparison of files disconnected connection  asynchronous, background  system weighs speed of updating disconnection against minimization of network traffic emulating Cache misses  modeling of user patience: how long can a user wait for data without an error message?  function of file size and bandwidthProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  8. 8. File systems - Little Work Only changes in the cache manager of the client Connection modes and use Connected Partially Fetch only Disconnected Connected Method normal delayed write optimistic abort at cache to the server replication of files miss Network continuous continuous connection on none requirements high bandwidth demand bandwidth Application office, WLAN packet radio cellular systems independent (e.g., GSM) with costs per callProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  9. 9. 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/disconnectedProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  10. 10. 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” transactionProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  11. 11. 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!Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  12. 12. 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 non persistent 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 <DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>FU-Berlin: Institut f&uuml;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"> <!--script language="JavaScript" src="fuinf.js"--> <!--/script--> </head> <body onResize="self.location.reload();"> ...Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  13. 13. 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 trafficProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  14. 14. HTTP 1.0 and mobility IICaching  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 disconnectedMany unsolved problems!Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  15. 15. 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 costsProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  16. 16. 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 complicatedProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  17. 17. 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...Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  18. 18. System support for WWW in a mobile world IEnhanced browsers mobile client  Pre-fetching, caching, off-line use integrated enhancement  e.g. Internet Explorer browser web serverAdditional, accompanying application  Pre-fetching, caching, off-line use mobile client  e.g. original WebWhacker browser additional application web serverProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  19. 19. System support for WWW in a mobile world IIClient Proxy mobile client  Pre-fetching, caching, off-line use  e.g., Caubweb, TeleWeb, Weblicator, browser client WebWhacker, WebEx, WebMirror, proxy ... web serverNetwork Proxy mobile client  adaptive content transformation for bad connections, pre-fetching, caching browser  e.g., TranSend, Digestor network proxy web serverProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  20. 20. System support for WWW in a mobile world IIIClient and network proxy mobile client  combination of benefits plus client simplified protocols browser proxy  e.g., MobiScape, WebExpress web network server proxySpecial network subsystem  adaptive content transformation mobile client for bad connections, pre-fetching, caching client browser  e.g., Mowgli proxyAdditional many proprietary server web network extensions possible server proxy  “channels”, content negotiation, ...Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  21. 21. 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.org  now: Open Mobile Alliance www.openmobilealliance.org (Open Mobile Architecture + WAP Forum + SyncML + …)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  22. 22. 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.Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  23. 23. WAP 1.x - reference model and protocols Internet A-SAP WAP HTML, Java Application Layer (WAE) additional services and applications S-SAP Session Layer (WSP) HTTP TR-SAP Transaction Layer (WTP) SEC-SAP SSL/TLS Security Layer (WTLS) T-SAP TCP/IP, Transport Layer (WDP) WCMP UDP/IP, media Bearers (GSM, CDPD, ...) WAE comprises WML (Wireless Markup Language), WML Script, WTAI etc.Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  24. 24. WAP - network elements fixed network wireless network Internet HTML WML WAP Binary WML filter proxy HTML WML HTML filter/ Binary WML WAP web HTML proxy server WTA Binary WML server PSTN Binary WML: binary file format for clientsProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  25. 25. WDP - Wireless Datagram ProtocolProtocol 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 onesAdditionally, WCMP (wireless Control Message Protocol) is used for control/error report (similar to ICMP in the TCP/IP protocol suite)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  26. 26. 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)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  27. 27. Usage of WDP Wireless Data Gateway WTLS WTLS WTLS WTLSGSM-SMS WDP & WDP & WDP & WDP & Adaptation Adaptation Adaptation Adaptation SMS SMS SMS SMS Tunnel Tunnel Tunnel Tunnel Subnetwork Subnetwork Subnetwork Subnetwork WAPGSM-CSD Proxy WTLS WTLS WTLS WTLS Internet Service Provider UDP UDP Remote Access Service UDP UDP IP IP Interworking IP IP IP IP PPP Function PPP PPP PPP PSTN PSTN Subnetwork Subnetwork Subnetwork Subnetwork CSD-RF CSD-RF PSTN PSTN CSD-RF CSD-RF Circuit Circuit Circuit CircuitProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  28. 28. WTLS - Wireless Transport Layer SecurityGoals  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 dataWTLS  is based on the TLS (Transport Layer Security) protocol (former SSL, Secure Sockets Layer)  optimized for low-bandwidth communication channelsProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  29. 29. Secure session, full handshake originator peer SEC-SAP SEC-SAP SEC-Create.req (SA, SP, DA, DP, KES, CS, CM) SEC-Create.ind (SA, SP, DA, DP, KES, CS, CM) SEC-Create.res (SNM, KR, SID, KES‘, CS‘, CM‘) SEC-Create.cnf SEC-Exchange.req (SNM, KR, SID, KES‘, CS‘, CM‘) SEC-Exchange.ind SEC-Exchange.res (CC) SEC-Commit.req SEC-Exchange.cnf (CC) SEC-Commit.ind SEC-Commit.cnfProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  30. 30. SEC-Unitdata - transferring datagrams sender receiver SEC-SAP SEC-SAPSEC-Unitdata.req(SA, SP, DA, DP, UD) SEC-Unitdata.ind (SA, SP, DA, DP, UD)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  31. 31. WTP - Wireless Transaction ProtocolGoals  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)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  32. 32. Details of WTP ISupport 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 browsingNo explicit connection setup or release is availableServices for higher layers are called eventsProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  33. 33. Details of WTP IIUsed 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)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  34. 34. WTP Class 0 transaction initiator responder TR-SAP TR-SAPTR-Invoke.req(SA, SP, DA, DP, A, UD, C=0, H) TR-Invoke.ind Invoke P DU (SA, SP, DA, DP, A, UD, C=0, H‘)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  35. 35. WTP Class 1 transaction, no user ack & user ack initiator responder TR-SAP TR-SAP TR-Invoke.req (SA, SP, DA, DP, A, UD, C=1, H) TR-Invoke.ind Invoke P DU (SA, SP, DA, DP, A, UD, C=1, H‘) TR-Invoke.cnf U (H) Ack PD initiator responder TR-SAP TR-SAP TR-Invoke.req (SA, SP, DA, DP, A, UD, C=1, H) TR-Invoke.ind Invoke P DU (SA, SP, DA, DP, A, UD, C=1, H‘) TR-Invoke.res (H‘) TR-Invoke.cnf U (H) Ack PDProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  36. 36. WTP Class 2 transaction, no user ack, no hold on initiator responder TR-SAP TR-SAP TR-Invoke.req (SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke.ind Invoke P DU (SA, SP, DA, DP, A, UD, C=2, H‘) TR-Result.req (UD*, H‘) TR-Invoke.cnf PDU (H) Result TR-Result.ind (UD*, H) TR-Result.res (H) Ack PD TR-Result.cnf U (H‘)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  37. 37. WTP Class 2 transaction, user ack initiator responder TR-SAP TR-SAP TR-Invoke.req (SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke.ind Invoke P DU (SA, SP, DA, DP, A, UD, C=2, H‘) TR-Invoke.res (H‘) TR-Invoke.cnf U (H) Ack PD TR-Result.req (UD*, H‘) TR-Result.ind PDU (UD*, H) Result TR-Result.res (H) Ack PD TR-Result.cnf U (H‘)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  38. 38. WTP Class 2 transaction, hold on, no user ack initiator responder TR-SAP TR-SAP TR-Invoke.req (SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke.ind Invoke P DU (SA, SP, DA, DP, A, UD, C=2, H‘) TR-Invoke.cnf U (H) Ack PD TR-Result.req (UD*, H‘) TR-Result.ind PDU Result (UD*, H) TR-Result.res (H) Ack PD TR-Result.cnf U (H‘)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  39. 39. 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  managementProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  40. 40. WSP protocols WSP Connection mode Connectionless mode (uses WTP) (uses WDP or WTLS) • Session Management (class 0, 2) • Method Invocation • Method Invocation (Kl. 2) • Push • Error Report (in general unreliable) • Push (class 0) • Confirmed Push (class 1) • Session suspend/resume (class 0, 2)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  41. 41. WSP/B session establishment client server S-SAP S-SAP S-Connect.req (SA, CA, CH, RC) Conne S-Connect.ind ct P DU (SA, CA, CH, RC) S-Connect.res (SH, NC) S-Connect.cnf ply P DU (SH, NC) ConnRe WTP Class 2 transactionProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  42. 42. WSP/B session suspend/resume client server S-SAP S-SAP S-Suspend.req Suspe S-Suspend.ind nd PD U (R) S-Suspend.ind (R) WTP Class 0 transaction S-Resume.req (SA, CA) ~ ~ Resum S-Resume.ind e PDU (SA, CA) S-Resume.res PDU S-Resume.cnf Reply WTP Class 2 transactionProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  43. 43. WSP/B session termination client server S-SAP S-SAP S-Disconnect.req (R) Discon S-Disconnect.ind nect P S-Disconnect.ind DU (R) (R) WTP Class 0 transactionProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  44. 44. WSP/B method invoke client server S-SAP S-SAP S-MethodInvoke.req (CTID, M, RU) Metho S-MethodInvoke.ind d PDU (STID, M, RU) S-MethodInvoke.res (STID) S-MethodInvoke.cnf (CTID) S-MethodResult.req (STID, S, RH, RB) S-MethodResult.ind PDU (CTID, S, RH, RB) Reply S-MethodResult.res (CTID) S-MethodResult.cnf (STID) WTP Class 2 transactionProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  45. 45. WSP/B over WTP - method invocation client initiator responder server S-SAP TR-SAP TR-SAP S-SAPS-MethodInvoke.req TR-Invoke.req Invo ke(Me thod) TR-Invoke.ind S-MethodInvoke.ind TR-Invoke.res S-MethodInvoke.res US-MethodInvoke.cnf TR-Invoke.cnf Ack PD TR-Result.req S-MethodResult.req eply)S-MethodResult.ind TR-Result.ind Result(RS-MethodResult.res TR-Result.res Ack PD U TR-Result.cnf S-MethodResult.cnfProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  46. 46. WSP/B over WTP - asynchronous, unordered requests client server S-SAP S-SAP S-MethodInvoke_1.req S-MethodInvoke_2.req S-MethodInvoke_2.ind S-MethodInvoke_1.ind S-MethodInvoke_3.req S-MethodResult_1.req S-MethodInvoke_3.ind S-MethodResult_1.ind S-MethodResult_3.req S-MethodResult_3.ind S-MethodResult_2.req S-MethodInvoke_4.req S-MethodInvoke_4.ind S-MethodResult_4.ind S-MethodResult_4.req S-MethodResult_2.indProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  47. 47. WSP/B - confirmend/non-confirmed push client server S-SAP S-SAP S-Push.req (PH, PB) S-Push.ind DU (PH, PB) Push P WTP Class 0 transaction client server S-SAP S-SAP S-ConfirmedPush.req (SPID, PH, PB) S-ConfirmedPush.ind ush PDU (CPID, PH, PB) ConfP S-ConfirmedPush.res (CPID) S-ConfirmedPush.cnf (SPID) WTP Class 1 transactionProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  48. 48. WSP/B over WDP client server S-Unit-MethodInvoke.req S-SAP S-SAP (SA, CA, TID, M, RU) Metho S-Unit-MethodInvoke.ind d PDU (SA, CA, TID, M, RU) S-Unit-MethodResult.req (CA, SA, TID, S, RH, RB) S-Unit-MethodResult.ind PDU (CA, SA, TID, S, RH, RB) Reply S-Unit-Push.req (CA, SA, PID, PH, PB) S-Unit-Push.ind D U (CA, SA, PID, PH, PB) Push P WDP Unitdata serviceProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  49. 49. 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, ...Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  50. 50. WAE logical model Origin Servers Gateway Client response encoded WTA web with response user agent server content with encoders content & decoders WML other content user agent server push encoded content push content other WAE user agents request encoded requestProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  51. 51. 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 capabilitiesFeatures  text and images  user interaction  navigation  context managementProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  52. 52. 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>Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  53. 53. 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>Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  54. 54. WMLScriptComplement to WMLProvides general scripting capabilitiesFeatures  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 deploymentProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  55. 55. WMLScript - examplefunction pizza_test(pizza_type) { var taste = "unknown"; if (pizza_type = "Margherita") { taste = "well... "; } else { if (pizza_type = "Vulcano") { taste = "quite hot"; }; }; return taste;};Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  56. 56. Wireless Telephony Application (WTA)Collection of telephony specific extensionsExtension 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 functionsExample  calling a number (WML) wtai://wp/mc;07216086415  calling a number (WMLScript) WTAPublic.makeCall("07216086415");Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  57. 57. WTA logical architecture other telephone networks WTA server client WML scripts mobile WTA WTA & WML network user agent server WML decks WAP gateway repository WTA services encoders & device network operator decoders specific trusted domain other functions servers third party firewall serversProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  58. 58. Voice box exampleWTA-User-Agent WTA-Gateway WTA-Server Mobile network Voice box server Indicate new voice message Generate new deck Service Indication Push URL Display deck; user selects WSP Get HTTP Get Respond with content Binary WML WML Display deck; user selects WSP Get HTTP Get Respond with card WML for call Binary WML Play requested voice message Wait for call Call setup Setup call Setup call Accept call Accept call Accept call Voice connectionProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  59. 59. 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>Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  60. 60. WTAI - example with WML and WMLScript Ifunction 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");}Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  61. 61. 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>Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  62. 62. WAP push architecture with proxy gatewayPush Access Protocol  Content transmission between server and PPG  First version uses HTTPPush OTA (Over The Air) Protocol  Simple, optimized  Mapped onto WSP Push Proxy Push Push OTA Gateway Access Client Push Initiator Protocol Protocol User Agents Server Coding, application checkingProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  63. 63. Push/Pull services in WAP IService Indication  Service announcement using a pushed short message  Service usage via a pull  Service identification via a URI<?xml version="1.0"?> <!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN" "http://www.wapforum.org/DTD/si.dtd"><si> <indication href="http://www.piiiizza4u.de/offer/salad.wml" created="2002-10-30T17:45:32Z" si-expires="2000-10-30T17:50:31Z"> Salad special: The 5 minute offer </indication></si>Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  64. 64. Push/Pull services in WAP IIService 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<?xml version="1.0"?> <!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN" "http://www.wapforum.org/DTD/sl.dtd"><sl href="http://www.piiiizza4u.de/offer/salad.wml"></sl>Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  65. 65. Examples for WAP protocol stacks (WAP 1.x) WAP standardization WAE user agent outside WAP WAE transaction based WSP application datagram based WTP WTP application WTLS WTLS WTLS UDP WDP UDP WDP UDP WDP IP non IP IP non IP IP non IP (GPRS, ...) (SMS, ...) (GPRS, ...) (SMS, ...) (GPRS, ...) (SMS, ...) 1. 2. 3. typical WAP pure data application with application complete protocol with/without stack additional securityProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  66. 66. 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 – 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 plus proprietary tags, special transport layer (Stop/go, ARQ, push, connection oriented) mobile terminal mobile network gateway content provider cHTML + tags cHTML + tags HTTP(S) HTTP(S) TL TL TCP TCP TCP TCP IP IP IP IP PDC-P PDC-P L2 L2 L2 L2 L1 L1 L1 L1Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  67. 67. Email example: i-mode push with SMS Popular misconception: application WAP was a failure, i-mode is different WSP and a success – wrong from a technology point of view, right from a WTP business point of view… WDP SMS i-mode as a business model: - content providers get >80%Operator sends an SMS containing a of the revenue.push message if a new email has - independent of technologyarrived. If the user wants to read the (GSM/GPRS in Europe,email, an HTTP get follows with the PDC-P in Japan – but alsoemail as response. UMTS!)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  68. 68. i-mode protocol stack based on WAP 2.0 user equipment gateway server cHTML cHTML HTTP HTTP SSL SSL WTCP WTCP TCP TCP IP IP IP IP L2 L2 L2 L2 L1 L1 L1 L1 i-mode can use WAP 2.0/Internet protocols (example: i-mode in Germany over GSM/GPRS)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  69. 69. i-mode – technical requirementsFunctions Descriptions Status RequirementWEB Access Portal Site / Internet Access M i-mode HTML (cHTML+tags)E-mail Internet e-mail and inter-terminal email M HTTP 1.1Security End-End security O SSL (Version 2, 3), TLS 1Java Java application made available O Compatible i-mode JAVARinging tone download Ringing melody download M SMF basedImage download Stand-by screen download M GIF (O: JPEG)Voice call notification during i- Voice termination notified and responded during i-mode M 3GPP standard systemmode session communicationsContent charge billing Per content charge billed to user M Specifications depend on each operator’s billing systemThird party payment collection Content charge collection on behalf of Content Provider M Specifications depend on each operator’s billing systemReverse billing Packet usage charges can be billed to third party O Specifications depend on each operator’s billing systemSubscriber ID transmission Hashed subscriber ID from the operator’s portal to the CP M The ID generation algorithm transmission on each content access should be determined by each operator and has to be secretNumber of characters per e- Number of characters (byte) per e-mail M To be defined by operators (e.g.mail 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 operatorsUser Agent Browser specifications to be notified M HTTP 1.1i-mode button Dedicated button O Hard or soft key Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  70. 70. i-mode examples IProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  71. 71. i-mode examples IIProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  72. 72. i-mode examples IIIProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  73. 73. WAP 2.0 (July 2001)New for developers  XHTML  TCP with „Wireless Profile“  HTTPNew applications  Color graphics  Animation  Large file download  Location based services  Synchronization with PIMs  Pop-up/context sensitive menusGoal: integration of WWW, Internet, WAP, i-modeProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  74. 74. WAP 2.0 architecture Service Security Multimedia Messaging Content discovery services (Email) formats External Crypto WAE/WTA User Agent Pushservices EFI libraries (WML, XHTMLMP) not acl pp A kr o we m rf a Authenti- i iProvisioning cation Capability Negotiation Push Cookies Navigation OTA Synchronisation no ss e S Identification Discovery i Service Hypermedia transfer Strea- PKI MMS Lookup (WTP+WSP, HTTP) ming r e s na T f r Secure Connections Datagrams transport (TCP with (WDP, UDP) wireless profile) kr o we m rf l oc o o P r e ae B t r ops na T r t r Secure IPv4 CSD USSD GPRS ... bearer IPv6 SMS FLEX MPAK ... a rProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  75. 75. WAP 2.0 example protocol stacks WAP device WAP gateway Web server WAE WAE WSP WSP WAP device WAP proxy Web server HTTP HTTP WTP WTP WAE WAE WTLS WTLS TLS TLS HTTP‘ HTTP‘ HTTP HTTP WDP WDP TCP TCP TCP‘ TCP‘ TCP TCP bearer bearer IP IP IP IP IP IP WAP 1.x Server/Gateway/Client WAP HTTP Proxy with profiled TCP and HTTP WAP device WAP proxy Web server WAE WAE WAP device Web server HTTP HTTP WAE WAE TLS TLS HTTP IP router HTTP TCP‘ TCP‘ TCP TCP TCP TCP IP IP IP IP IP IP IP IP WAP Proxy with TLS tunneling WAP direct accessProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  76. 76. 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 hardwareJ2ME  Provides a uniform platform  Restricted functionality compared to standard java platform (JVM)Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  77. 77. Applications of J2MEExample 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 factorProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  78. 78. Characteristics and architectureJava Virtual Machine  Virtual Hardware (Processor) Applications  KVM (K Virtual Machine)  Min. 128 kByte, typ. 256 kByte Profile  Optimized for low performance devices (MIDP)  Might be a co-processor ConfigurationsConfigurations (CDC, CLDC)  Subset of standard Java libraries depending technical hardware parameters (memory, CPU) Java Virtual Machine  CLDC (Connected Limited Device Configuration) (JVM, KVM)  Basic libraries, input/output, security – describes Java support for mobile devices Operating systemProfiles (EPOC, Palm, WinCE)  Interoperability of heterogeneous devices belonging to the same category Hardware  MIDP (Mobile Information Device Profile) (SH4, ARM, 68k, ...)  Defines interfaces for GUIs, HTTP, application support, …Prof. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  79. 79. Hardware independent developmentProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/
  80. 80. Summary J2MEIdea is more than WAP 1.x or i-mode  Full applications on mobile phones, not only a browser  Includes system updates, end-to-end encryptionPlatform independent via virtualization  As long as certain common interfaces are used  Not valid for hardware specific functionsLimited functionality compared to JVM  Thus, maybe an intermediate solution only – until embedded systems, mobile phones are as powerful as today’s desktop systemsProf. Dr.-Ing. Jochen Schiller, http://www.jochenschiller.de/

×