clude Jim's own MP3 player, or his brother's digital camera, or perhaps some storage-capable devices of his very close friends among the scouts: Emanuel and ...
Exploiting co-location history for efficient service selection in ubiquitous computing systems Alexandros Karypidis
Spyros Lalis
Department of Computer and Communications Engineering University of Thessaly, Hellas {karypid,lalis}@inf.uth.gr Abstract As the ubiquitous computing vision materializes, the number and diversity of digital elements in our environment increases. Computing capability comes in various forms and is embedded in different physical objects, ranging from miniature devices such as human implants and tiny sensor particles, to large constructions such as vehicles and entire buildings. The number of possible interactions among such elements, some of which may be invisible or offer similar functionality, is growing fast so that it becomes increasingly hard to combine or select between them. Mechanisms are thus required for intelligent matchmaking that will achieve controlled system behavior, yet without requiring the user to continuously input desirable options in an explicit manner. In this paper we argue that information about the colocation relationship of computing elements is quite valuable in this respect and can be exploited to guide automated service selection with minimal or no user involvement. We also discuss the implementation of such mechanism that is part of our runtime system for smart objects.
1
Introduction
Stepping forward into the ubiquitous and pervasive computing era, the number and diversity of digital elements in the environment increases. Computing and information resources come in various forms, ranging from miniature devices such as human implants and tiny sensor particles, to large constructions such as vehicles and buildings. Computing elements can also be embedded into everyday and personal objects such as jewelery [7], wristwatches [16, 11], clothes [23, 18], cups [4] and furniture [19]. Given the inherently distributed and dynamic nature of modern computing environments, runtime systems and ap-
plications need to deal with the intermittent connectivity and varying resource availability; these are constant impediments in achieving robust operation. Moreover, due to the proliferation of elements worn or surrounding the user at any point in time, the number of possible interactions or compositions between them that could lead to desirable functionality grows. Put in terms of a service-oriented viewpoint, there can be several service providers offering identical or similar functionality requested by a service consumer. Simple service discovery is hardly a sufficient solution to the association problem [22] of locating suitable partners for spontaneous interaction in ubiquitous computing environments. The selection between competing service offerings is non-trivial and requires more elaborate matchmaking between consumers and providers, otherwise systems may exhibit chaotic and undesirable behavior. To underline the subtle nature of association in the specific context of ubiquitous computing, we note that the technically meaningful approach of going for the most resourceful option does not necessarily coincide with what is desirable from the personal standpoint of the user. For example, even if the user is situated in infrastructure-rich environments that offer several “outsourcing” options, resource-constrained personal devices may still be preferred for reasons of trust, privacy and habituation. Users may feel more comfortable with their own personal objects rather than with more capable devices requiring unfamiliar interaction modes and modalities. A personal device may also be preferred when a user is on the move (or is about to change location) and wishes to maintain a stable, even if less functional, working system. One possible way to address this problem is for the system to ask users to inform such decisions. However, this is hard to do in a dynamically changing environment comprising a large number of devices, without making the system awkward to use. It would require explicit and continuous user interaction, which is undesirable especially in a mobile
Proceedings of the Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’05) 0-7695-2375-7/05 $20.00 © 2005
IEEE
and wearable computing setting where interaction resources are scarce and user attention must be preserved. It would also imply an in-depth understanding of the various computing elements and their combination options, which cannot be expected from a casual user. Enabling spontaneous communication among devices is necessary but insufficient to pursue the vision of a calm system. In addition, a controlled cooperation between them must be achieved while relieving the user from having to continuously dictate every possible interaction, being lost in a labyrinth of numerous options and internal system technicalities. Hence, mechanisms are needed that will help automate such decisions, resulting in a seamless and self-adjusting system that will behave according to the user’s desires and familiar ways. Such mechanisms will consider the current and past context of use in addition to service properties. In this paper we investigate how information about the co-location context and history of devices can be exploited to achieve this goal. We argue that even a simple analysis of physical proximity patterns among devices can enhance automated service selection in many cases, without explicit user involvement or increased administrative effort. We also discuss the implementation of a corresponding service discovery and selection mechanism that was developed as part of our compact runtime system for smart artefacts.
2
Background and motivation
Our previous work, in the 2WEAR project [14, 13, 9], focuses on a flexible computing model that allows wearable and mobile devices to be combined with each other in a spontaneous fashion. A basic functional core can be ‘composed’ using just a few devices that are carried or worn by the user. Infrastructural computing elements such as Internet access points and user interaction resources found in smart spaces can be opportunistically exploited to augment the functional capabilities and conserve the energy of the personal system, but the core idea is to be able to operate in a completely ad-hoc fashion, relying on elements present in the MANET and not requiring any infrastructure. A key characteristic of our system is that the user can naturally change its configuration by choosing the devices she carries with her at any point in time as well as by moving close to or away from infrastructure devices. To relieve the application programmer from having to explicitly deal with the system dynamics, the runtime automates inter-device cooperation for key functions such as user interaction and data placement. Application interfaces can be constructed using abstract interaction objects that are mapped onto the currently available (and possibly distributed) devices. Furthermore, a cooperative data management scheme is implemented to facilitate transparent data placement between storage devices in conjunction with asynchronous and in-
cremental backup of application data to a central data repository, whenever connectivity is available. To cope with but also to exploit the flexible nature of the system, the user interaction and storage management mechanisms rely on the discovery of available devices in order to select the best possible service that will help the system achieve the desired functionality at any point in time. However, letting the system aggressively exploit newly discovered services is non-optimal because these may remain accessible only for a small amount of time, for example due to user movement. This leads to wasting valuable system resources without achieving any progress. For the case of interactive functions, it may also result in annoying delays and discontinuity both in terms of mode and modality. We address this problem by guiding service selection via preferences that can be specified by the user and/or the application logic, also at runtime. Our initial approach was to let preferences be expressed solely in terms of device ownership and service attribute information1 . This indeed makes it possible to express various selection policies in a flexible and controlled fashion. On the other hand, it requires the user to manually specify numerous default preferences for various runtime services, applications and device combinations, which can be quite impractical. It became clear that to make the system more user friendly, service selection would have to be more intelligent. In fact, despite the system’s ability to dynamically discover and switch between configurations, we found out that it is often better (a) to maintain the current service selection rather than switch to a seemingly better option, and (b) to perform selection based not only on functional service attributes but also on expected availability. A different, perhaps more socially inspired, way of putting this is to say that one should favor a “familiar” and “stable” partnership against a new one even if this appears to be more “exciting”2 . This prompted us to consider the extension of our preference-based service selection model to include information about the previous experience with devices and services that have already been encountered in the past. As a first step towards this direction, we have investigated the exploitation of device co-location history as an additional hint in dynamic service selection. The details of this work are discussed in the next sections.
3
A simple model for capturing co-location information
To capture the co-location relationship between a local device (and potential application host) and other remote devices (offering services to applications) it is required to keep 1 Service
types and attributes were documented via a suitable ontology. course, people occasionally act according to a more “adventurous” spirit, for better or worse. 2 Of
Proceedings of the Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’05) 0-7695-2375-7/05 $20.00 © 2005
IEEE
Device Wristwatch Office room Car Living room Bedroom Other Phone
Current duration 50 hours 30 mins N/A N/A N/A 1 min
Previous encounters 2 22 34 28 15 N/A
Mean duration 82 hours 3 hours 25 mins 4 hours 6 hours N/A
Time of last encounter 53 hours 16 hours 40 mins 55 mins 45 mins N/A
Table 1. An example of the co-location context maintained by a mobile phone. both current and historic information about such encounters. We adopt a simple information model comprising the following information for each remote device: (a) duration of the current encounter, (b) number and mean duration of previous encounters, and (c) time of the last encounter. For example, Table 1 shows co-location entries for a user’s mobile phone. Based on these entries it can be inferred that the phone is constantly near the wristwatch, having only two stable encounters of very high duration. The user seems to have entered her office half an hour ago, where she has been roughly 22 times this week averaging three hours for every stay. Moreover, she was previously in a car (probably driving to work) which was used about 34 times, with an average driving time of about half an hour. Earlier, the user was at home as can be seen from the bedroom and living room entries. At present, another unknown phone has just been encountered, indicating that an unfamiliar person is perhaps visiting the user at the office. A more elaborate information model could be employed, for example by recording a (bounded) number of separate entries for each encounter. This would allow for a more informed analysis of co-location history and prediction of future behavior. Nevertheless, considerable information can already be deduced even from such simple co-location data, which can be maintained using a very small memory footprint. More importantly, it becomes possible to capture the most basic “familiar” and “stable” device relationships in a system, which in turn can be easily exploited to guide service selection. In the next section we describe how this information is efficiently maintained by the discovery component of our runtime system.
4
An implementation of co-location aware service discovery
As previously mentioned, our research [14, 13, 9] targets MANET environments. We therefore pursued an implementation which allows collection and maintenance of co-location heuristics without needing infrastructure support. We incorporated our implementation to our runtime (depicted in Figure 1) for developing smart-object applications. The runtime environment, provides basic service
discovery and invocation primitives which in turn is used to build more advanced application support, such as user interaction and storage management mechanisms. Co-location information is now available to guide service selection.
{ { Figure 1. System design overview The runtime’s engine processes system events and application requests in a main loop. A periodic event is used to sense the computing elements in proximity. Whenever the event is triggered, the engine calls into the network driver to obtain a list of co-located devices. In our Bluetooth-based implementation, this returns the nodes sensed from an inquiry scan operation [2]. Other networking technologies and discovery protocols can be supported by adding a suitable driver. Based on this periodic sensing event the discovery module keeps an array of device encounter records, shown in Listing 1, in conjunction with a hash map to achieve quick lookups. A record holds the time of the first sensing event tsCurEncStartEvnt and the time of the last sensing event tsCurEncLastEvnt contributing to the current encounter. It also holds the number prvEncCnt and mean duration meanPrvEncDur of previous encounters as well as the time tsLastPrvEnc of the last encounter. Finally, it holds the start time of the so-called observation window tsObsrvWinStart for purposes which will be discussed
Proceedings of the Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’05) 0-7695-2375-7/05 $20.00 © 2005
IEEE
private c l a s s EncounterRecord { Device d ; / / a b s t r a c t c l a s s long tsObsrvWinStart ; long t s C u r E n c S t a r t E v n t long tsCurEncLastEvnt ; long tsLastPrvEnc ; i n t prvEncCnt ; l o n g meanPrvEncDur ; // .. . long getCurEncDuration ( ) { return tsCurEncLastEvnt − tsCurEncStartEvnt ; } int getPrevEncCount ( ) { return prvEncCnt ; } i n t getMeanPrevEncDuration ( ) { r e t u r n meanPrvEncDur ; } //
...
} Listing 1. The EncounterRecord object
later on. Table 2 summarizes how these fields map to the elements of the co-location information as shown in Table 1. When a device is sensed for the first time, a new encounter record is created for it and properly initialized. The tsCurEncStartEvnt and tsCurEncLastEvnt fields in the (new) encounter record are set equal to the time of the sensing event that triggered the encounter. The running duration of the encounter is maintained as subsequent sensing events cause updates to the tsCurEncLastEvnt field. When a sensing event does not return this device, the current encounter ends and the record’s fields are updated. Specifically, the prvEncCnt is incremented by one, the tsLastPrvEnc is updated to hold the value of tsCurEncLastEvnt, the meanPrvEncDur is recalculated to incorporate the duration of the encounter, and the tsCurEncStartEvnt and tsCurEncLastEvnt are reset to zero indicating that the device is no longer colocated with the local host. Figure 2 illustrates a sample series of sensing events and the corresponding encounter record updates. Sensing information delivered by the network driver to the discovery module can be inaccurate in terms of completeness due to the inherent unreliability of wireless
History Information Device Current duration Previous encounters Mean duration Last encounter
Implementation d.getAddress() tsCurEncLastEvnt tsCurEncStartEvnt prvEncCnt meanPrvEncDur tsLastPrvEnc
Table 2. Mapping of co-location history table to EncounterRecord object fields.
and most notably short-range communication (propagation anomalies, interference, user movement, etc). Thus, a sensing event may not return all nearby devices. An important implication of this technicality is that a device that is constantly in proximity is nevertheless quite likely to alternate between “co-located” and “not co-located” states. To ameliorate this anomaly, the discovery module does not consider an encounter to be complete when the device is not sensed for the first time, but only after a timeout so that subsequent sensing events will either lead to the continuation of the encounter or further verify that the device is no longer nearby. The timeout period is an internal configuration parameter that can be set at runtime. The co-location history is accessible to applications via methods in the DiscoveryService object which allows applications to query for services by current colocation time and estimated mean duration. Once applications obtain a reference to a service they may also retrieve the EncounterRecord of the corresponding device and inspect co-location information. In addition, the DeviceRegistry object allows access to the co-location information even prior to inspecting a device in the PAN in order to retrieve its services.
5
Garbage collection of co-location history
Given the large number of devices that can be encountered in a ubiquitous computing setting but also the typical resource constraints of embedded devices, it is unrealistic to let the co-location information grow ad infinitum. This in turn necessitates a policy for replacing or collecting encounter records. Therefore, when a new encounter record must be created, the database size is checked to see whether there is enough space. In this case the new record is simply inserted into the database. Else, a victim record is chosen (randomly) out of all records concerning devices that (a) are currently not co-located, (b) have the smallest total duration of previous encounters (approximated as the product of the number of previous encounters and mean duration) and (c) have the oldest latest encounter. If no such record
Proceedings of the Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’05) 0-7695-2375-7/05 $20.00 © 2005
IEEE
Figure 2. Time diagram of sample events regarding co-location history recording. exists, i.e. all records are about devices that are currently co-located, then the new encounter is ignored. This approach results in the system being “blind” to new devices (and the services provided by them) if the size of the database is smaller than the number of currently co-located devices. We nevertheless expect this limitation to be of minor practical importance. This is because the memory requirements of our approach are already very modest and can be met even by small embedded devices. Furthermore, devices that host heavyweight applications that may need perform informed service selection for a large number of different services, can easily maintain large enough databases in the order of hundreds of records; they may even feature persistent storage so that part of the encounter database can be kept without occupying valuable volatile memory. Finally, it is important to stress the fact that co-location information is an auxiliary hint, and that it is possible to discover and access a device and service independently of whether a corresponding encounter record exists. Co-location history is maintained with respect to an observation period P (e.g. one week), which is a system configuration parameter that makes it possible to remove old co-location records. Since we do not keep a separate timestamp for each previous encounter, garbage collection is done by approximation, as follows. When a new encounter record is created, its tsObsrvWinStart field is initialized with the time of the first corresponding sensing event. This field is used to periodically check whether the record contains data beyond the observation period P , i.e. currentTime - tsObsrvWinStart > P. In this case the co-location history is pruned by increasing the value of the tsObsrvWinStart field by an advancement time slot T. Also, the number of previous encounters is adjusted, assuming a uniform distribution of encounters in time, by decreasing the prvEncCnt field in proportion to T. The meanPrvEncDur field remains unchanged since
we assume a uniform distribution of encounter duration in time. As a result of this update process an encounter record may end up containing merely “outdated” information and can be removed. We consider this to be the case when: prvEncCnt < T/P, which allows a record based on a single encounter to persist for at least two consecutive periods. Other metrics could easily be employed for discarding records. Large observation periods have the effect of keeping information around for a long time, thus can be used to capture macroscopic encounter patterns. Small observation periods are more appropriate for capturing shorter and repetitive patterns which in essence do not correspond to any new information. They also allow the system to “forget” faster, making it more receptive to changing user habits. Notably, a similar effect of “forgetting” could also be introduced via a weighted scheme for calculating the number and average duration of previous encounters, reinforcing recent and weakening previous encounter information. For the time being we prefer an unbiased scheme because most user activities in our personal computing scenarios seem to be quite periodic and repetitive, exhibiting significant colocation invariance for most devices involved. Moreover, adaptation to entirely new situations would require a radical weighting scheme in favor of new encounters, which in turn would hardly work for most other routine cases. We believe that such exceptional changes in user requirements are best dealt with via explicit preferences; in this case the user is also more inclined to be happy to provide explicit input to the system.
6
Exploiting co-location context history in higher level runtime mechanisms
Co-location information provides the opportunity to take more informed decisions about the “partners” chosen for a
Proceedings of the Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’05) 0-7695-2375-7/05 $20.00 © 2005
IEEE
particular interaction or producer-consumer matching. It is possible to think of many different scenarios where applications directly take advantage of this information. However, it is probably even more important to think of how this information can be related to and exploited by higherlevel runtime mechanisms for the general benefit of all or at least a large class of applications. In the following, we give some examples of how we exploited co-location information within our runtime system for smart objects.
6.1
Context dissemination
In [9], we present a mechanism for software entities to asynchronously exchange context information, both in a vertical (between software entities residing on the same device) and horizontal (between different devices) fashion. This is accomplished by the context manager module of our runtime system (see Figure 1) that allows local software entities to advertise contextual information. The advertised context becomes available for use by any local entity, and is eventually propagated to other devices as part of the routine discovery and service inspection cycle. Context information has a time-to-live (TTL) value to constrain diffusion and may be tagged as non-exportable to enforce purely vertical context aggregation. As an overall result the collective sensing capabilities of a group can be exploited in a seamless way, letting co-located devices and software entities form an aggregated and shared contextual perception. This context dissemination mechanism is capable of operating in pure MANET settings with no infrastructure support, as is the co-location mechanism described in Section 4. We therefore exploited each in the other in the following ways. First, co-location information becomes “per se” context, by publishing the identities of devices in the MANET to the context manager as non-exportable3 , so that this information can be exploited by local services and applications. This context is exploited indirectly by the storage system in our runtime, which annotates files with meta-data based on the contents of the context-manager. For example, if a user takes a photograph using a digital camera, a GPS location stamp can be attached to the file (provided that a GPS receiver device posts this data to its local context manager). Co-location metadata can provide analogous documentation in terms of the devices (and thus users) present at that time (also see [10] for a specific application of this concept). In our photography example, the photograph will contain meta-data regarding the devices present when the user took the photograph. This can be used in the distant future to determine which device was used to obtain the GPS location stamp, or to determine the people present based on the ownership of devices. 3 Advertising the presence of another device to the neighborhood is probably useless as neighbors can observe it themselves.
Co-location information is further used by the context mechanism to control horizontal context diffusion. A device or application can namely avoid importing context provided by a source (device) that is merely an opportunistic encounter (e.g. a short current encounter and/or no long previous encounters) and prefer to rely exclusively on context information provided by stable and familiar sources. This prevents “context littering” from opportunistic encounters among moving users. We refer the reader to [9] for a more elaborate discussion on the implementation of our runtime’s storage system, which automatically collects such meta-data to be used as semantic annotations.
6.2
Data availability
A more obvious case of using co-location information is to achieve better data placement in a distributed device setting. Specifically, when our storage management framework decides (due to local memory limits) to offload files to a remote device, it selects a storage service which has the highest mean encounter duration. This increases the likelihood of the local applications being able to access the remote data in the (near) future. For example, imagine a user being part of a group taking photographs in an isolated location, without any wireless network coverage or fixed infrastructure. A typical example would be scouts which are on a hiking and camping trip in the countryside. Assume one of the scouts, Jim, has a camera which runs out of space. Our runtime’s storage system is capable of offloading files to other trusted devices which have adequate storage. Trusted devices could include Jim’s own MP3 player, or his brother’s digital camera, or perhaps some storage-capable devices of his very close friends among the scouts: Emanuel and John. Other scouts are assumed to be untrusted members (no pun intended to scouts’ honor). To increase the likelihood of the local application being able to access the remote data, one would expect the selection to go to a device of the person that Jim is sharing the tent with (e.g. John). This preference can be naturally captured via the co-location information for the various devices within the group. In specific, the storage system selects the trusted device for which the product of mean encounter duration and number of encounters is maximum to conduct file transfers.
6.3
Resource preservation
Power consumption is a key challenge in wearable computing [21]. It is important to restrict wasted computing cycles and even more important to avoid radio use (which is typically much more energy-consuming) whenever possible. One way to exploit co-location history towards this objective is to select stable services (i.e. ones located on de-
Proceedings of the Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’05) 0-7695-2375-7/05 $20.00 © 2005
IEEE
vices with long mean encounter durations) when in power saving mode. As a specific example, we refer again to our storage framework [14, 9] and specifically to its ability to automatically back up data generated by the user to a central repository using network access points. As a result, files such as photographs on digital cameras, voice-memo or conversation recordings on a mobile phone and notes taken on a PDA are automatically collected to a repository accessible by the user through a desktop. When an access point is known to have long encounter duration (e.g. the access point in the office where one spends significant time) a device can backup files with low probability of being interrupted. Else a significant amount of resources can be wasted in a series of continuous (and unsuccessful) attempts to backup a file via many different access points encountered only for a brief duration (e.g. as the user walks down the street and passes by different hot spots). We modified the storage system’s backup behavior as follows: unless the access point is one which is known to be around for at least two minutes on average, the backup process is not initiated. The metric used is the mean encounter duration recorder for that access point. The number of encounters is disregarded (as opposed to the metric used in Section 6.2) because we are only interested in the prospect of continuous co-location in order to complete this backup round.
7
Discussion
There has been a lot of research in middleware for ubiquitous computing. With regard to infrastructure, we refer the reader to work such as Aura [6] and Gaia [20]. Both systems target infrastructure-based smart spaces, but could also benefit from a co-location history management mechanism given that they also consider mobile computing elements. Most mobile computing middleware does not address the issue of maintaining co-location information. Focus is typically either on the technicalities of enabling spontaneous interaction [8, 3, 17], or on specific application scenarios and requirements [15, 12] where the high granularity of functionality will generally not give rise to association issues. Recent work such as the RCSM framework [24] goes further by providing an elegant way for achieving contextaware (and context-triggered) device interaction. Specifically, in RCSM the CA-IDL language makes it possible to invoke methods as the outcome of context-related expressions. However, expressing selection of a specific component in the presence of many candidates is not considered. Some analogy exists among our approach to exploit colocation history to infer device proximity (and thus availability) and work in P2P networks for achieving faulttolerance. In [5], nodes gather history regarding faulty behavior of peers, over some observation period. Services
are then replicated on nodes which fail within different time-slots, thereby decreasing the probability of service unavailability due to concurrent failure, but this work is however not applicable to our MANET setting, nor to resourceconstrained devices. Further insight into the potential use of co-location history can be found in comparison to the analysis of user location information, e.g. see [1]. In this case GPS time and location stamps are recorded using a wearable device, and are subsequently used to infer discrete locations (in the higher level sense of the word) based on the areas where a person spends significant time. This data is further exploited to compute the correlation among such locations as a function of time in order to predict user movement. Such elaborate analysis could also be applied to study device colocation patterns, provided that a device has enough memory resources to be able to keep more detailed information.
8
Conclusion
The association problem [22] – detecting partner components with which a component may interact – can not be addressed efficiently through simple service discovery. Equally important to detecting compatible components is automating service selection in a computing environment with numerous suitable options. In this paper we have argued that in many cases historical co-location information can provide a valuable hint to support intelligent service selection in a dynamic and multidevice setting. We have also presented a concrete and compact implementation of such a mechanism as an extension of our runtime system that was developed to support applications in a distributed personal system, and discussed several applications thereof. Though we do not claim to have provided a solution that caters for all possible requirements and scenarios, we believe that our approach is sufficiently generic and efficient to be useful in many different cases.
References [1] D. Ashbrook and T. Starner. Using gps to learn significant locations and predict movement across multiple users. Personal Ubiquitous Comput., 7(5):275–286, 2003. [2] S. Avancha, A. Joshi, and T. Finin. Communications: Enhanced service discovery in Bluetooth. Computer, 35(6):96– 99, June 2002. [3] J. Beck, A. Gefflaut, and N. Islam. MOCA: a service framework for mobile computing devices. In Proceedings of the 1st ACM international workshop on Data engineering for wireless and mobile access, pages 62–68. ACM Press, 1999. [4] M. Beigl, H.-W. Gellersen, and A. Schmidt. Mediacups: experience with design and use of computer-augmented everyday artefacts. Comput. Networks, 35(4):401–409, 2001.
Proceedings of the Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’05) 0-7695-2375-7/05 $20.00 © 2005
IEEE
[5] F. Chen and S. Yuan. A contextualized fault-tolerant infrastructure for P2P mobile service composition. In IEEE International Conference on Services Computing (SCC 2004) Shanghai, China. IEEE Computer Society Press, September 2004. [6] S. Cheng, D. Garlan, B. R. Schmerl, J. P. Sousa, B. Spitznagel, P. Steenkiste, and N. Hu. Software architecture-based adaptation for pervasive systems. In Proceedings of the International Conference on Architecture of Computing Systems, pages 67–82. Springer-Verlag, 2002. [7] M. Gandy, T. Starner, J. Auxier, and D. Ashbrook. The gesture pendant: A self-illuminating, wearable, infrared computer vision system for home automation control and medical monitoring. In Proceedings of the 4th IEEE Internation Symposium on Wearable Computing, pages 87–94, October 2000. [8] T. D. Hodes, R. H. Katz, E. Servan-Schreiber, and L. Rowe. Composable ad-hoc mobile services for universal interaction. In Proceedings of the 3rd annual ACM/IEEE international conference on Mobile computing and networking, pages 1–12. ACM Press, 1997. [9] A. Karypidis and S. Lalis. Context-based storage management for wearable and portable devices. In Systems Aspects in Organic and Pervasive Computing - ARCS 2005: 18th International Conference on Architecture of Computing Systems, volume 3432 of Lecture Notes in Computer Science, pages 236–248. Springer, March 2005. [10] N. Kern, B. Schiele, H. Junker, P. Lukowicz, and G. Troster. Wearable sensing to annotate meeting recordings. Personal Ubiquitous Comput., 7(5):263–274, 2003. [11] A. Kirkeby, R. Zacho, J. D. Mackinlay, and P. Zellweger. TrekTrack: A round wristwatch interface for SMS authoring. In Proceedings of the Third International Conference on Ubiquitous Computing, volume 2201 of Lecture Notes in Computer Science, pages 292–298. Springer, 2001. [12] G. Kortuem and Z. Segall. Wearable communities: Augmenting social networks with wearable computers. IEEE Pervasive Computing, 2(1):71–78, 2003. [13] S. Lalis, A. Karypidis, and A. Savidis. Ad-hoc composition in wearable and mobile computing. Commun. ACM, 48(3):67–68, 2005. [14] S. Lalis, A. Karypidis, A. Savidis, and C. Stephanidis. Runtime support for a dynamically composable and adaptive wearable system. In Proceedings of the 7th IEEE Internation Symposium on Wearable Computing, pages 18–21, October 2003. [15] J. Lehikoinen, J. Holopainen, M. Salmimaa, and A. Aldrovandi. MEX: A distributed software architecture for wearable computers. In Proceedings of the 3rd IEEE Internation Symposium on Wearable Computing, pages 52–57, 1999. [16] C. Narayanaswami, N. Kamijoh, M. Raghunath, T. Inoue, T. Cipolla, J. Sanford, E. Schlig, S. Venkiteswaran, D. Guniguntala, V. Kulkarni, and K. Yamazaki. IBM’s Linux watch: The challenge of miniaturization. IEEE Computer, 35(1):33–41, Jan. 2002. [17] M. Raghunath, C. Narayanaswami, and C. Pinhanez. Fostering a symbiotic handheld environment. IEEE Computer, 36(9):56–65, 2003.
[18] J. Rantanen, J. Impio, T. Karinsalo, A. Reho, M. Malmivaara, M. Tasanen, and J. Vanhala. Smart clothing prototype for the arctic environment. Personal and Ubiquitous Computing, 6(1):3–16, 2002. [19] T. Rodden, Y. Rogers, J. Halloran, and I. Taylor. Designing novel interactional workspaces to support face to face consultations. In CHI ’03: Proceedings of the conference on Human factors in computing systems, pages 57–64. ACM Press, 2003. [20] M. Romn and R. H. Campbell. A Middleware-Based Application Framework for Active Space Applications. In Lecture Notes in Computer Science, volume 2672, pages 433–454. Springer-Verlag, August 2003. [21] T. Starner. The challenges of wearable computing: Part 1. IEEE Micro, 21(4):44–52, July/Aug. 2001. [22] Tim Kindberg and Armando Fox. System software for ubiquitous computing. IEEE Pervasive Computing, 1(01):70–81, 2002. [23] A. Toney, L. Dune, B. H. Thomas, and S. P. Ashdown. A Shoulder Pad Insert Vibrotactile Display. In Proceedings of the 7th IEEE Internation Symposium on Wearable Computing, pages 35–44, October 2003. [24] Yau Stephen S. and Karim Fariaz and Wang Yu and Wang Bin and Gupta Sandeep K. S. Reconfigurable contextsensitive middleware for pervasive computing. IEEE Pervasive Computing, 1(03):33–40, 2002.
Proceedings of the Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’05) 0-7695-2375-7/05 $20.00 © 2005
IEEE
