Two approaches for an adaptive multimedia transfer service for mobile environments

qThis is an extended version of an article presented at theInteractive Applications of Mobile Computing Workshop,IMC'98, Rostock, Germany.

*Corresponding author. Tel.: #49-351-463-8063; fax.: #49-351-463-8251.

E-mail address: [email protected] (T. Ziegert)

Computers & Graphics 23 (1999) 849}856

IMC '98

Two approaches for an adaptive multimedia transfer servicefor mobile environmentsq

Alexander Schill, Sascha KuK mmel, Thomas Springer, Thomas Ziegert*

Department of Computer Science, Institute for Operating Systems, Databases, and Computer Networks, Dresden University of Technology,D-01062 Dresden, Germany

Abstract

Mobile environments are characterized by varying locations and network access points of end users, by varying levelsof network QoS and often also by limited connectivity and reliability. These aspects have to be considered speci"cally fordistributed multimedia applications, typically involving large amounts of data and speci"c QoS requirements. Thisarticle presents concepts and experiences concerning adaptive services for asynchronous multimedia transmission inmobile environments. We describe two di!erent approaches to solve the problems of adaptation to variable network QoSusing generic mechanisms. The "rst approach takes advantage of a mobile queuing service and is based on our formerwork on a support platform for mobile computing (see Schill and KuK mmel. Mobile Computing Special Issue ofDistributed Systems Engineering Journal 1995; 128}41; Schill et al. Proceedings of IMC 96 Workshop on InformationVisualization and Mobile Computing. Zentrum fuK r graphische Datenverarbeitung, February 1996). The second ap-proach uses the mobile agent paradigm in the context of an application partitioning model to gain #exibility andmaintainability (see Schill et al. In: Papaioannou, Minar, editors, Proceedings. Mobile Agents in the Context ofCompetition and Cooperation (MAC3), a workshop at Autonomous Agents '99, 1999. p. 34}41.). Both approachesexploit software-based conversion to adapt multimedia data according to bandwidth availability. Decoupling ofcommunication peers with automatic noti"cations about communication actions helps to address disconnectionproblems. ( 1999 Elsevier Science Ltd. All rights reserved.

1. Introduction and motivation

During the recent years, it has been widely recognizedthat distributed applications in mobile environments re-quire speci"c system support (see [1}7]). Major newproblems are user and host mobility, dynamic discon-

nection, and varying network QoS. A typical applicationscenario of a mobile sales force might include the follow-ing steps: A sales engineer is connected to a LAN envi-ronment (e.g. using a 10 or 100 Mbit/s Ethernet) usinga docking station and has full access to multimediaproduct catalogs, supporting an e$cient caching of rel-evant data [8]. Subsequently, the user is on the roadwithout network access; important messages and noti"-cations between the company and the user have to bequeued for later retrieval. In urgent cases, a wireless link,e.g. based on GSM, can be established. This enables theaccess to important additional information with limiteddata rate (typically with 9.6 kbit/s) and high latency.Large multimedia data objects either have to be excludedfrom transmission or have at least to be converted based

0097-8493/99/$ - see front matter ( 1999 Elsevier Science Ltd. All rights reserved.PII: S 0 0 9 7 - 8 4 9 3 ( 9 9 ) 0 0 1 1 5 - 6

Fig. 1. Basic structure of the adaptive multimedia transfer service.

on lossy compression techniques. Later on, the usermight connect again to a LAN in a branch or customero$ce, possibly with X.25 or frame relay access to themain o$ce (i.e. with a data rate between 9.6 kbit/s andseveral Mbit/s, depending on the infrastructure). Therequired adaptability concerning the transmission ofmultimedia objects can be implemented within the ap-plication (such as a multimedia mail tool, an advanced"le transfer mechanism or a remote database accessmechanism). However, the introduction of a generic ser-vice respectively component for an adaptive multimediatransfer enables increased reusability across applicationsand supports the exploitation of services for partiallyautomating the described conversion mechanisms andthe required bandwidth management.

In the remainder of this article we present two di!erentapproaches providing means for the adaptation of multi-media data according to the currently available QoS-parameters of the network connection. Sections 2 and 3describe the basic structure and operation of both servi-ces as well as the evaluation of the developed mechanismsand experiences we made. Section 4 provides concludingremarks.

2. A mobile queuing service

2.1. Basic structure and operation

Fig. 1 shows the basic structure and components of themobile queuing service. An application with the need forasynchronous transfer of multimedia objects accesses thetransfer service via a speci"c client-site API. Withoutconnectivity, data are "rst queued at the sending site.Otherwise, a speci"c component called application datamobilizer and manager (ADMM) is contacted (1). Itcalculates the route to the destination by employing

mechanisms for locating mobile users. It is also possibleto cache a mobility pro"le of the destination user and totransfer information to several most likely locations. Thismakes sense if user mobility follows a relatively regularschedule, and if the target user cannot be currentlylocated due to disconnection. The ADMM can be con-tacted by each intermediate transmission server, forexample for dynamic adaptation of the preselected rout-ing path (2). The connections between the transmissionservers and between the last server and the end systemwith the target application are evaluated by a bandwidthand cost management (BCM) component (3). This com-ponent performs regular tests for network connectivityand measures roundtrip times and throughput. More-over, it can make use of con"guration information ofnetwork management tools. According to the results,a decision is made whether large-volume multimediadata can be transmitted in their original form or whethera conversion based on compression techniques is advis-able. To guide this decision, all data objects are taggedwith their media type and format information. In addi-tion, it might be reasonable to specify rules concerningthe allowed degree of information loss caused by com-pression (for example the required minimum qualitylevel, see Section 3), although this is not supported by theimplementation. If a conversion is required, media ob-jects are passed to the conversion service (CVS) (4) andare enqueued again based on a modi"ed representation(5). Eventually, the target application dequeues the re-ceived data (6). If it was temporarily disconnected, it isbeing noti"ed about the availability of information uponreconnection. Multimedia data transfer is reliable basedon persistent storage of received information. The servicenoti"es registered applications upon data arrival or whena dequeuing operation at a remote site completes. As-suming a long time between the enqueue and dequeueoperations, there is a high likelihood that the sending

850 A. Schill et al. / Computers & Graphics 23 (1999) 849}856

Fig. 2. User-driven selection of conversion parameters.

1A "rst attempt is the OMG CORBA Telecoms Speci"cation(see [13]) which de"nes the so-called streams and enables ap-plications to specify their QoS requirements.

application has already gone. Therefore, applications canspecify a reply-box "le. The system will log any reportsabout successful arrivals or failures during delivery (time-outs) in that "le. A garbage collection mechanism basedon a lifetime control of data objects is part of the system.Security requirements are met by tagging data objectswith security classes; this supports the use of appropriateencryption mechanisms if required by the application.Related ideas can be found in [9] (focusing on band-width-related adaptation in mobile systems), [10](o!ering multimedia conversion mechanisms for datareduction), [11] (implementing mobile multimedia dataaccess from an InfoPad), or [12] (focusing on asyn-chronous interactions), for example.

2.2. Evaluation and use of the mechanisms byan application

The generic multimedia transmission service has beenused to implement multimedia mail applications basedon Internet and X.400 protocols. Moreover, it can also beused as an advanced transport mechanism for "le trans-fer or for multimedia database or WWW access in mobileenvironments. With multimedia mail, user agents (UA)access the transfer service which acts as a speci"c kind ofmessage store (MS). The transfer service on the mobilehost provides a send queue for bu!ering information tobe sent in case of disconnections. Transfer and "nalaccess of multimedia attachments is done in an adaptiveway based on the conversions discussed above. As anexample, possible conversions for image "les are shownin Fig. 2. The selection can be made by the user in thecase of multimedia mail access from an end system.Therefore, the user selects the conversion parameters forevery multimedial message part he wishes to transfer tohis mobile computer. Alternatively, an automatic conver-sion within the message transfer system is also possible.

Di!erent performance measurements were done withthis implementation. The hardware platform consistedof a Pentium 133 under Windows NT (64 Mbyte mainmemory), connected with a Pentium 120 Notebook (40Mbyte main memory) via a GSM connection (9.6 kbit/s).Dedicated application data were transmitted as mailattachments. A message consists of a text component(size: 5238 byte), a JPEG image (size: 289463 byte), anda wave-encoded audio "le (size: 132356 byte, based ona frequency of 44 kHz and a sampling width of 16 bitwith two channels). In the experiment, the image qualitywas reduced to a value of 25% of the original quality,leading to a reduction of the data size of the JPEG "ledown to 25055 byte (or less than 10% of the original size).The audio encoding was modi"ed to a sampling fre-quency of 11 kHz with a sampling width of 8 bit and onlyone channel; this led to an audio "le size of 8269 byte.This way, the total transmission time was reduced to 93 s(from 646 s), while still yielding an acceptable quality ofthe attachments from an application point of view.

2.3. Experiences and discussion

In summary, the experiments with the presented mech-anism have shown that generic, application-independentsupport for asynchronous adaptive multimedia transferis a reasonable component of mobile computing environ-ments. It enables data reduction and handles discon-nections. Based on a well-speci"ed API to the supportingservices, the implementation of mobile applications canbe supported well. This requires evaluation of networkcharacteristics, explicit speci"cation of multimedia datatypes, and user-driven decisions about actual conver-sions. Therefore, both network management informationfrom the underlying environment as well as informationabout user preferences from the application on top of thegeneric service are required. This also means that distri-bution transparency * a major goal of current middle-ware such as CORBA or Java RMI*must be relaxed tosome degree; at least, the user must be aware of band-width and quality of service limitations and must specifyassociated parameters.1 The queuing mechanisms wereimplemented on top of an RPC system (Microsoft RPC,similar to DCE RPC). Other transport mechanisms arealso possible, maintaining the same application-level in-terfaces and the same additional services. For example,a more reliable transport service based on distributedtransactions could be integrated relatively easy. Thesynchronous mechanisms o!ered by RPC have disad-vantages with long delays as they exist in mobile com-munication systems. In related implementations, we have

A. Schill et al. / Computers & Graphics 23 (1999) 849}856 851

Fig. 3. The generic partitioning model.

shown that these problems can be handled by splittinglengthy messages into several RPCs which will be in-voked in parallel. In contrast to traditional parallel com-puting applications, however, we mainly make use ofparallel transmission. Computing and modi"cation ofmessages at the destination system, on the other hand,remains sequential. The generic services discussed aboveshould be o!ered as a set of loosely coupled componentsrather than as a static, layered support platform. Invarious applications, not all components are really neces-sary or can be simpli"ed* for example the cost manage-ment or the conversion service. Furthermore, thecomponents of the service have to be installed andstarted on any computer they should be accessible from.

The described mobile queuing service handles adapta-tion according to media type and format. There are nomeans for context or semantic-based data reduction. Theinformation about the temporal importance of multi-media data is only available at the application level orfrom the user itself. Components doing this semanticreduction should be dynamically manageable from themobile host. They are part of a speci"c application buthave a transient role. It should be possible to dynam-ically invoke them when needed, as well as this should bethe case for the components for data conversion.

These experiences and the requirement of #exibility letto the development of the second approach using anapplication partitioning model based on mobile agentswhich will be discussed in the remainder of this article.

3. An application partitioning model

3.1. Basic structure and operation

The partitioning model described in this section usesmobile agents as application components. This enablesthe dynamic placement of components during runtimeand therefore facilitates more #exibility in con"guringthe service. An application is split into two pairs ofcomponents which contain generic and application re-lated functions (see Fig. 3). The pair of generic compo-nents acts as a proxy for the mobile device. The genericproxy mediates the transfer of multimedia data betweenapplication components over a link with changing qual-ity parameters. While the other components exist perapplication, these two only exist per mobile device, thusthey are used by all applications of a mobile device.

We extended the approach of a single proxy whichimplements techniques to improve the behavior of ap-plications in a mobile environment. Such techniques arecaching, prefetching (disconnected operations [14,15])and queuing to handle frequent disconnections and "lter-ing, compression and conversion to reduce the amount ofdata transferred over low bandwidth links. We dividedthese techniques into generic and application speci"cfunctions which have to be placed on the mobile deviceor within the wired network. The used criteria wererestrictions to the placement of the code and the avail-ability of information to apply the techniques e$ciently.


Caching, prefetching and lazy write-back are carried outby the application-related component on the mobile de-vice because these techniques use information which isonly available at application level to work e!ectively.Caching and lazy write-back can also be applied ina more generic fashion and therefore be carried out bythe generic component. Compression and conversiondepend only on the data type and are generic. Queuingimproves the disconnection handling of all applicationsin common. Data can be "ltered using application re-lated information. Therefore "ltering is done by the ap-plication-related component within the wired network.Packets can also be "ltered using their routing informa-tion (e. g. source and target and priority) which is com-mon for all applications. Lazy evaluation and outlinesdepend on information available at application level.Related work can be found in [9,10,16,17].

In our concept the application-related components areintentionally independent from the generic proxy. Thatmeans that all application components are also able tocommunicate without the generic proxy. This is useful ifa high bandwidth connection to the mobile device isavailable. It is possible to dynamically bind and unbindapplication components to the generic proxy accordingto changes in the execution environment and user needs.The proxy includes functions similar to the queuing ser-vice. Incoming data objects are inserted into a queue forfurther processing. The data objects remain in the queueuntil the transfer is possible. Selected data objects areautomatically adapted to the available bandwidth bycompressing and converting these according to the datatype. To optimize the data transfer over di!erent com-munication media special protocols are applicable. Forinstance multiple parallel send threads can be used forcommunication media with high delay times resulting ina better exploitation of the available bandwidth. If a gen-eric component receives a data object from its twin com-ponent so it will mediate it according to the includedtarget information. All data is encapsulated in an uni-form data container which consists of a description of theincluded data and the data itself. The description con-tains routing information, data type, two ids to identifydata streams and packets within a stream and informa-tion how the packet should be handled by the genericproxy. This allows each application to con"gure thehandling of its data itself. For instance an application candetermine if a data object should be compressed andwhich minimal quality is tolerable for the compression.The data in the container is presented by an object fora special data type. Therefore, one class for each datatype is needed. All data type classes have to implementa special interface which allows the generic handling ofall data. The interface contains methods for reading thetype of the data, to get a byte stream or a special Javaobject for the data and to reduce for example the qualityof a picture to a given value. Currently, we only support

the compression of JPEG images. Therefore, we use theJPEG codec of the JDK1.2 beta 4 [18] version. Theseclasses are now included in the Java advanced imagingpackage [19]. It is possible to introduce new data typesto the system without changing the generic proxy. Be-cause of the use of RMI these classes have to be loadedfrom a web server by the application using the RMI classloader. If an object of a loaded class is sent as a parameterin a RMI call the class is loaded automatically into thevirtual machine of the called object if it is not availablelocally.

Each agent contains a method to receive data objects.This method is similar for all agents (for details see [20]).The queuing mechanism is not determined in the model.Currently, we use a priority queue in our prototypeapplication. Therefore, the user can specify a priority foreach application according to time constraints concern-ing the delivery of their messages. Each message is as-signed with a priority belonging to its application beforeit is enqueued. Other queuing mechanisms are applic-able. The priority could also be determined by the ap-plication itself according to the position of data withina data structure. Also multiple queues (e.g. one for eachpriority) could be used.

3.2. Evaluation and use of the mechanisms byan application

To validate the model described above we imple-mented a multimedia e-mail application. Fig. 4 shows theapplication components. As email client we use the Net-scape Communicator Mail component. Received mailsare saved in a "le and can be read with the mail client asusual. The application-related component on the mobiledevice provides a user interface to con"gure and controlall application components (agents) and to input "lterdata and the information required to access the emailaccount. The application-speci"c component in the wirednetwork is called email agent. It migrates to the mailserver or a host close to this server. Once there it will askfor new messages using the information for the emailaccount. New messages are "ltered in two ways using theheader information (e.g. sender, receiver or subject) andinformation in the body (e.g. body text or attachmentdata type and size). The "lter information is de"ned bythe user. Only messages which match at least one header"lter are delivered. The attachment "lters are appliedbefore the transfer. Only data types speci"ed in the "lterare sent. The attachments must not be larger than thethreshold assigned to a data type. The "ltered messagesare sent as a sequence of data objects to the generic proxycomponent in the wired network. Within the genericproxy incoming data objects are enqueued as describedbefore. If an object can be sent to the mobile device one ofthe enqueued packets is dequeued according to the usedqueuing mechanism. The amount of data can be adapted


Fig. 4. Agent-based e-mail application.

Table 1Message transfer times in ms

100 VG AnyLAN Ethernet Xircom Netwave wirelessLAN

With generic proxy Low quality 180.0 179.2 444.7High quality 190.8 189.1 809.6

Without generic proxy Low quality 55.5 57.3 378.3High quality 58.8 72.1 774.4

to the available bandwidth before the transfer takesplace. Therefore, conversion and lossy compression ac-cording to the type of data is applied. The degree of thedata loss is con"gurable. The user de"nes the type of datawhich should be compressed and the new quality(in percent) of the modi"ed data. This information isapplied to all data objects mediated by the generic proxyproviding automatic compression.

The implementation is based on the ObjectSpaceVoyager core technology API [21] and the JDK 1.2 [18].The communication between agents is based on the RMImechanism of Java. For further details see [22].Table 1 shows the transfer times of messages with andwithout the indirection over the proxy agent. We conduc-ted our measurements for 100 VG AnyLAN on two200 MHz Pentium Pro, 64 MB RAM workstationsrunning WindowsNT and for Ethernet and the wirelessLAN on a ThinkPad 760D (Pentium 166 MHz, 64 MBRAM) running Windows95 and one of the workstationsmentioned. The values are average times over 500 runs.We transferred an email containing a JPEG picturewith a size of 12204 bytes in high and 4439 bytes lowquality. The decoding and encoding needs an average of135.6 ms altogether. The values for 100VGAnyLAN andEthernet are highly in#uenced by the serialization/deserialization times. The use of the proxy components

only is advantageous for disconnection handling. Usingthe wireless LAN, the transfer time of the compresseddata is signi"cantly lower than the times for transferringuncompressed data. The indirection over the genericproxy takes also some time but the bene"t for discon-nection handling and adaptation justi"es this e!ort.

That means the user speci"es the handling of data ina higher level than in the queuing service. There is noneed to decide how to compress each data object whichshould be transferred to the mobile host. Because of theability of all components to move this approach is more#exible.

3.3. Experiences and discussion

The generic proxy provides a robust software compon-ent to adapt data transfer which can be used by allapplications of a mobile device. The data handling re-mains individually con"gurable for each application. Be-cause of the de"ned and limited functionality of thegeneric proxy, this component is small compared to theapplication-related components. This reduces the e!ortnecessary after the movement of the mobile device. Onlythe generic proxy has to be moved. This decouples theapplication-related parts from the movement of the mo-bile device. Therefore, own migration strategies can be


applied, which includes the migration to a server near themost probable next location of a mobile user. An impor-tant fact is the use of mobile agents as application com-ponents which facilitates a dynamic placement ofapplication parts and the dynamic placement of theproxy during runtime. The capability of migration isperformed by the agent system. The agent system alsoprovides other services (e.g. naming and locating,security) which can be used by all applications.Mobile application components can be sent to hosts onthe wired network side and are able to continue theirwork, even if the connection to the mobile host is closed.The results of this autonomous operation will be de-livered, when a new connection to the mobile device isestablished. To enable the adaptation to the executionenvironment, the environment has to be sensed by thecomponents. Therefore the agent system must provideadditional services for instance to observe the quality ofnetwork connections. By using an agent system based onJava the proxy can be used on any platform whichprovides a Java virtual machine. Only the availability ofthe agent system and the class "les are special require-ments in our approach.

4. Conclusions

This article has presented two approaches for an adap-tive multimedia transfer service and has illustrated theiruse within the context of a mobile application. The servi-ces have been implemented completely and have beenevaluated concerning its performance aspects.

Based on a selective con"guration of the componentsnecessary for a speci"c application, the overhead andcode size * especially on the mobile system * can bereduced. Another observation is that performancetradeo!s must be evaluated carefully for optimizing suchadaptive mechanisms. As illustrated above, media con-version times for software-based conversions can alsobecome rather signi"cant and can only be justi"ed ifbandwidth variation among di!erent network accesspoints is relatively high (as in the case of GSM or WLANvs. Ethernet). The presented mechanisms can be appliedto digital images and to attached video "les in a rathersimilar way using JPEG or MPEG compression tech-niques. However, the performance tradeo!s have to beevaluated separately. Time-dependent live video or audiotransmission has not been considered within our experi-ments as the services are targeted at asynchronouscommunication. However, conversion of video wasimplemented in the context of other related projectswithin our research group. Some of the results might betransferable into the mobile computing domain, but itwill hardly be possible to provide QoS guarantees in thenear future.

References

[1] Athan A, Duchamp D. Agent-mediated message passingfor constrained environments. In: USENIX Association,editor. Proceedings of the USENIX Mobile and Location* Independent Computing Symposium: August 2}3,1993, Cambridge, MA, USA, Berkeley, CA, USA, August1993. p. 103}7 USENIX.

[2] Bakre A, Badrinath BR. M-RPC: a remote procedure callservice for mobile clients. In: Proceedings of the FirstACM International Conference on Mobile Computingand Networking MobiCom'95, November 1995, p. 2}11.

[3] Balakrishnan H, Amir E, Katz RH. Improving TCP/IP* performance over wireless networks. In: Proceedingsof the First ACM International Conference on MobileComputing and Networking MobiCom'95, November1995, p. 124}31.

[4] Davies N, Pink S, Blair GS. Services to support distributedapplications in a mobile environment. In: First Inter-national Workshop on Services in Distributed and Net-worked Environments, Prague, Republique Tcheque, June1994.

[5] Imielinski T, Badrinath BR, Wireless mobile computing:Solutions and challenges in data management. TechnicalReport DCS-TR-296, Department of Computer Science,Rutgers University, New Brunswick, NJ 08903, 1993.

[6] Satyanarayanan M. Fundamental challenges in mobilecomputing. In: Fifteenth ACM Symposium on Principlesof Distributed Computing, Philadelphia, PA, May 1996.

[7] Satyanarayanan M. Mobile information access. IEEE Per-sonal Communications 1996;3(1):26}33.

[8] Kuenning G. Design of the SEER predictive cachingscheme. In: Workshop on Mobile Computing Systems andApplications, Santa Cruz, CA, US, 1994.

[9] Zenel B, Duchamp D. A general purpose proxy "lteringmechanism applied to the mobile environment. In: Pro-ceedings of the Third Annual ACM/IEEE InternationalConference on Mobile Computing and NetworkingMobiCom'97, September 1997, p. 248}59.

[10] Fox A, Gribble SD, Brewer EA, Amir E. Adapting tonetwork and client variability via on-demand dynamicdistillation. In: Proceedings of the Seventh InternationalConference on Architectural Support for ProgrammingLanguages and Operating Systems, Cambridge, MA, Oc-tober 1}5, 1996. p. 160}170. ACM SIGARCH, SIGOPS,SIGPLAN, and the IEEE Computer Society.

[11] Narayanaswamy S, Seshan S, Amir E, Brewer E, Broder-sen RW, Burghardt F, Burstein A, Yuan-Chi Chang, FoxA, Gilbert JM, Han R, Katz RH, Long AC, MesserschmittDG, Rabaey JM. A low-power, lightweight unit to provideubiquitous information access application and networksupport for InfoPad. IEEE Personal Communications1996;3(2):4}17.

[12] Edwards WK, Mynatt ED, Petersen K, Spreitzer MJ,Terry DB, Theimer MM. Designing and implementingasynchronous collaborative applications with Bayou. In:Proceedings of the ACM Symposium on User InterfaceSoftware and Technology, Asynchronous Collaboration,1997, p. 119}28.

[13] Object Management Group. CORBA Telecoms Speci"ca-tion, July 1998.


[14] Fiuczynski ME, Grove D. A programming methodologyfor disconnected operation. Technical Report, Universityof Washington, March 1994.

[15] Kistler JJ, Satyanarayanan M. Disconnected operation inthe Coda "le system. ACM Transactions on ComputerSystems 1992;10(1):3}25.

[16] Watson T. Application design for wireless computing. In:Workshop on Mobile Computing Systems and Applica-tions, Santa Cruz, CA, US, 1994.

[17] Watson T. E!ective wireless communication through ap-plication partitioning. In: Fifth Workshop on Hot Topicsin Operation Systems (HotOS-V), Rosario Resort, OrcasIsland, Washington, USA, May 1995.

[18] Sun Microsystems. The Java Developers Kit, Version 1.2.http://java.sun.com/products/jdk1.2/index.html, 1998.

[19] Sun Microsystems. Java Advanced Imaging API.http://java.sun.com/products/java-media/jai/index.html,1998.

[20] Springer T. Verteilung von Applikationen in Systemenmit mobilen EndgeraK ten. Master's thesis, TechnischeUniversitaK t Dresden, Institut fuK r Betriebsysteme,Datenbanken und Rechnernetze, Lehrstuhl Rechnernetze,Mommsenstr.13, 01237 Dresden, Germany, October1998.

[21] Voyager Core Technology User Guide, Version 2.0 Beta 1,1997.

[22] Schill A, Held A, BoK ehmak W, Springer T, Ziegert T. Anagent based application for personalised vehicular tra$cmanagement. Lecture Notes in Computer Science,Vol. 1477, Berlin: Springer, 1998, p. 99}111.


Documents

Two approaches for an adaptive multimedia transfer service for mobile environments