Kohvakko (Kohvakko, 2006) points out the current problem in information collection and representation area being that majority of the existing aware solutions are domain-oriented and task-specific. Because of this, context-aware applications use quite different information models and information ex-change protocols and, thus, are not able to exex-change context information or receive it from the environment unless it is designed specifically for their needs.
As a solution she presents a general framework idea for development of inter-operable context-aware dynamic systems. It is called Context-Aware Mobile Environment(CAME) and consists of four components, which are independent from functionality and implementation points of view.
Figure 1: Information exchange scheme between the CAME mem-bers(Kohvakko, 2006)
- Context Exchange Protocol(CEP)
- Context Aware Application(CAA) - Context Provider(CP)
- Context Aware Supporting Agency(CASA)
CAME is based on the principle that all of its participants can be implemented separately, can use diverse techniques and can perform different functionalities.
Hence each participant of the CAME is able to directly exchange information with any other entity of the environment including components of same the type using CEP(Lakkala, 2003) as illustrated in Figure 1. The key idea of CAME is to have common knowledge representation model and common pro-tocol. CEP, developed by Nokia, is used as an example but in principle it could be any other suitable protocol. As a base of knowledge representation and context extraction, the CAME uses semantic network formally specified by Resource Description Framework(RDF)(W3C, 10 February 2004).
We shall shortly introduce the participants of the CAME.
CASA
The Context-Awareness Supporting Agency is environment-oriented, it is not mobile but has its home environment and permanent reference, which is public for CAA. Each realization of the CASA may provide a different set of services depending on the needs of the particular domain. The main and only compulsory function is to collect, store and provide information about available context providers to the context-aware applications and external agencies. Others functions we are interested in are support for context exchange between environments and the support for the full version of the context exchange protocol. One example of the CASA is the S60 Context Framework, which is presented in section 2.7
CP
The basic function of the Context Provider in CASA is to transform con-text information from the Concon-text Source(CS) data format to the form required by the context exchange protocol and to pass context informa-tion to a consumer. This makes the Context Provider CS oriented and therefore the complexity of a CP depends on the nature of the context source. Hence a CP must be aware of the CS’s nature, but a CS may
not be aware about the CP. The CP is activated when there is a need for it. When there is no need anymore for the CP, the context consumer should release it. When the last consumer needing the CP releases it, the CP deactivates itself and goes to the ’sleep’ mode. Example of a CP could be a software that reads data from the GPS receiver and trans-forms the data to a form required by the CEP before passing it directly to the navigation application needing this information. The navigation application is in a role of a context consumer in this scenario.
CEP
The purpose of the CEP is to enable information exchange between the components of CAME. The first version of the context exchange proto-col has been designed by Nokia(Lakkala, 2003), and could be used as the basis. Each participant in the context-aware environment should sup-port basic or extended version of the protocol. It must include at least following statements
- request/response for the value of the context variable, - request/response for meta-context information,
- activation/deactivation of context provider,
- request/response for available context variables(context providers).
CAA
The basic idea of the context-aware application structure is in separation of the context-awareness capability(CAC) from the whole application’s functionality. This means that the application should work normally also when there is no context information available. ’Normally’ here would not mean ’in the best possible way’. An example of this could be the connection assistant described in section 2.2.
Sometimes absence of context information could also be an important context factor. The complexity of a context-aware application can vary a lot likewise as with the CP’s. The CAA can perform complicated context-based reasoning, prediction, semantic analysis etc. thus beinginteractive or would simply receive CEP messages -from one CP- concerning only one context variable being then a reflective CAA. An example of the interactive CAA could be an application that changes device profile to silent for the night time so the user would not be disturbed while asleep.
Maybe the time from the clock implicating that it is night would not
be enough since the user could for example be in the bar and would probably like to be able to receive calls. But if -in addition- there is a user’s home wlan access point detected there could then be enough context information to infer that the user is asleep and do not want to be disturbed.
An example of areflective CAA could be the Meeting Sniffer application introduced later in this document in section 6. When the Meeting Sniffer application is in push mode it changes the device profile to silent when it receives the silent context from other device.
The requirements of CAME do not state anything on context management model as far as the used protocol in context exchange is the same. The Context Exchange System is implemented on the S60 Context Framework, which is based on context management model called blackboard model. There exist also other context management models. The major ones are introduced in the next section.