COMP327 Mobile Computing Session:

Transcription

1 COMP327 Mobile Computing Session: Lecture Set 7 - The Mobile Internet [ last updated: 12 November 2018 ] 1

2 In this Lecture Set Challenges of Mobile access to the Internet Early Wireless Internet Systems Wireless Application Protocol Architecture and Application Environment Multimedia Messaging Service Short Messaging Service OTA Programming imessage 2

3 The challenges in moving from fixed line PCs to Mobile Devices To understand the challenges (and pitfalls) of moving to a Mobile Internet, first consider the fixed line Internet! Initially, most usage was and web Mostly free, other than modem connection charges Top down content distribution model The web was read-only - Web 1.0 Early retailers (e.g. Amazon) exposed inventory, but offered few value-based services Evolved slowly over several years ( incubation time ), driven by access and expectation Technologies had the chance to settle and be tested before large-scale adoption 3

4 The challenges in moving from fixed line PCs to Mobile Devices Things were different when the Mobile Internet launched Access was initially targeted at general public Previous technologies were tried and tested by students and universities, which ironed out problems Access was charged from day one! Reduced adoption, and raised false expectation Content and Services were adapted from the Web, rather than redesigned to exploit mobility Very few sites or services had any appeal or use for users WAP stack required new tools and additional effort, yet served a small user base! Early networks unsuited for packet-switched data Initial usage was expensive, thus limiting uptake 4

5 The Mobile Internet: Early Precursors Early approaches to providing content had to contend with new technical challenges: Limited Screen Size and limited input capability Not suited for most web pages Limited memory, processor and power May struggle to handle any client-side processing Intermittent connectivity HTTP is stateless Web 2.0 was emerging on the fixed-line Internet Placed greater demands on both the device and the interface Greater potential for mobile devices, though this was not realised for years Various content markup solutions have emerged 5

6 Stateless vs Stateful Protocols A stateless protocol is a communications protocol that treats each request as an independent transaction Unrelated to any previous request so that the communication consists of independent pairs of request and response. Server does not need to retain session information or status about each communications partner for the duration of multiple requests. In contrast, a protocol that requires keeping of the internal state on the server is known as a stateful protocol. Examples of stateless protocols include the Internet Protocol (IP), and the Hypertext Transfer Protocol (HTTP). Stateless design simplifies the server design because there is no need to dynamically allocate storage to deal with conversations in progress. If a client session dies in mid-transaction, no part of the system needs to be responsible for cleaning up the present state of the server. A disadvantage of statelessness is that it may be necessary to include additional information in every request, and this will need to be interpreted by the server. 6

7 Taken from Wikipedia, at Copyright: Matthew Stuckwisch, 2008 GNU Free Documentation License, V1.2 and Creative Commons Attribution 3.0 License 7

8 AT&T PocketNet A mobile data service introduced in the US in 1996 Relied on Cellular Digital Packet Data (CDPD) Built on top of the D-AMPS/TDMA infrastructure Exploited an unused bandwidth previously used by AMPS Provided speeds of up to 19.2kbit/s Provided a basic TCP/IP stack to deliver data Content presented using a stripped-down HTML language Handheld Device Markup Language (HDML) A microbrowser was also developed - UP.View Content was primarily text Introduced the Deck-of-Cards metaphor 8

9 Palm.Net - WebClipping WebClipping optimises transfer of HTML by caching static web content on the device Introduced in 1998 by Palm Aimed mainly at Palm s PDAs Which had more screen real-estate than mobile phones Only dynamic content is sent over wireless Several hundred web services were adapted Primarily finance, shopping, information, and entertainment 9

10 Palm PDAs (Palm Pilot) 10

11 NTT DoCoMo i-mode A service delivery system introduced by DoCoMo in Japan, 1999 Uses a variety of protocols to deliver content formatted in a compact variant of HTML (C-HTML) i-mode enabled phones posses a special i-mode button Provided access to more than 12,000 official sites through DoCoMo s portal sites and billing services Over 100,000 unofficial ones!!! Users paid for both up and downlink data, but monthly packages existed Operated over DoCoMo s PDC-P packet-switch network Over 49 million users worldwide in 2009, but now declining 11

12 i-mode and C-HTML Adds several features not available in HTML Introduced: Access Keys to improve navigation Phone number shortcuts for links Emoji characters (Japanese emoticons) No support for JPEG images, tables, image maps, multiple fonts, background colours and images, style sheets etc. Basic operations done through four keys, not mouse movement Cursor forward and backward, select, and back/stop Has been overtaken by XHTML 12

13 The reason for i-mode s Success Ease of use Early use of packet-switched data, with easy access through the i- Mode button Critical mass of compelling content Vast number of legal sites with partnership agreements, all discoverable through the main i-mode portal. Usage/payment agreements pre-arranged through DoCoMo Eliminated the need for provider billing, and hence reduced deployment costs for content providers DoCoMo generated incremental revenue by charging a small commission for the clearinghouse billing system service. For more details on the i-mode Business Model, look at No longer available. Wayback machine has last copy from

14 WAP: Wireless Application Protocol An open international standard to support access to the Mobile Web Established in June 1997 Joint Forum including Ericsson, Nokia, Motorola and Openwave The previous approaches discussed were all proprietary WAP was developed as an open standard Released WAP Specification 1.1 in Summer 1999 First services and devices available by the end of that year Based on GSM, it was heavily hyped, but failed to live up to expectation in Europe (although successful in Asia) Worthless Application Protocol, Wait And Pay 14

15 WAP 1.1 Gateway A Gateway translated packets from the WAP stack to the Internet stack Overcame the differences in assumptions of each stack Improves communication by Caching content Authenticating users and providing billing support Compressing and encrypting data across the air interface To Mobile Device Encoding/Decoding WSP: Session Layer HTTP: Hypertext Transfer Protocol WTP: Transport Layer WTLS: Security Layer TLS/SSL: Transport Layer Security WDP: Transport Layer TCP: Transmission Control Protocol Bearer Networks IP: Internet Protocol Wired Internet Traffic 15

16 WAP 1.1 Architecture Wireless Datagram Protocol (WDP) Provides an interface between the WAP stack and the bearer networks Wireless Transport Layer Security (WTLS) Based on the Internet s TLS Tailored for low-bandwidth, high-latency links Also provides provision for security, privacy, data integrity and authentication Wireless Transaction Protocol (WTP) Simplified, wireless substitute for TCP with some HTTP functionality Optimised for wireless links Three classes of content delivery WAE: Application Layer WSP: Session Layer WTP: Transport Layer WTLS: Security Layer WDP: Transport Layer Bearer Networks WTP Class 0 Unreliable message delivery WTP Class 1 Reliable message delivery without result e.g. push notification WTP Class 2 Reliable message delivery with acknowledgement e.g. banking applications 16

17 WAP 1.1 Architecture Wireless Session Protocol (WSP) Provides HTTP/1.1 functionality Introduces shared state between client and server to optimise transfer Facilitates session resumption after suspension due to loss of connection, etc Responsible for binary encoding of sessions Wireless Application Environment Provides the WAP browser and support for WML, scripting, etc Provides access to Wireless Telephony Applications Interface (WTAI) WAE: Application Layer WSP: Session Layer WTP: Transport Layer WTLS: Security Layer WDP: Transport Layer Bearer Networks Supports telephony services from WAP session 17

18 Wireless Application Environment (WAE) Consists of the following specifications: Wireless Markup Language (WML) Based on HTML and HDML (originally from AT&T s PocketNet) WAP Binary XML Format (WBXML) Binary encoding and transfer of XML to reduce traffic size across air interface WMLScript Based on JavaScript, to execute client-side services and reduce repeated comms such as validating user input Wireless Telephony Application (WTAI) Telephony-specific for call and feature control mechanisms Content Formats Data formats such as calendar entries, images, and address book records 18

19 Wireless Markup Language (WML) Based on the Deck of Cards Metaphor All cards sent simultaneously User then navigates content without bursty comms Overcomes GSM/GPRS latency problems with bursty browsing behaviour Uses soft keys, where the semantics change as the context changes Includes client-side logic through WMLScript Simplified variant of JavaScript Avoids unnecessary round-trip comms e.g. validating user-entered data Supports functions for digital signing WAP 2.0 supports XHTML Basic Separates the data (XML) from the presentation (CSS) 19

20 Inspiration for the Deck of Cards Metaphor Mobile Phones have tiny screens Can only display a limited amount of content Many applications assume a dialog-based interaction (i.e. cards) Each interaction involves a number of options, leading to further options based on the earlier choice By bundling all the cards together (a deck) and sending in one transaction, transmission time and delays could be reduced. 20

21 WML Example <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" " > <wml> <card id="card1" title="first Card"> <do type= accept label= NEXT > <go href= #Card2 /> </do> <p mode="wrap">a sample WML page. Press NEXT.</p> </card> <card id="card2" title="second Card"> <p>this is card 2.</p> </card> </wml> --First Card-- A sample WML page. Press NEXT. Options -Browser Options- Next Select Back --Second Card-- This is card 2. Options 21

22 WAP 2.0 Architecture WAP 2.0 introduced an alternative stack Consisted of variations of the TCP and HTTP protocols which had been configured for wireless comms WAP 1.1 stack now referred to as a legacy stack Aimed at 2.5G and 3G bearer networks Gateway significantly simplified Finally supports true end-to-end security WML replaced by XHTML Mobile Profile Better transcoding, and use of W3C tools such as CSS WAP push introduced, to support server-initiated sessions Good for real-time information, such as stock quotes Device capability could be defined using a User Agent Profile 22

23 User Agent Profiles A protocol to determine the capabilities of the WAP client Introduced in WAP2.0 Builds upon W3C s Composite Capability/Preference Profile (CC/PP) Represents information such as: Hardware characteristics (screen size and colour capability, bluetooth etc) Software characteristics (OS, A/V codecs, Java support etc) Applications/User preferences (browser type, supported scripting languages) WAP characteristics (WAP version, max WML deck size, etc) Network characteristics (latency, reliability, etc) Information typically sent in WSP (Wireless Session Protocol) or HTTP headers, to aid the server in tailoring content for the client Can vary during a session, due to changes in use or cell characteristics 23

24 Transcoding HTML to WML A variety of microbrowsers emerged on mobile devices Optimised to display Web content effectively on small devices Often stripped down web browsers, but later versions handled CSS etc However, the variety of markup languages made web maintenance and content provision difficult (especially when supporting legacy devices) HTML, WML, C-HTML, XML etc Transcoding addressed this by assuming a canonical source (e.g. XML) which was translated into destination formats, using techniques such as: XSLT (XSL transformation) Java and JAXP (SAX and DOM) Logical HTML, with CSS based on User Agent Profiles for presentation 24

25 Transcoding Challenges Various challenges in converting content Ideally, good design practices should be used Should identify primary / significant content May need to: Reduce or eliminate images Reformat HTML content Separate content into a deck of cards e.g. splitting headed content to produce index page Eliminate functionality for irrelevant interfaces e.g. image maps or mouse-over events 25

26 WAP Criticisms Idiosyncratic WML language Providers have to either provide WML specific content, or rely on Web-to-WAP transcoders. Conceptual Distance between PC screens and mobile display too great Underspecification of terminal requirements Early WAP standards left many features optional Devices often failed to operate properly; functionality was often inconsistent Constrained User Interface Capabilities Early WAP devices had small monochrome screens with limited buttons Even later colour devices lacked conventional PC based interactions Lack of Good Authoring Tools Demands of authoring for WML greater than HTML, but poor tool support 26

27 The WAP User Experience Although WAP introduced a number of features designed to improve the mobile internet experience, many complained of: Slow connections, hence steep bills (pre GPRS) Dead-ends or sites being down Sites with poor sign-posting making search difficult Uneven quality and stale content Small screens Studies in late 2000 found that mundane tasks took longer than users could tolerate 27

28 The WAP User Experience Problems with WAP usage included: Technical limitations due to bearer (GSM) rather than WAP itself Poor site design with little consideration of the user experience. Little in the way of intuitive navigation support Design typically reflected the wired Internet practices with little attempt to understand Mobile Computing constraints Poor content and poorly managed sites Unlike i-mode, European operators failed to set up business models to encourage the generation of quality content Device limitations By the 2010 s WAP had largely been superseded by more modern standards. 28

29 Messaging MMS and SMS Messaging services that allow short messages to be sent from a mobile device......often to other mobile devices, but also to services and servers. SMS - Short Messaging Service A conversational communication mechanism where users exchange short messages Generated revenues of US$114.6 billion globally in 2010 (up from US$89B in 2008) In 2010, 6.1 trillion messages were sent! 561 billion per month in June 2014! Initial uptake was low (0.4 messages per month per user in 1995, 35 in 2000) MMS - MultiMedia Messaging Service An extension of SMS which can handle multimedia (video, images, sound, rich text etc) 336 million messages sent in the UK in 2006, 553m in 2008 More event driven - often activity spikes at Christmas, celebrations etc 4.4 million picture messages were sent on Christmas Day 2008 (3x daily average) 29

30 Short Messaging Service SMS The most widely used data application on the planet Uses include Messaging, OTA programming, Value-added Services, and Televoting Originally defined as part of the GSM series of standards to send up to bit character messages Sent over the signalling paths during quiet (non-call) periods Required the inclusion of a Short Message Service Centre node (SMSC). First commercial deployments in 1993 Subsequent uptake in other technologies CDMA networks, Digital AMPS, 3G, and both satellite and landline networks 30

31 Short Messaging Service SMS Messages sent to a Short Message Service Centre (SMSC) Provides a store and forward mechanism: Attempts to send messages to recipients If recipient is unavailable, the message is queued for a later retry No guarantees that message will be sent, but delivery reports can be requested 31

32 SMS Message Size Messages are 140 octets long (8*140=1120 bits) plus routing data and metadata Messages can be encoded using different alphabets: 1. A Default GSM 7-bit alphabet Each character encoded as 7 bits from a basic character set Possible to send up to 160 characters (160 * 7 = 1120 bits = 140 octets) Extended character set provides an additional table of escaped characters Represented using 2 characters - an escape, followed by a second character 8 bit bit

33 SMS Message Size Messages are 140 octets long (8*140=1120 bits) plus routing data and metadata Messages can be encoded using different alphabets: 2. A National Language Shift Table Also uses 7-bit encoding, but requires a 4 octet UDH (User Data Header) to identify the language Uses an extended escaped character set to represent a shift table Possible to send up to 155 characters (155 * 7 = approx 136 octets, + 4 UDH octets) Supports languages such as Urdu, Hindi, etc, UDH

34 SMS Message Size Messages are 140 octets long (8*140=1120 bits) plus routing data and metadata Messages can be encoded using different alphabets: 3. An 8-bit data alphabet Treated as raw data - up to 1120 bits (or 140 octets of data) 8 bit raw data

35 SMS Message Size Messages are 140 octets long (8*140=1120 bits) plus routing data and metadata Messages can be encoded using different alphabets: 4. A 16 bit UCS-2 alphabet Supports most commonly used Latin and eastern character sets Arabic, Chinese, Korean, Cyrillic Possible to send up to bit characters in 1 message 16 bit Default mode is GSM7-bit, but if an extended character is used (e.g. lower case c with cedilla - ç ), then all characters are converted into 16-bit UCS-2 characters. 35

36 Longer SMS messages Concatenated SMS can be used to overcome the message length limitation (140 octets) Message is split into a number of segment messages, each of which include User Data Header (UDH) Receiving device then re-assembles message Each smaller message is charged at the same price as a single message. UDH lengths can vary, depending on the alphabet GSM 7-bit alphabet: bit characters per segment 8-bit data alphabet: bit characters per segment 16-bit UCS-2 alphabet: bit characters per segment Example A message containing bit characters can be sent in a single SMS message A message containing bit characters will be sent as two SMS messages The first containing bit characters and a 49-bit UDH The second containing 8 7-bit characters and a 49-bit UDH. 36

37 MultiMedia Messaging Service - MMS Often considered a spinoff of SMS and WAP Extends SMS to support transmission of media Driven primarily due to the uptake of camera capabilities within mobile phones Also used to deliver ring tones, etc Developed by the Open Mobile Alliance (OMA) However, was also part of 3GPP and WAP groups Launched in March 2002 across GSM/GPRS and 3G However, deployment and uptake delayed in the US until 2009 (AT&T) Messages typically sent to other mobile devices But due to backward compatibility, messages are sometimes viewed over the web from a 3 rd party device 37

38 MultiMedia Messaging Service - MMS Completely different delivery mechanism to SMS Multimedia content is first encoded using MIME format Then sent to the recipient carrier s MMS store and forward server (MMSC) The MMSC determines if the recipient s device is MMS capable: Content is extracted and sent to a temporary HTTP enabled store An SMS control message containing the content s URL is sent The recipient s WAP browser opens and receives content from the URL If the device is not MMS capable (legacy experience): Content is delivered to a web based service URL is forwarded to the recipient as a standard SMS message Differences in device capability may require transcoding of content 38

39 Over-the-air programming (OTA) One of the main challenges of MMS is the number of handset parameters that need configuring. Bad configuration is often responsible for poor user experience Over-the-air programming (OTA) increasingly being used to set configuration parameters New software updates or configurations can be sent directly to the device from network operators Several Methods in use A call or SMS alerting the user to a new update. User then dials in (when convenient) triggering an automatic software update. SMS may be sent automatically due to a trigger; e.g. using a service for the first time, or after having signed up for a service Typically relies on the device possessing a provisioning client to set parameters. 39

40 Apple s imessage Announced at WWDC 2011 (June 6th 2011) Allows users to send texts, documents, photos, videos etc. Uses Wifi or mobile internet - not SMS/MMS & hence doesn t count against tariff limits on those Seamless experience for iphone users On 23rd Oct 2012, 300 billion messages had been sent - average of 28,000 per second By Feb 2016, 200,000 imessages per second As of 2017, 6.3 trillion messages are sent annually 40

41 Apple s imessage Based on Apple s Push Notification Service - proprietary binary protocol that sets up a keep-alive connection to Apple s Servers. Each connection has a unique code which acts to identify a route to a specific device. Connection is end-to-end encrypted with TLS using a client-side certificate, requested by device on the activation of imessage. 41

42 Apple s imessage On first use the phone creates two sets of private and public keys - one for encrypting data, the other for signing data Public keys are sent to Apple s servers. Private keys stored on device (Apple never sees them) When an imessage conversation starts, sender fetches your public key(s) from Apple s servers Message is encrypted before it leaves the sender s device. 42

43 Apple s imessage But what if you have multiple devices? Each device has a separate set of keys Private keys are not sent between devices. If you have two devices, then each message is encrypted and stored twice. When you retrieve an imessage it is encrypted for the device retrieving it Some minor data (timestamp and APN routing data is not encrypted) All data is encrypted as a package for transfer between device and servers. 43

44 Apple s imessage What about images/video etc? Lots of copies = very inefficient Apple keep one copy on icloud servers The sender s device generates a new random key, and a URI, cataloging where media is stored on servers Apple sends your device the key and URI (encrypted so only you can decrypt them) Your device pulls media from Apple s servers and displays it 44

45 Apple s imessage There are some security weaknesses that could be exploited The public keys to encrypt copies of the message are stored on Apple s key server. Relies on Apple being a good guy and really giving the sender the correct keys - User cannot check! Also, they could add a key to the key list that gets sent - could add the FBI s key (for example) 45

46 Apple s imessage Once message is retrieved, that copy is deleted from Apple s servers. If you have multiple devices, a further encrypted copy meant for each of those can sit on the server until it expires. Messages are kept for a maximum of 7 days. 46

47 EFF Secure Messaging Scorecard 47

48 EFF Secure Messaging Scorecard 48

49 To Recap... In this lecture set, we covered: Differences between Internet access from a PC over a fixed line vs a Mobile wireless device And how this affected early provision of mobile services Early approaches, which led to WAP The WAP stack, WML and Deck-of-Cards Other content delivery systems SMS, MMS and OTA, imessage 49

50 Further Reading M-Commerce Norman Sadeh (Wiley, 2009) Chapter 4 Pervasive Computing: The Mobile World Uwe Hansmann, Lothar Merk, Martin S. Nicklous, Thomas Stober (Springer Professional Computing, 2003) Chapter 11 Beyond 3G: Bringing Networks, Terminals, and the Web Together Martin Sauter (Wiley, 2009) Chapter 6 50