Presentation is loading. Please wait.

Presentation is loading. Please wait.

Mobile Computing Chapter 4 : Support for Mobility.

Similar presentations


Presentation on theme: "Mobile Computing Chapter 4 : Support for Mobility."— Presentation transcript:

1 Mobile Computing Chapter 4 : Support for Mobility

2 . In this Lecture, you will learn about basic concept of file systems and databases in mobile computing. Also we will discuss about WWW and WAP in mobile communication. By the end of this lecture, the students will be able to understand: File systems WWW and Mobility WAP - Wireless Application Protocol WTP-classes WSP WML, WML Script

3 File systems - Motivation
The general goal of a file system is to support efficient, transparent, and consistent access to files, no matter where the client requesting files or the server(s) offering files. Efficiency is of special importance for wireless systems as the bandwidth is low so the protocol overhead and updating operations etc. should be kept at a minimum. Transparency addresses the problems of location- dependent views on a file system. To support mobility, the file system should provide identical views on directories, file names, access rights etc., independent of the current location.

4 problems General problems are The limited resources on portable devices and the low bandwidth of the wireless access. File systems cannot rely on large caches in the end-system or perform many updates via the wireless link. Portable devices may also be disconnected for a longer period. Hardware and software components of portable devices often do not follow standard computer architectures or operating systems. Mobile phones, PDAs, and other devices have their own operating system, hardware, and application software. Portable devices are not as reliable as desktop systems or traditional file servers. Standard file systems like the network file system (NFS) are very inefficient and almost unusable in a mobile and wireless environment. The main problem is consistency of the copy with the original data.

5 some more problems and solutions regarding consistency
The basic problem for distributed file systems that allow replication of data for performance reasons is the consistency of replicated objects (files, parts of files, parts of a data structure etc.). To avoid inconsistencies many traditional systems apply mechanisms to maintain a permanent consistent view for all users of a file system. This strong consistency is achieved by atomic updates similar to database systems. Maintaining strong consistency is not only very expensive in terms of exchanging updates via the wireless link, but is also sometimes impossible.

6 . One solution is to forbid access to disconnected objects. This would prohibit any real application based on the file system. Mobile systems have to use a weak consistency model for file systems. Weak consistency implies certain periods of inconsistency that have to be tolerated for performance reasons. Reintegration is the process of merging objects from different users resulting in one consistent file system. A user could hold a copy of an object, disconnect from the network, change the object, and reconnect again. The changed object must then be reintegrated. A conflict may occur, e.g., if an object has been changed by two users working with two copies.

7 Little Work Little Work only requires changes to the cache manager of the client and detects write conflicts during reintegration. Little Work has no specific tools for reintegration and offers no transaction service. However, Little Work uses more client states to maintain consistency. Connected: This mode needs a continuous high bandwidth as available in typical office environments using, e.g., a WLAN. Partially connected: If a client has only a lower bandwidth connection, but still has the possibility to communicate continuously, it is referred to as partially connected. Fetch only: If the only network available offers connections on demand, the client goes into the fetch only state. Disconnected: Without any network, the client is disconnected.

8 Ficus Ficus is a distributed file system, which is not based on a client/server approach. Ficus allows the optimistic use of replicates, detects write conflicts, and solves conflicts on directories. Ficus tries to minimize the exchange of files that are valid only for a short time, e.g. temporary files. A critical issue for gossip protocols is how fast they propagate to the client that needs this information and how much unnecessary traffic it causes to propagate information to clients that are not interested.

9 MIo-NFS The system mobile integration of NFS (MIo–NFS) is an extension of the Network File System (NFS, (Guedes, 1995)). In contrast to many other systems, MIo-NFS uses a pessimistic approach with tokens controlling access to files. Only the token-holder for a specific file may change this file, so MIo- NFS avoids write conflicts. MIo-NFS supports three different modes: l Connected: The server handles all access to files as usual. l Loosely connected: Clients use local replicates, exchange tokens over the network, and update files via the network. l Disconnected: The client uses only local replicates. Writing is only allowed if the client is token-holder.

10 Rover Compared to Coda, the Rover platform uses another approach to support mobility (Joseph, 1997a and 1997b). Rover provides a platform for developing new, mobility aware applications. Two new components have been introduced in Rover. Re-locatable dynamic objects are objects that can be dynamically loaded into a client computer from a server (or vice-versa) to reduce client-server communication. Queued remote procedure calls allow for non-blocking RPCs even when a host is disconnected. Requests and responses are exchanged as soon as a connection is available again. Conflict resolution is done in the server and is application specific.

11 World wide web 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! 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! The first two subsections give short overviews of HTTP and HTML together with their problems in wireless environments. Some approaches to improve HTML and HTTP are presented, most of them proprietary. The last subsection introduces different system architectures used for web access, each trying to improve the classic client/server scenario.

12 Hypertext transfer protocol
The hypertext transfer protocol (HTTP) is a stateless, lightweight, application level protocol for data transfer between servers and clients. The first version, HTTP/1.0, never became a formal standard due to too many variant implementations. HTTP/1.1 is the standard currently used by most implementations. Krishnamurthy (1999) lists the key differences between the two versions. An HTTP transaction consists of an HTTP request issued by a client and an HTTP response from a server. Stateless means that all HTTP transactions are independent of each other. HTTP does not ‘remember’ any transaction, request, or response. This results in a very simple implementation without the need for complex state machines. A simple request might proceed as follows. GET requests the source following next, here / indicates the index file in the web root directory (index.html).

13 . HTTP (in particular version 1.0) causes many problems already in fixed networks but even more in wireless networks. Bandwidth and delay: HTTP has not been designed with low bandwidth/high delay connections in mind. The original environment has been networked with workstations running TCP/IP over wired networks with some Mbit/s bandwidth. HTTP protocol headers are quite large and redundant. Many information fields are transferred repeatedly with each request because HTTP is stateless. Caching: Although useful in many cases, caching is quite often disabled by content providers. Many companies want to place advertisements on web pages and need feedback, e.g., through the number of clicks on a page to estimate the number of potential customers. POSTing: Sending content from a client to a server can cause additional problems if the client is currently disconnected. The POST request cannot be fulfilled in a disconnected state, so a server could be simulated by accepting the posting via an additional process.

14 Hypertext markup language
HTML is broadly used to describe the content of web pages in the world wide web. No matter which version is used, they all share common properties. HTML was designed for standard desktop computers connected to the internet with a fixed wire. These computers share common properties, such as a relatively high performance (especially when compared to handheld devices), a color high-resolution display (24 bit true color, 1,200 × 1,024 pixels is standard), mouse, sound system, and large hard disks. Web pages using the current HTML often ignore these differences in end systems. Pages are designed primarily for a nice presentation of content, not for efficient transfer of this content. HTML itself offers almost no way of optimizing pages for different clients or different transmission technologies.

15 Cont.… However, HTML is not the biggest problem when accessing web pages from wireless handheld clients. Almost all of today’s web pages, especially those of companies, are ‘enriched’ with special ‘features’, some using HTML, some not. These features include animated GIFs, Java Applets, Frames, ActiveX controls, multi-media content following different proprietary formats etc. The approaches using content distillation or semantic compression might work with HTML, but those many additional plug-ins each need their own mechanism to translate them into a useful format for a wireless device with limited capabilities.

16 Some approaches that might help wireless access
The problems with HTTP and HTML are well known and have encouraged many different proprietary and standardized solutions (or better partial solutions). Some of the efforts are: Image scaling: If a page contains a true color, high-resolution picture, this picture can be scaled down to fewer colors, lower resolution, or to just the title of the picture. The user can then decide to download the picture separately. Clipping, zooming, or detail studies can be offered to users if they are interested in a part of the picture. Content transformation: Many documents are only available in certain formats, e.g. Postscript or portable document format (PDF). Before transmitting such documents to a client without the appropriate reader, a special converter could translate this document into plain text

17 Cont….. Content extraction/semantic compression: Besides transforming the content, e.g., headlines or keywords could be extracted from a document and presented to a user. The user could then decide to download more information relating to a certain headline or keyword. An abstract from some given text could be automatically generated. Extracting headlines is simpler, but sometimes useless if HTML headlines are used for layout purposes and not for structuring a document. Special languages and protocols: Other approaches try to replace HTML and HTTP with other languages and protocols better adapted to a wireless environment. Early examples are the handheld device transport protocol (HDTP) and the handheld device markup language (HDML) from Unwired Planet. Push technologies: Instead of pulling content from a server, the server could also push content to a client. This avoids the overhead of setting up connections for each item, but is only useful for some content, e.g. news, weather information, road conditions, where users do not have to interact much.

18 System architecture The classic underlying system architecture of the www is a client/server system. The client, a web browser running as an application on a computer, requests content from a server, the web server running on another computer. Caching is a major topic in the web client/server scenario. While caching is also useful for wired computers because it reduces the delay of displaying previously accessed pages, it is the only way of supporting (partially) disconnected web browsers. The first enhancement was the integration of caching into web browsers. This is standard for all of today’s browsers (e.g. Netscape, (2002), Microsoft, (2002)). Figure 10.3 shows a mobile client with a web browser running. A user can then go “offline” and still browse through the cached content (pages, pictures, multi-media objects etc.). The typical enhancements for web browsing act as a transparent proxy as shown in Figure The browser accesses the web server through the client proxy, i.e., the proxy acts as server for the browser and as client for the web server.

19 The proxy can now pre-fetch and cache content according to many strategies. As soon as the client is disconnected, the proxy serves the content. Many approaches follow this scheme which is independent of the browser so allows other developments.

20 A proxy can also support a mobile client on the network side (see Figure 10.6). This network proxy can perform adaptive content transformation (e.g., semantic compression, headline extraction etc) or pre-fetch and cache content. The benefits of client and network proxies can be combined, which results in a system architecture as illustrated in Figure 10.7.

21 . You can even go one step further and implement a specialized network subsystem as shown in Figure 10.8. This solution has the same benefits as the previous one but now, content transfer can be further optimized. Many other enhancements are possible. Examples are server extensions to provide content especially suited for wireless access and mobile, hand held clients.

22 Wireless application protocol (version 1.x)
The growth of the internet, internet applications, and mobile communications led to many early proprietary solutions providing internet services for mobile, wireless devices. Some of the problems these partial solutions face were discussed earlier because the world wide web is the most important and fastest growing internet application. To avoid many islands of incompatible solutions, e.g. special solutions for GSM, IS-136, or certain manufacturers, the wireless application protocol forum (WAP Forum) was founded. As this section describes version 1.x of WAP and the standards are still known as WAP Forum standards, this name was kept throughout the description of WAP. The basic objectives of the WAP Forum and now of the OMA are to bring diverse internet content (e.g., web pages, push services) and other data services (e.g., stock quotes) to digital cellular phones and other wireless, mobile terminals (e.g., PDAs, laptops). A protocol suite should enable global wireless communication across different wireless network technologies, e.g., GSM, CDPD, UMTS etc.

23 Cont.…. The forum is embracing and extending existing standards and technologies of the internet wherever possible and is creating a framework for the development of contents and applications that scale across a very wide range of wireless bearer networks and wireless device types. All solutions must be: interoperable, i.e., allowing terminals and software from different vendors to communicate with networks from different providers; scalable, i.e., protocols and services should scale with customer needs and number of customers; efficient, i.e., provision of QoS suited to the characteristics of the wireless and mobile networks; reliable, i.e., provision of a consistent and predictable platform for deploying services; and secure, i.e., preservation of the integrity of user data, protection of devices and services from security problems.

24 WAP 1.x Architecture The basis for transmission of data is formed by different bearer services. WAP does not specify bearer services, but uses existing data services and will integrate further services. No special interface has been specified between the bearer service and the next higher layer.

25 Cont.…. The transport layer with its wireless datagram protocol (WDP) and the additional wireless control message protocol (WCMP), because the adaptation of these protocols are bearer-specific The next higher layer, the security layer with its wireless transport layer security protocol WTLS offers its service at the security SAP (SEC-SAP). The WAP transaction layer with its wireless transaction protocol (WTP) offers a lightweight transaction service at the transaction SAP (TR-SAP). This service efficiently provides reliable or unreliable requests and asynchronous Transactions. The session layer with the wireless session protocol (WSP) currently offers two services at the session-SAP (S-SAP), one connection-oriented and one connectionless if used directly on top of WDP.

26 . Finally the application layer with the wireless application environment (WAE) offers a framework for the integration of different www and mobile telephony applications.

27 Wireless datagram protocol
The wireless datagram protocol (WDP) operates on top of many different bearer services capable of carrying data. At the T-SAP WDP offers a consistent datagram transport service independent of the underlying bearer. To offer this consistent service, the adaptation needed in the transport layer can differ depending on the services of the bearer. The closer the bearer service is to IP, the smaller the adaptation can be. If the bearer already offers IP services, UDP is used as WDP. WDP offers more or less the same services as UDP. WDP offers source and destination port numbers used for multiplexing and demultiplexing of data respectively. The service primitive to send a datagram is TDUnitdata.req with the destination address (DA), destination port (DP), Source address (SA), source port (SP), and user data (UD) as mandatory parameters (see Figure 10.11).

28 Cont.…. Destination and source address are unique addresses for the receiver and sender of the user data. These could be MSISDNs (i.e., a telephone number), IP addresses, or any other unique identifiers. The T-DUnitdata.ind service primitive indicates the reception of data. Here destination address and port are only optional parameters. .

29 Wireless transport layer security
If requested by an application, a security service, the wireless transport layer security (WTLS), can be integrated into the WAP architecture on top of WDP as specified in WAP Forum. WTLS can provide different levels of security (for privacy, data integrity, and authentication) and has been optimized for low bandwidth, high-delay bearer networks. WTLS takes into account the low processing power and very limited memory capacity of the mobile devices for cryptographic algorithms. WTLS supports datagram and connection-oriented transport layer protocols. New compared to, e.g. GSM, is the security relation between two peers and not only between the mobile device and the base station WTLS took over many features and mechanisms from TLS (formerly SSL, secure sockets layer (Dierks, 1999)), but it has an optimized handshaking between the peers.

30 .

31 Cont.… Before data can be exchanged via WTLS, a secure session has to be established. This session establishment consists of several steps: Figure illustrates the sequence of service primitives needed for a so-called ‘full handshake’ (several optimizations are possible). The first step is to initiate the session with the SEC-Create primitive. Parameters are source address (SA), source port (SP) of the originator, destination address (DA), destination port (DP) of the peer. The peer answers with parameters for the sequence number mode (SNM), the key refresh cycle (KR) (i.e., how often keys are refreshed within this secure session),the session identifier (SID) (which is unique with each peer), and the selected key exchange suite (KES’), cipher suite (CS’), compression method (CM’). The first step of the secure session creation, the negotiation of the security parameters and suites, is indicated on the originator’s side, followed by the request for a certificate.

32 Cont.…. After setting up a secure connection between two peers, user data can be exchanged. This is done using the simple SEC-Unitdata primitive as shown in Figure SEC-Unitdata has exactly the same function as T-DUnitdata on the WDP layer, namely it transfers a datagram between a sender and a receiver. The higher layers simply use SEC-Unitdata instead of T-DUnitdata. The parameters are the same here: source address (SA), source port (SP), destination address (DA), destination port (DP), and user data (UD). Although WTLS allows for different encryption mechanisms with different key lengths, it is quite clear that due to computing power on the hand held devices the encryption provided cannot be very strong. If applications require stronger security, it is up to an application or a user to apply stronger encryption on top of the whole protocol stack and use WTLS as a basic security level only.

33 Wireless transaction protocol
The wireless transaction protocol (WTP) is on top of either WDP or, if security is required, WTLS. WTP has been designed to run on very thin clients, such as mobile phones. WTP offers several advantages to higher layers, including an improved reliability over datagram services, improved efficiency over connection-oriented services, and support for transaction- oriented services such as web browsing. In this context, a transaction is defined as a request with its response, e.g. for a web page.WTP offers many features to the higher layers. The basis is formed from three classes of transaction service as explained in the following paragraphs. Class 0 provides unreliable message transfer without any result message. Classes 1 and 2 provide reliable message transfer, class 1 without, class 2 with, exactly one reliable result message (the typical request/response case). WTP achieves reliability using duplicate removal, retransmission, acknowledgements and unique transaction identifiers. No WTP-class requires any connection set-up or tear-down phase.

34 Cont.…. This avoids unnecessary overhead on the communication link.
WTP allows for asynchronous transactions, abort of transactions, concatenation of messages, and can report success or failure of reliable messages (e.g., a server cannot handle the request). To be consistent with the specification, in the following the term initiator is used for a WTP entity initiating a transaction (aka client), and the term responder for the WTP entity responding to a transaction (aka server). A special feature of WTP is its ability to provide a user acknowledgement or, alternatively, an automatic acknowledgement by the WTP entity. If user acknowledgement is required, a WTP user has to confirm every message received by a WTP entity.

35 .

36

37 Wireless session protocol
The wireless session protocol (WSP) has been designed to operate on top of the datagram service WDP or the transaction service WTP. For both types, security can be inserted using the WTLS security layer if required. WSP provides a shared state between a client and a server to optimize content transfer. WSP tries to replace within the wireless domain, is stateless, which already causes many problems in fixed networks State is needed in web browsing, for example, to resume browsing in exactly the same context in which browsing has been suspended. Client users can continue to work where they left the browser or when the network was interrupted, or users can get their customized environment every time they start the browser. WSP offers the following general features needed for content exchange between cooperating clients and servers:

38 Cont.… Session management: WSP introduces sessions that can be established from a client to a server and may be long lived. Sessions can also be released in an orderly manner. The capabilities of suspending and resuming a session are important to mobile applications. Assume a mobile device is being switched off – it would be useful for a user to be able to continue operation at exactly the point where the device was switched off. Capability negotiation: Clients and servers can agree upon a common level of protocol functionality during session establishment. Example parameters to negotiate are maximum client SDU size, maximum outstanding requests, protocol options, and server SDU size. Content encoding: WSP also defines the efficient binary encoding for the content it transfers. WSP offers content typing and composite objects, as explained for web browsing.

39 Wireless application environment
The main idea behind the wireless application environment (WAE) is to create a general-purpose application environment based mainly on existing technologies and philosophies of the world wide web. This environment should allow service providers, software manufacturers, or hardware vendors to integrate their applications so they can reach a wide variety of different wireless platforms in an efficient way. WAE does not dictate or assume any specific man-machine-interface model, but allows for a variety of devices, each with its own capabilities and probably vendor-specific extras. WAE has already integrated the following technologies and adapted them for use in a wireless environment with low power hand held devices. HTML, JavaScript, and the handheld device markup language HDML form the basis of the wireless markup language (WML) and the scripting language WMLscript. WAE focuses on devices with very limited capabilities, narrow-band environments, and special security and access control features.

40 The first phase of the WAE specification developed a whole application suite, especially for wireless clients as presented in the following sections. Future developments for the WAE will include extensions for more content formats, integration of further existing or emerging technologies, more server-side aspects, and the integration of intelligent telephone networks. One global goal of the WAE is to minimize over-the-air traffic and resource consumption on the handheld device. This goal is also reflected in the logical model underlying WAE (Figure 10.29)

41 WAP 2.0 It can be stated that WAP 2.0 is roughly the sum of WAP 1.x, i-mode, Internet protocols, and many mobility specific enhancements. WAP 2.0 continues to support WAP 1.x protocols, but additionally integrates IP, TCP (with a wireless profile), TLS, and HTTP (wireless profiled). WAP 2.0 browsers support. WML as well as XHTML with a mobile profile (XHTMLMP). XHTML is the extensible hypertext mark-up language developed by the W3C (2002) to replace and enhance the currently used HTML. The protocol framework consists of the following four components: Bearer networks: Similar to WAP 1.x, many bearers are supported. Typical bearers today are GPRS in GSM networks, SMS for push services. Third generation networks will directly offer IP services. Transport services: These services offer an end-to-end abstraction on top of different bearers. Transport services can be either connection-oriented or connectionless. For reliable, connection-oriented services TCP with a wireless profile can be used. WDP or UDP (in case of an IP bearer) can be used for unreliable, connectionless (datagram) services.

42 Transfer services: Examples for transfer protocols are a wireless profiled HTTP, the combination of WTP/WSP, streaming protocols, and message transfer protocols. The multimedia messaging service (MMS) transfers asynchronous multi-media content (WAP Forum, 2001d). MMS supports different media types, such as JPEG, GIF, text, and AMR coded audio. There is no fixed upper bound for the message size. Depending on the network operator and device capabilities, typical sizes are 30–100 k byte. MMS is already offered by many providers. Session services: Mobile devices need a shared state between network elements to operate efficiently. CC/PP can be used for capability negotiation. This includes information about client, server, and proxy capabilities, and allows for customization of content. The push OTA service offers reliable and unreliable push services. Finally, a synchronization service has been defined for synchronizing replicated data. .

43

44


Download ppt "Mobile Computing Chapter 4 : Support for Mobility."

Similar presentations


Ads by Google