Device Coordination : Concept, Use Cases and Requirements
W3C @@@ 31 August24 October 2008
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The Acstract will be developed after maturating the text of document.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is an Editorial Draft of a possible future W3C Recommendation.
Comments on this document may be sent to the public public-uwa@w3.org mailing list (archived at http://lists.w3.org/Archives/Public/public-uwa/).
Publication as a Editorial Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document is published as part of the W3C Ubiquitous Web Applications Activity by the Ubiquitous Web Applications Working Group. It is a deliverable as defined in the Charter of that group.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
[TBD] - If any one, who knows the way to make ToC automatically, please let me know it.
This document is intended to be an initial base document on which further device coordination is developed.
The text in this section will be refined.
Recent advances in computing technologies and network infrastructure have enabled to provide rich services either local or remote to users through a variety of mobile devices such as digital cameras, handheld computers, PDAs, and smart phones. A wide range of services including home/office networking, location-based services, and intelligent traffic management services are becoming more available than ever, technically practical and financially affordable. In particular, Web-related technologies have contributed to enhance the realization of ubiquitous applications by means of their rich interoperable and extensible mechanisms that have been widely accepted in many domains.
In spite of the rapid growth of Ubiquitous Web Applications (UWA), they impose several important challenges to provide useful services to relevant users through suitable devices. Specifically, services that are either local or remote, explicit or implicit, and individual user-targeted or a group of user-oriented can have diverse characteristics. Therefore, how to unambiguously describe services to discover them in a ubiquitous environment needs to be addressed. Especially, for providing such services, it is also necessary to establish solid relationships between devices and services that they provide.
In a ubiquitous environment, devices may play as clients, servers, or a combination of both. Depending on their roles, devices need to efficiently be accessed and effectively utilized to provide useful services to users. To meet these requirements, how to clearly identify devices and bind them to services needs to be addressed. Furthermore, more often than not, capabilities of devices in providing services or performing computational tasks vary ranging from a simple sensory capability to high decision making performance. Therefore, their capabilities and their usage states corresponding to service provision are to also be specified in an unambiguous way.
In addition to services and devices, special care needs to be taken to consider users preferences. Therefore, discovering devices and biding them to a certain set of services involve a process of describing user’s needs and searching for a matching resource. In this process, users can be asked to specify their preferences interactively, or other third-party can be assigned to manage the user preference. Both the two cases, however, require well-defined specification of user preference that can be supported by CC/PP that has already been accepted as a recommendation of W3C.
For Ubiquitous Web Applications, services, devices, resources, and user preference need to be harmonized. More specifically, web applications providing services through devices need to be able to access proper resources in accordance with their capabilities and user preference through well-defined interfaces without the need to consider internal implementation or network-specific aspects. To this end, it is necessary to develop a mechanism for devices to find available resources, bind to them, and adapt their capabilities to provide specific services or exchange information concerning the states of service provision processes. This procedure is closely related to coordination among heterogeneous devices within a system.
Device coordination plays a crucial role in deal with these challenges listed above. It covers the means for discovering and binding of resources into application sessions in consideration of user preference. This involves consideration of how to describe user preferences, device capabilities, and services as a basis for discovery. Moreover, device coordination is responsible with handling interdependencies among devices, resources, and user preference in providing seamless services to users.
Device coordination is considered a mechanism that aid to managing interdependencies among devices that have different types or levels of capabilities to provide services in such a way that users can enjoy the benefits of the services [1], [2]. Although there are several facets in interdependencies, this document considers interdependencies from a resources’ perspective. How to describe resources and how access control mechanisms to be applied to resources of individual device are among the important issues in device coordination.
Device coordination is broadly defined as a mechanism to eliminate or at least mitigate the interdependencies among devices to achieve a mutually agreed goal service by means of facilitating purposeful communication between devices and adjusting their resource usages.
Formally, it is represented by the following expression:
Device coordination 
can mathematically be represented as a function such that
, where
is a set of service-requesting devices with a capability set
,
is a set of service-providing devices with a resource set
, and
is a set of services that are provided to a user set
.
Device coordination takes two device sets as input parameters in order to coordinate them
. It bridges gaps between capability and resource of devices
to provide services to users.
The following texts is need the concensus to settle down
A narrow definition of device coordination in terms of UWA is given as follows: Device coordination involves a means to describe capabilities of devices and required resources to provide services and relationship between such devices and services, establish a scheme to discover services and bind devices to them, and provide a protocol-independent mechanism to enable event exchanges between them for the purpose of providing users with useful services fitting to user preference.
To realize the device coordination as the above narrow definition, there are several issues to be addressed, and Device coordination consists of several major steps.
The first is related to services. It is obvious that device coordination may not be required during all service lifecycles (sessions). Put other words, device coordination can be dependent of states of a service. For example, when a phone rings, other devices related to sound volume need to change their volume level for conversation over the phone. This volume change of other devices is, however, required only after a user pick up the phone to start conversation. This shows a situation that device coordination is invoked depending on states of a service. Therefore, it may need to describe service state transitions by means of possibly SCXML concerning device coordination.
The second is to identify and describe the relationship between services and devices. Similar to WSDL (Web Service Description Language), it is necessary for device coordination to have a specification to describe what service is available for a device and how the service can be provided by accessing certain resource of the device. For this reason, resource binding plays an important role in device coordination, and it needs to be considered in the relationship between services and devices. Available resources can be exposed via well-established web technologies such as markup and scripting.
Information about why and how device coordination is invoked may need to be shared among devices. In this case, indeterminacy of communication or conversation among devices should be considered in coordinating devices. For example, current resource usage/availability or adjusting capability of a device needs to be transparent to other devices that possibly are interconnected via different protocols. Therefore, how to exchange events and the context of device coordination should be considered an important facet. DOM-based representation of conversation between devices and services can be a potentially effective candidate to support this aspect, and it is necessary to devise a specification for device coordination context to support the coordination mechanism. The device coordination context can be a data structure used to mark messages belonging to the relevant web application involved in device coordination, and it may contain elements that identify a service type and uniquely describe the instances of that service type.
The opinion on the section in the F2F meeting is that current texts are just described the each tenologies, and it is need to make a relarionships including what is difference? and what is simillar?
To achieve seamless device coordination, it is necessary to share information among devices involved in providing useful services to users.
A CC/PP profile is a description of device capabilities and user preferences. Devices which join in coordination may have different capability and preference according to the types of devices and the status of users. The device capabilities and user preferences may be considered in device coordination and they can be referred in the description of CC/PP.
DCCI provides a framework for client-side access to a hierarchy of device properties together with a means to set event handlers for notifications of changes to property values. In some cases, device coordination should recognize the properties of individual devices to provide data or information in proper manners (e.g. display, CPU, speaker, etc.).
DIAL provides the filtering and presentation of Web page content available across different delivery contexts. It enables to accomplish device-neutral data and information transmission in the course of device coordination.
RDF provides a general method of representing information in the Web. It enables to coordinate devices in consideration for data semantics of Web resources which can be accessed on the Web and be utilized by devices for the purpose of effective coordination.
SCXML specified a state-machine based execution model based on Harel State Tables. The state transitions described in devices can be referenced to recognize current or potential states of each device for the optimized device coordination.
[TBD]
There are a variety of ubiquitous devices access to the Web, such as mobile phones, smart phones, personal digital assistants, interactive television systems, voice response systems, kiosks and even certain domestic appliances. Unfortunately, any common and generic way to help them communicate on the Web has not been provided so far. This work addresses the challenges of offering the standardized mechanism of enabling the device coordination. This work aims to design the following components.
Intuitively, device coordination involves a variety of aspects such as how to represent common goals of multiple devices, how to group certain sets of devices together, how to assign services to specific devices, how to allocate resources among different devices, how to determine priority among services provided by different devices, and how to share information such as user context and environmental factors among devices. Even though these aspects impose great challenges on device coordination, it is considered beyond the scope of this document. However, these can be implemented to specific application domains by means of the framework and mechanisms proposed in this document.
It is need more careful to choose the term in this document. And, if a term is taken from other document, the text such as "This term was taken verbatim from xxx" is required.
The working group has decided to use following terms in the work and this document.
An attribute of a sender or receiver (often the receiver) which indicates an ability to generate or process a particular type of message content.
This term was taken verbatim from Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 2.0
A mechanism of binding separated activities of multiple actors, agents, or computing devices in order to achieve the proper goal. See also the Device Coordination.
An apparatus through which a user can perceive and interact with the Web. This term was taken verbatim from Glossary of Terms for Device Independence.
A set of attributes that characterizes the capabilities of the access mechanism, the preferences of the user and other aspects of the context into which a web page is to be delivered. This term was taken verbatim from Glossary of Terms for Device Independence.
A mechanism to eliminate or at least mitigate the interdependencies among devices to achieve a mutually agreed goal service by means of facilitating purposeful communication between devices and adjusting their resource usages.
An attribute of a sender or receiver (often the receiver) which indicates a preference to generate or process one particular type of message content over another, even if both are possible. This term was taken verbatim from Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 2.0.
A network data object or service that can be identified by a URI. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways. This term was taken verbatim from Glossary of Terms for Device Independence.
An abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of providers entities and requesters entities. To be used, a service must be realized by a concrete provider agent. This term was taken verbatim from Web Services Glossary.
An individual or group of individuals acting as a single entity. The user is further qualified as an entity who uses a device to request content and/or resource from a server. This term was taken verbatim from Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 2.0.
(Dave's opinion)The first idea is to abstract away from the specific formats, addressing schemes and protocols used to pass messages passed between devices. This allows us to describe applications using Web concepts such as URIs and DOM events. The application sees the device as a DOM node to which it can target events, and attach event listeners. This allows applications to be written independent of the message passing protocols and networking technologies, which continue to evolve at a rapid pace.
For uncoordinated devices, the events are passed directly to the target device. For strongly coordinated devices all events must be routed through a coordinator which is responsible for managing a set of device/services. In between there is the idea of loosely coordinated devices, where the coordinator is used to manage resourcing agreements between devices, but once an agreement is negotiated, the events move directly between the devices involved.
The loosely coordinated model is well suited to access control, where the coordinator is responsible for access control decisions and determines how applications can access particular devices and in what manner. Strong coordination is a centralized control model, whereas loose coordination is federated control model involving the means to delegate responsibility in a distributed manner.
Uncoordinated devices use a peer to peer model.
The ability to name devices and services with URIs means that we can harness the Semantic Web to provide a rich description of the devices, the services they provide, and the associated coordination and access control policies. These descriptions can be used when an application is being developed, and later when an application is run, as a means to dynamically adapt to variations in devices, including potential malfunctions.
The Web allows these descriptions and the reasoning over them to be done remotely on a server/agent. This means that applications can be upgraded on a much faster timescale than the devices which may be unchanged for the lifetime of the product they are part of, e.g.
cars, houses, planes and ships.
To realize effective device coordination, it is necessary to consider relationship among devices and services, which is closely related to coupling. According to the Web Services glossary in W3C, coupling refers to the interrelatedness and dependency between two or more components or Web Services. This dependency can be decomposed into real dependency and artificial dependency [WSGlossry]:
The first idea is to abstract away from the specific formats, addressing schemes and protocols used to pass messages passed between devices. This allows us to describe applications using Web concepts such as URIs and DOM events. The application sees the device as a DOM node to which it can target events, and attach event listeners. This allows applications to be written independent of the message passing protocols and networking technologies, which continue to evolve at a rapid pace.
For uncoordinated models, the events are passed directly to the target device. For strongly coordinated models all events must be routed through a coordinator which is responsible for managing a set of device/services. In between there is the idea of loosely coordinated models, where the coordinator is used to manage resourcing agreements between devices, but once an agreement is negotiated, the events move directly between the devices involved.
The ability to name devices and services with URIs means that we can harness the Semantic Web to provide a rich description of the devices, the services they provide, and the associated coordination and access control policies. These descriptions can be used when an application is being developed, and later when an application is run, as a means to dynamically adapt to variations in devices, including potential malfunctions.
The Web allows these descriptions and the reasoning over them to be done remotely on a server/agent. This means that applications can be upgraded on a much faster timescale than the devices which may be unchanged for the lifetime of the product they are part of, e.g. cars, houses, planes and ships.
The text in this section will be developed until the end of September
The strongly coordinated model has a centralized coordinator which passes messages between devices. All events must be routed through the coordinator which is responsible for managing a set of device/services. In this model, the coordinator may use a specific protocol or interface, component structure, and security model to communicate each other. When implementing devices to be coordinated in this model, they should observe and stick to coordination models of the coordinator that they are willing to participate in.
However, devices do not necessarily need to use the common language or protocol. By implementing translation and adaptation unit for the different languages and protocols and translating them among devices, the centralized coordinator can play a role in negotiating and mediating events between devices. The coordinator has translation and adaptation unit inside to work as middleware between devices. Consequently, the change of the coordinator may cause the participating devices and services to be updated. Devices conformant to or adaptive to the coordinator can achieve their aims in a physical location or virtual space, such as a home, an office, and a hospital.
Figure 1. An example of strongly coordinated model in device coordination
The text in this section will be developed until the end of September
The loosely coordinated model is well suited to access control, where the coordinator is responsible for access control decisions and determines how applications can access particular devices and in what manner. This model corresponds to a federated control model involving the means to delegate responsibility in a distributed manner. The loosely coordinated model can be an effective form of ubiquitous web application with ultimate scalability and applicability. The coordinator in this model just works as mediator to find and connect available devices in systems. After coordination is established, devices communicate each other with a common protocol. The devices have unlimited compatibility with each other in this model.
In a loosely coordinated model, devices may late or dynamically bind to other components before or while running. Devices adopt standardized interfaces and protocols for loosely coordinated model as they should seamlessly work with each other although they are implemented at different time.
Figure 2. An example of loosely coordinated model in device coordination
The text in this section will be developed until the end of September
Devices in uncoordinated models use a peer to peer manner. The devices cannot be reusable in other systems, because they are hooked so strongly that it is difficult to detach from the system. An uncoordinated model cannot be detached and once a device in this model is detached from the system, it cannot be reconnected automatically. The devices have no compatibility with each other. The system in this model is designed to work adhockery.
Nevertheless, all communicating devices do not require coordinators to mediate them. Suppose two devices are designed to work with only each other without cooperation with any others. Their functions have only to be implemented to support the other device. Instead of strongly or loosely coordinated models, uncoordinated model can be adopted to guarantee secure and robust coordination of the proprietary functions in a pair of devices.
Figure 3. An example of uncoordinated model in device coordination
The following use cases was just taken from the document in UWA F2F meeting. Beacuse it is impossible to describe all of use cases on device coordination, it is need to categorization in a view point of Model of Device Coordination(section 2). After developing the texts in section 2, the categorization of use cases will be develped, and many contributions are required on this clause.
This document presents major uses cases that device coordination can contribute for effective service provision. Each case highlights the need for Device Coordination in realizing Ubiquitous Web applications.
If a person receives a phone call, automated volume control systems, such as audio components and digital television, will lower their volumes to avoid interference automatically.
The messages such as 'lower volume,' 'increase volume,' and 'reset volume' pass through the coordinator. For instance, if a person receives a phone call, the phone device sends a requesting message, 'lower volume,' to the coordinator. Then, the coordinator controls volume control systems in sound devices to lower their volume. The communications among devices are centralized as shown in Figure 1, so that only the centralized coordinator can control devices by passing corresponding messages to target device registered in it. The state chart of this model can be depicted as shown in Figure 4.
Figure 4. A state chart of the automatic volume control service system in strongly coordinated model
Before a set of services are activated, possible devices are connected via coordinator in loosely coordinated model. They only share information of device locations and communication ports which are required to couple them. Once the devices are connected to the coordinator, messages are passed directly between devices without the coordinator. In this case, adding new devices in the system can be carried out automatically. The state chart of this model can be depicted as shown in Figure 5.
Figure 5. A state chart of the automatic volume control service system in loosely coordinated model
There is no coordinator in this model, so the coordination between devices is considered as built-in or pre-installed one. The state chart of this model can be depicted as shown in Figure 6.
Figure 6. A state chart of the automatic volume control service system in uncoordinated model
A user can watch video on PDP in the living room, which was recorded on his or her cellular phone.
The video files which were recorded on his or her cellular phone can be played on the HDTV in the living room.
If a user turns on the radio in the kitchen, PDP will lower the volume in the living room.
If any fire risk is detected (e.g., gas leakage), it will be alerted the fire station to.
A home security system needs to automatically identify a resident and unlock the door.
Scenario: A home security system needs to automatically identify a resident and unlock the door when he or she intends to enter the home.
The coordinator plays a role as a security guard which can recognize personal information and control the door lock system. The state chart of this model can be depicted as shown in Figure 7.
Figure 7. A state chart of the automatic door opening system in strongly coordinated model.
The role of coordinator is just building physical connection between a door lock system and the resident identification module. After the connection has been established, the messages that invoke a service are directly passed between devices. The state chart of this model can be depicted as shown in Figure 8.
Figure 8. A state chart of the automatic door opening system in loosely coordinated model
There is no coordinator in this model, so the resident identification can be done by direct and pre-defined connection between devices. The state chart of this model can be depicted as shown in Figure 9.
Figure 9. A state chart of the automatic volume control service system in uncoordinated model
If a user search for a restaurant on PDA, it will recommend restaurants close to his/her location.
If a user searches for a destination on his/her cellular phone, it will provide the shortest path from a standing point to the location.
An MP3 player will recognize a user's current mood, it plays a piece of music in an appropriate genre.
A user can search for newly released movies, and make a reservation for the ticket right on the spot.
A PDA provides all the information for hot items that are daily advertized and suitable shops as well.
A device needs to provide services that can satisfy multiple users’ preference in consideration of their device capabilities.
A user's schedule will be transmitted from a remote device to whatever device the user is currently using.
If a PDA is not equipped with a sound system, it will automatically transfer sound to a desk top computer.
A navigation system constantly receives traffic information from devices installed on roads and traffic light systems, and provides the best possible route for the driver.
If a user queries for weather information via his or her PDA, it will provide weather information in consideration of the user’s schedule and location.
If a user searches for the shortest path to the destination, his or her PDA will provide a route in consideration of the location of the closest subway from the standing point.
If a user searches for a direction for a specific location in front of a kiosk, it will provide the best possible transportation method to the destination.
A PDA provides arrival time of the bus at the nearest bus stop.
A user can use a wire transfer or purchase goods with his or her cellular phone.
A user can purchase a family ticket with PDA, and each of family member's cellular phone be used as a means to show tickets for the rides.
A user can use a banking service in front of an ATM by connecting his or her PDA that stores the user’s PIN information.
Current shopping information will be transferred from the user's desktop to his or her PDA, so the user can continue shopping on the road.
If a user answers a question wrong on his or her PDA, a lecture will be provided specific to the question that the user answered wrong.
If an instructor records student’s cores, the proper study materials will be sent to each student's PDA
The texts in this clause is not matured, and it is need to make a consunsus on the texts. During the development from section 1 ~ section 3, the requirement item should be developed.
The following references should be refined.
First Editor's draft was developed.
Since the first Editor's Draft:
$Id: index.html,v 1.1 2008/10/20 13:38:54 dsr Exp $