Context exchange between devices in mobile environment

(1)

LAPPEENRANTA UNIVERSITY OF TECHNOLOGY DEPARTMENT OF INFORMATION TECHNOLOGY

CONTEXT EXCHANGE BETWEEN DEVICES IN MOBILE ENVIRONMENT

The topic of the Master’s thesis has been approved by the department council of the Department of Information Technology on 10.10.2007.

Supervised and reviewed by Professor Kari Smolander and Doctor of Philosophy Nataliya Kohvakko

(2)

ABSTRACT

Lappeenranta University of Technology Department of Information Technology Software Engineering

Jarkko Mikael Tulla

Context exchange between devices in mobile environment Master’s thesis.

2008

75 pages, 13 figures and 5 tables.

Examiners: Professor Kari Smolander

Doctor of Philosophy Nataliya Kohvakko

Keywords: context-awareness, context exchange, distributed context a- wareness, context framework

Context awareness is emerging on mobile devices. Context awareness can be used to improve usability of a mobile device. Context awareness is particu- larly important on mobile devices due the limitations they have. At first in this work, a literature review on context awareness and mobile environment is made. For aiding context awareness there exist an implementation of a Context Framework for Symbian S60 devices. It provides a possibility for exchanging the contexts inside the device between the client applications of the local Context Framework. The main contribution of this thesis is to design and implement an enhancement to the S60 Context Framework for providing possibility to exchange context over device boundaries. Using the implemented Context Exchange System, the context exchange is neither depending on the type of the context nor the type of the client. In addition, the clients and the contexts can reside on any interconnected device. The usage of the system is independent of the programming language since in addition to using only Sym- bian C++ function interfaces it can also be utilized using XML scripts. The Meeting Sniffer application, which uses the Context Exchange System, was also developed in this work. Using this application, it is possible to recognize a meeting situation and suggest device profile change to a user.

(3)

TIIVISTELM ¨ A

Lappeenrannan Teknillinen Yliopisto Tietotekniikan osasto

Ohjelmistotekniikka Jarkko Mikael Tulla

Laitteiden välinen kontekstin vaihto mobiiliympäristössä Diplomityö

2008

75 sivua, 13 kuvaa ja 5 taulukkoa.

Tarkastajat: Professori Kari Smolander

Filosofian tohtori Nataliya Kohvakko

Hakusanat: kontekstitietoisuus, kontekstin vaihto, hajautettu kontekstitietoisuus, kontekstikehys

Matkapuhelimien kontekstitietoisuus on lisääntymässä. Kontekstitietoisuutta voidaan hyödyntää matkapuhelimen käytettävyyden parantamisessa. Kontek- stitietoisuus on erityisen tärkeää matkapuhelimessa sen rajoituksien vuoksi.

Aluksi tässä työssä tehdään kirjallisuustutkimus kontekstitietoisuudesta ja mat- kaviestinympäristöstä. Symbian S60 matkapuhelimeen on toteutettu kontekstikehys kontekstitietoisuuden toteuttamiseksi. Tämä kontekstikehys tarjoaa kontekstin välitysmahdollisuuden laitteen sisällä, paikallisen kontekstikehyk- sen asiakassovellusten kesken. Tämän työn tärkein osuus on toteuttaa kon- tekstitiedon vaihdon yli laiterajojen mahdollistava laajennus olemassaolevaan kontekstikehykseen. Toteutettua järjestelmää käyttämällä kontekstitietoa voidaan vaihtaa kontekstin tai asiakassovelluksen tyypistä riippumatta. Lisäksi kontekstit ja asiakassovellukset voivat sijaita missä tahansa keskenään yhtey- dessä olevassa laitteessa. Järjestelmää voidaan Symbian C++ ohjelmointi- rajapintojen lisäksi käyttää myös XML scriptien avulla, jolloin se ei ole ri- ippuvainen ohjelmointikielestä Työhön kuului myös toteutettua laajennusta käyttävän Meeting Sniffer-sovelluksen toteutus. Sovelluksen avulla voidaan tunnistaa kokoustilanne ja ehdottaa matkapuhelimen profiilin vaihtoa käyttäjäl- le.

(4)

FOREWORD

This master thesis has been written for Nokia Corporation in Oulu, Finland in 2008

I want to thank my supervisor professor Kari Smolander at Lappeenranta University of Technology and second reviewer Ph.D. Nataliya Kohvakko at Nokia for their guidance on this thesis.

I am also grateful to Jouni Ahola for providing support on my own company, TietoEnator, side.

Special thanks to Juha Uusitalo, my colleague at TietoEnator, for his invalu- able help on software development in Symbian environment.

I also wish to thank my parents. They have always encouraged me to study.

In Oulu, Finland, 1st of November 2008

Jarkko Tulla

(5)

ABBREVIATIONS

1G First Generation Mobile Communications System 2G Second Generation Mobile Communications System 3G Third Generation Mobile Communications System 4G Fourth Generation Mobile Communications System AI Artificial Intelligence

API Application Programming Interface BDI Belief-Desire-Intention

CAA Context-Aware Application CAC Context-Awareness Capability CAME Context-Aware Mobile Environment CASA Context-Awareness Supporting Agency CEP Context Exchange Protocol

CP Context Provider

CS Context Source

EDR Enhanced Data Rate

GIAC General Inquiry Access Code GPRS General Packet Radio Service GPS Global Positioning System HCI Human Computer Interaction HSCSD High-Speed Circuit-Switched Data HSPA High-Speed Packet Access

IR Infrared

ITU The International Telecommunication Union

(8)

L2CAP Logical Link Control and Adaptation Layer

LED Light Emitting Diode

LIAC Limited Inquiry Access Code PAN Personal Area Network pan public access network

RDF Resource Description Framework RFCOMM Radio Frequency Communication SDP (Bluetooth) Service Discovery Protocol

UMTS Universal Mobile Telecommunications System WLAN Wireless Local Area Network

WPAN Wireless Personal Area Network

WWW World Wide Web

XML EXtensible Markup Language

(9)

1 INTRODUCTION

1.1 Background

Usability is one of the key factors for good user experience, with any device.

The task of providing the good user experience is harder to implement to mobile devices with small screen and keyboard when compared -for example- to a desktop PC. Also context of the mobile device is changing rapidly and this sets more challenges for usability. In order to improve usability mobile devices should adapt to a changing situation, to be context aware. Context aware applications are needed for better user experience. Context awareness is emphasized in mobile environment where the user and the device are moving or there are another moving users with devices in the context of a one user. In addition to other resources, there is an increasing number of sensors embed- ded in mobile devices for providing information about context. In addition, for using only resources of one device for providing context information, the contexts could be exchanged between devices.

A software subsystem, the Context Framework has been introduced in (Kor- pip¨a¨a, 2005) for facilitating the implementation of context-aware features on mobile device. The Context Framework is based on blackboard context management model.

There exist an implementation based on this framework for Symbian S60 devices. This implementation provides currently context exchange possibility only inside the device between the client applications of the local Context Framework. Sharing of context information through a network was beyond the scope of the introduced Context Framework, therefore implementation lacks support for context exchange between devices.

1.2 Task Setting

Since the context exchange possibility between devices was not provided in the implementation of the S60 Context Framework, the task of this work was to design and pilot this capability. Using this enhancement the context exchange

(10)

between devices should become possible and be independent of the context type or the client. The S60 Context Framework is based on blackboard context management model which means that the contexts are stored to the blackboard from where they are available to all clients of the local Context Framework.

The provided context exchange enhancement merges the blackboards of the physically separated -but interconnected- devices together, so that a context stored to one device’s blackboard is available to other devices as well.

The implemented Context Exchange System is independent of the programming language since in addition to using provided Symbian C++ function interfaces, it can also be utilized using XML scripts. The work also includes development of an application which uses the implemented system. Using this application it should be possible to recognize the meeting situation and suggest profile change to a user. Context exchange should be automatic so that it should be possible with a minimal user intervention.

To realize these tasks the following research question has been formulated

How to exchange context in blackboard context management model based software architecture for mobile devices?

This can be divided to the following more specific questions:

1. What kind of software architecture would be efficient for exchange of context information between mobile devices?

2. Which would be the protocol suitable for context exchange?

3. What would be suitable communication channel for context exchange?

4. Which parameters would be relevant for measuring performance?

1.3 Scope of the Thesis

On a way to answer to research questions, a literature review on context awareness is made. Also technologies on wireless communication are evaluated. In

(11)

the review, context and context awareness are discussed in detail. A general framework, the Context Aware Mobile Environment(CAME) for context aware systems introduced in (Kohvakko, 2006) is briefly described. Context management models are studied. CAME and context management models are converged by presenting the Context Framework. The Context Framework is the implementation of a blackboard context management model and realizes one environment specific context provisioning system as a part of the CAME.

Solutions needed for the mobile environment are described.

Security isssues are beyond the scope of this research. Information models related to context awareness are not discussed. We do not handle possible types of context like location nor the possible applications or services that could be implemented using context exchange system more than explaining the functioning of the example application, the Meeting Sniffer. Omission is because one of the requirements -defined in section 5.1- was independency of the type of context and of the application.

1.4 Organization of the Thesis

Literature review is made in sections 2 and 3. Context awareness is discussed in section 2. The mobile environment is handled in section 3, also answer to the research question 3 -What would be suitable communication channel for context exchange? is provided in this section, in subsection 3.3. The literature review is converged to the term Distributed Context Awareness, which is introduced in section 4. The design and the architecture of the developed Context Exchange System is presented in section 5 answering also to the research question 1 -What kind of software architecture would be efficient for exchange of context information between mobile devices?. The Meeting Sniffer application is presented in section 6. The development environment, protocol and testing are described in section 7. This section also answers to the research questions2 -Which would be the protocol suitable for context exchange? and 4 -Which parameters would be relevant for measuring performance? The mod- ifiability of the system and future work are discussed in section 8. The main research question,How to exchange context in blackboard context management model based software architecture for mobile devices, is answered and the work is concluded in section 9.

(12)

2 CONTEXT AWARENESS

Context awareness is usually defined as an ability of an application to dynamically change or adapt its behavior according to the context(Schilit et al., 1994)(Brown et al., 1997)(Ward et al., 1997)

Context awareness is a wide concept and for clarifying it other concepts must be explained. The most important one being the context. Also context aware applications are explained in this section. In addition, the Context Aware Mobile Environment introduced by Kohvakko in (Kohvakko, 2006) is presented. We also explain and compare context management models. Korpipää’s Context Framework(Korpipää, 2005) is introduced in detail. S60 Context Framework is based on Korpipää’s Context Framework, which uses one of the introduced context management models, the blackboard based context management model.

2.1 Context

Characterization of the context is essential when talking about context awareness and context-aware systems and services.

The classical definition of the context is given by Dey in his doctoral dissertation (Dey, 2000)

Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves.

As we can see Deys definition is Human Computer Interaction(HCI) oriented.

Though Dey wants to make definition of the context more general, yet this is not general enough for our purposes since in the implemented Context Exchange System, interactions happen between software units while user- application interaction is not necessarily involved in the actual context exchange. It can also be arqued that the ultimate aim of more intelligent and adaptable devices is of reducing the time and effort required from the user.

(13)

Kohvakko also points out(Kohvakko, 2006) this issue by saying that nowadays interactions occur not only between human and computer but also between

- applications

- applications and equipment - low-level sw units

- any other logical or physical entities.

Deys definition is extended by (Ambient Networks ContextWare, 2005)

context information is any information that can be used to characterize the situation of an entity, where an entity can be a person, a place, a physical, a networking, a storage, a service or computational object.

The Context Exchange System can be seen as a part of the Context Aware Mobile Environment(CAME) introduced in (Kohvakko, 2006) and presented shortly in section 2.3 of this thesis. The task of the Context Exchange System in the CAME can be seen as an enabler of the communication between different Context Aware Supporting Agencies(CASAs). The S60 Context Framework is one environment-oriented CASA. Since the CAME is general and domain independent, more general definition of the context is needed.

Kohvakko states (Kohvakko, 2006) that one of the key enablers of the Wireless Internet is context-awareness, but proceeds that one of the most problematic issues in context-aware computing is an absence of common understanding of the context as a concept. Therefore the context as a concept is discussed in depth in her doctoral dissertation (Kohvakko, 2006). Shortcomings of the earlier definitions(Dey, 2000)(Ambient Networks ContextWare, 2005) are well addressed in conclusion that they suit only for particular domains and for certain classes of tasks. Hence she points out the lack of a universal definition of the context for any environment, any context consumer in any situation.

The conclusion of this discussion is that the context is a relational property and that contextuality of the information depends on the particular situation in which information is used. As a result she gives new definition of the context

(14)

context of the given piece of information is any information having known direct or distant semantic relationship with it

We find this perfect while looking from the wider perspective. But, from the perspective of the implemented Context Exchange System, the Dey’s definition presented earlier is more suitable to our needs.

2.2 Context-Aware Applications

Context-aware application is by definition(Kohvakko, 2006)

context-aware application is an application which is able to receive and use context information that is initially located outside the application. A context-aware application is able to perform its functions correctly without context information

In addition, Kohvakko defines 2 degrees of application context awareness -low and high. When the major functionality of an application is based on the context information it is high degree context-aware and hence can be called context-oriented or context-based application. An example of a high context- aware application could be a navigation application which would be quite useless without location information.

An application with low degreee of context awareness is called acontext-aware application. This kind of application usually performs some task which is not directly concerned of the context. An example of this kind of application could be a connection assistant which responsibility could be to offer the best possible option to connect to the Internet. At first, there could be only GPRS connection available for using the Internet. A situation could be that a mobile user with his/her mobile device could be entering to town center area of Oulu, in Finland, which is covered with panOULU, a free WLAN connection for everyone. The connection assistant should then notice this and inform the user about the availability of a better connection option what comes to cost and speed. Should the connection assistant miss -for some reason- the information on new option, the user could anyway continue using the Internet with the GPRS connection.

(15)

The general definition(Kohvakko, 2006) is perfect from the viewpoint of the implemented Context Exchange System since one of the requirements (see chapter 5.1) for the system is that it should exchange context not depending the context type nor the application. Further division to high and low degree context-awareness is left to a context consumer, which can be for example some application.

Moreover there are push and pull aspects in context-awareness as explained in (V¨ayrynen, 2007). Push and the pull are terms that typically characterize the initiator of data transmission when using a context-aware service. Inpush, a service or piece of information is pushed to a customer without his/her request and in pull, the user intentionally wants to retrieve information from its producer. Example cases on these are described in section 4

2.3 Context-Aware Mobile Environment

Kohvakko (Kohvakko, 2006) points out the current problem in information collection and representation area being that majority of the existing context- aware solutions are domain-oriented and task-specific. Because of this, context- aware applications use quite different information models and information exchange protocols and, thus, are not able to exchange 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)

(16)

- 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 protocol. 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 context information from the Context Source(CS) data format to the form required by the context exchange protocol and to pass context information 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

(17)

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 transforms 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 protocol has been designed by Nokia(Lakkala, 2003), and could be used as the basis. Each participant in the context-aware environment should support 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

(18)

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.

2.4 Context Management Models

There exist number of models for coordinating multiple inter-operating components. These are divided to three groups by Winograd(Winograd, 2001):

widget model, client-server model, and blackboard model. These models are introduced and compared in this section.

2.4.1 Widgets

Dey(Dey, 2000) introduces the Context Toolkit in his dissertation. The Con- text Toolkit is based on widgets. The widget based model is adopted from the architecture of graphical user interfaces(GUI). On a GUI, for example, a scroll bar is a widget, a high level abstraction that can be used by the application, hiding the details of controlling hardware peripherals. The guiding principle in the design was to separate the acquisition of the context from the use of it.

Interaction is implemented by passing messages(to the widget) and callbacks (triggering the code when a particular condition happens in the widget).

(19)

The Context Widgets in the Context Toolkit are responsible for collecting information through the use of the hardware-based sensors. The hardware- based sensors are introduced in (Dey et al., 1999) Just as the GUI widgets mediate between the application and the user, the Context Widgets mediate between the application and its operating environment. Both types of widgets provide abstraction that allows events to be placed in and taken out of the event queue without applications and widgets having to know the details about each other. Where the GUI widgets are owned by the application that created them, the context widgets are owned by any single application and are shared among all executing applications.

In addition to the widgets, the Context Toolkit consists of four more components. These are the Aggregator, the Intepreter, the Widget service, and the Discoverer. All components together provide functionality for handling the context. The architecture of the Context Toolkit is depicted in Figure 2

Figure 2: Context Toolkit architecture. The arrows represent typical interaction between components.(Korpip¨a¨a, 2005)

Widgets are attached to the sensors providing the context for the applications and separating the context acquisition from its use. The Aggregator collects pieces of the context into the same place, so that the application will not have to fetch them from several components. The Interpreter takes the contexts as an input and transforms them into another contexts. The Widget Service provides services that applications may execute, taking the context as input. Widgets, Aggregators and Interpreters register themselves with the Discoverer. When

(20)

an application is started, it contacts the Discoverer to locate the components that are relevant for it (Dey et al., 2001) (Korpip¨a¨a, 2005).

2.4.2 Client-Server

Hong and Landay(Hong and Landay, 2001) introduce a client-server-based approach for context management. The client-server architecture is more flexible compared to the widgets. In the client-server model the high-level components are separate and independent communicating entities. There is no central manager to keep track of services locally. Therefore, the components are more complex containing code to manage their connections. The cost of finding independent services and communicating with them is higher than in a centrally managed process. The Internet is one example of the client-server model. In the Internet, the client and the server can reside at different net locations and communicate using Internet protocols. In (Hong and Landay, 2001) authors give an example of the client-server-based approach aiming to simplify the tasks of creating and maintaining context-aware systems. They propose to shift the weight of context-aware computing onto network-accessible middleware infrastructures.

The advantages of the client-server architecture are identified(Hong and Lan- day, 2001) as

1. Independence from Hardware, Operating System, and Programming Lan- guage Support for greater range of devices and applications by using standard data formats and network protocols.

2. Improved Capabilities for Maintenance and Evolution Sensors, services, and devices can be changedindependently anddynamically with the help of the middleware layer that separates these from each other.

3. Sharing of Sensors, Processing Power, Data, and Services Devices and applications can be simpler since the burden of acquiring the needed context information can be placed to the infrastructure.

(21)

2.4.3 Blackboard

The blackboard architecture model is inherited from the Artificial Intelligence (AI) research(Englemore and Morgan, 1988). The viewpoint adopted in the blackboard model is data-centric while the viewpoint in the widget and the client-server models is process-centric. The messages are processed through the common shared message board, called blackboard. Processes can subscribe to receive messages matching a specified pattern. All the communication go through the blackboard and is managed by the blackboard manager manager, and thus the communicating components can be less complex than in client- server model. In the blackboard model the service discovery is not necessary.

Everything that can be done with the direct communication paths can be simulated by including an identifier for the path or its endpoints.(Winograd, 2001)

The S60 Context Framework and therefore the Context Exchange System is based on the blackboard model. Comparison of the models and justification of the chosen model is presented in the next section.

2.4.4 Comparison of Models

Winograd makes comparison of the presented models in (Winograd, 2001).

First he sets four criteria for comparison and justificates them

1. Efficiency The metrics being space and time. For the interactive applications the time-efficiency is more important. Given todays networking and processor speeds, the efficiency is not the bottleneck in most cases.

2. Configurability More difficult to measure but becoming more important all the time since computing has moved towards a network-centric environment with dynamic addition and removal of the processes. The weak point of the complex system designs is that when configured they work effectively but the maintenance by adding and modifying components is complex and sometimes not possible without rebooting the whole system.

3. Robustness Traditional error handling mechanisms do not scale to the systems of independent distributed components on a network. A robust

(22)

system must function with the components that malfunction, disappear, and are restarted

4. Simplicity Complex systems are used only by those, who have the dedica- tion and the motivation. The simplicity was the key to the success of the World Wide Web(WWW) since simplicity of the HTML and the HTTP protocols -over more powerfull predecessors- enabled more programmers to use it.

He then points out the contrasts between these three models

• The widget model is efficient with tight coupling and single manager control but the price is complex configuration and reduced robustness.

• The client-server model’s benefits are configurability and robustness.

The drawback with relatively large and complex independent process components are efficiency and configurability.

• The blackboard model is the most loosely coupled and new sources could be easily added, this leads to easy configuration. The simplicity is provided by the uniform communications path. The blackboard model is also robust. Its weakness is efficiency since every communication requires two hops (CS to the Blackboard, from the Blackboard to application) and the general message structure is not optimized to any particular kind of data or protocol.

Furthermore, Winograd compares a blackboard-based architecture called the Interactive Workspaces(Fox et al., 2000) with the widget-based Context Toolkit architecture(Dey, 2000) The result of this comparison is that the blackboard- based system offers simplified implementation since there is no need to set up connections to multiple components. There is always only one standardised communication link, from each component to the blackboard. He proceeds that the blackboard based architecture is suitable for most uses even when the communication is not so efficient, given the increasing processor speeds and the architecture that avoids the complexity of configuring point-to-point communication.

(23)

Winograd mentions that since the functioning of the system depends on the functioning of the blackboard component, it must be built as reliable as any operating system component. On the other hand the failure of other components has no critical effect on the overall functioning of the system. Also the centralized nature of the blackboard provides significant advantages one of them being the context history management, which would be much more complex for example using the widget based model.

Although Winograd(Winograd, 2001) arques that the blackboard model is the most suitable model for the context management, according to Korpipää(Kor- pipää, 2005) Winograd lacks the development and the evaluation of a context framework. Also Korpipää points out that Winograd does not address context recognition, common structure for context abstractions, context management API, application control and customization. Variety of context framework architectures(Chen and Finin, 2003)(Fahy and Clarke, 2004)(Kumar et al., 2000)(Mandato et al., 2001)(Minar et al., 2000)(Mitchell, 2002)(Ranganathan and Campbell, 2003)(Riekki et al., 2003)(Schilit, 1995)(Suomela et al., 2003) (Wang et al., 2004)(Yau and Karim, 2001) is presented in (Korpipää, 2005) and the following issues are pointed out:

• The prototypes and experiments are done on PC or laptop PC distributed environments when context info is processed in the environment infrastructure instead of the terminal.

• The lack of enabling and ease-to-use tool for the end-user development of the context-aware applications in a mobile device.

• The lack of real applications implemented in a real handheld mobile device.

Korpipää draws the conclusion that the related works(Chen and Finin, 2003) (Fahy and Clarke, 2004)(Kumar et al., 2000)(Mandato et al., 2001)(Minar et al., 2000)(Mitchell, 2002)(Ranganathan and Campbell, 2003)(Riekki et al., 2003) (Schilit, 1995)(Suomela et al., 2003)(Wang et al., 2004)(Yau and Karim, 2001) suggest the superior architecture for the context management, the blackboard model. He then introduces in his dissertation(Korpipää, 2005) a blackboard-based context framework addressing the mentioned issues. This Context

(24)

Framework is then implemented in a S60 device. Since the S60 Context Frame- work is the basis for the Context Exchange System designed in this thesis, we present this framework in the next section.

2.5 Context Framework

In the previous section the Context management models were presented and compared. This chapter introduces the Context Framework which is presented in Korpipää’s doctoral dissertation (Korpipää, 2005). According to Ko- rpipää the main metrics for choosing the blackboard architecture were robustness, configurability and simplicity. The requirements set for his blackboard- based software framework are

1. Concurrent context management in mobile device The main function of the context management system is to facilitate the use of the context for applications that are located in the mobile handheld device. The context framework must be able to handle the information acquired from the device’s internal and external sources. The external context information may come from both the local and global(Internet) infrastructure. The device’s internal context includes information received from the sources that are in the device. In addition, this requirement extracts the first requirement from (Mitchell, 2002), which emphasises that the application must withstand periods of disconnection from a networked context source. When the blackboard manager is in the device, the disconnection does not prevent the functioning of the application exploiting context.

The disconnection is seen by the application as having no changes in context from the networked sources.

2. Requirements for the application programming interface Any client is allowed to add the context into the blackboard and use it. The ’publish and subscribe’ mechanism must be provided to all clients in order to avoid polling of data or getting direct flow of raw data. This reduces the message traffic up to the application. The client must also be able to unsubscribe all the subscriptions it owns.

3. Flexibility in handling new contexts The Context Framework must be able to handle the new context types and values without changes to the

(25)

framework entities. It is possible that the source of the certain context will change and the application does not necessarily need to know about the change of the source. This is possible since the application always gets the context from the same blackboard.

4. Context abstracting and recognition The information acquired from sources, such as sensors, may require abstracting to be usable for applications.

It should be possible to recognize the context from multiple sources and time sequences. The recognition of the higher level context from the existing ones may be performed from the next basic cases of the input:

(a) Context recognition from a set of contexts, where the set can be the size of one or larger.

(b) Context recognition from context history. the recognition may be based on either the specified number of the latest contexts or a time interval.

The abstraction level of the data received by the context manager may vary. Next cases can be identified:

(a) Context Manager receives from the source event-based abstracted contexts that do not require further abstracting to be used by the application.

(b) Context Manager receives from the source event-based abstracted information that requires further abstracting. In this case the context recognisers can be used.

(c) Context Manager receives raw measurement data that is updated continuously and possibly with a high frequency.

5. Event-based communication of the context to the application The aim is to deliver events to the application, even though the source would measure or receive a continuous stream of data. There are two basic ways of dealing with continuous incoming data within the framework:

(a) Context Sources that receive information from the external sources simply forward it to the blackboard. The context abstracting and change detection will be performed after the Context Manager. This approach is feasible if the frequency of incoming data is low. The implementation of the Context Sources can be very simple in this case.

(26)

(b) Context Source itself performs the abstracting and change detection before adding the context to the blackboard. This approach is preferred if the frequency of incoming data is high.

6. Context database In order to maintain the availability of device applications to the context history in the case of reboot, a permanent storage for context information is needed. The most feasible solution for the storage is a terminal database, since the modern mobile devices contain sufficient capacity for the permanent storage. A networked database would cause problems what comes to disconnections, delays and bandwidth used. For performance reasons, the use of the permanent storage database provided by the Context Manager should be optional. The sensor-based applications utilising short-term active type of data do not require permanent storage. These could be for example those applying movement sensors.

Also for short life span data, the Context Manager should contain a fast cache memory, which has the history length of one for every context type.

7. Context caching The clients are not allowed to delete contexts from the context table because:

- it could still be needed by the other clients

- since the context can be any information from any source, the owner of the context is not always known.

Therefore the deleting is handled centrally. When the context table is full of the context types (the cache is full), a number of the types (including history, which length is also limited) will be deleted when new ones appear.

When the limit for contexts is exceeded the options to delete the contexts are:

- the least frequently used types

- those that have not been used in a certain time frame - those that have no subscribers

8. Time resolution of context Depending on the size of the blackboard and available resources, the maximum communication frequency for the continuous communication through the blackboard should be limited. The applications that require high frequency of continuous communication

(27)

should not use the blackboard. To reduce memory consumption, the history limit should be configured very short for the sources that produce continuous data.

9. Change detection When a new context value is received, the matching operation must be performed to see if it has changed from the previous one. If there has been a change, the subscribers to that context are informed of the change. In the simplest case, the context is represented by the string of characters, for example, and the change is detected using a simple string match operation. If the context is represented so that simple change detection is not possible, a separate change detector is required.

10. Context confidence The context information received by the Context Ma- nager can be imperfect, only partially true. It can be true with the certain probability, based on the evidence learned earlier. The data object representing the context is required to have the confidence attribute.

Hence the instances of the context information contain a property that describes the confidence of the instance. The confidence property can be used to express probability, fuzzy membership, or any other measure of uncertainty, depending on the case. The use of such confidence should be optional, since it may not always be available. The default value for the confidence should be true (one).

11. Context representation No changes to the Context Manager should be required, regardless of the syntax of the incoming context. However, common context properties should be defined to enable the use of the contexts through an API. The context representation should facilitate the use of the context with the API. The Context Framework must not strictly restrict the representation, but it must provide a template and the instructions for producing the contexts that allow the simplified use of, e.g., sensor-based data with the given API.

12. Application control The Context Framework is required to provide an API for programming context-aware applications. The context-based application control needs to be separated from the applications themselves.

The Context Framework is required to have an entity that enables the control of the applications based on the context events without modifying the applications.

(28)

13. Customization It is difficult to configure the behaviour of the device at the design time so that it meets the varying user demands in varying situations and configurations, which can change over time. Therefore, for the maximal simplicity, flexibility, and potentially wide spread of de- veloping context-aware applications, the end-user should have the ability to customize the way of interacting with the applications and external appliances.

From the requirements presented, the first Concurrent context management in mobile device and the last Customization are in the scope of this thesis.

The external context information is mentioned in the first requirement but is not extensively handled in Korpip¨a¨a’s dissertation. This is because the focus of his dissertation is on terminal context management, The context exchange over device boundaries was not implemented to the S60 Context Framework either. The main contribution of this thesis is providing the support for the context exchange between mobile devices in the S60 Context Framework. The implemented Context Exchange System supports also customization.

The Main components of the Context Framework are introduced in the next section.

2.6 Context Framework Architecture

The Context Framework consists of the Context Manager, the Application, the Context Source, the Context Abstractor, the Change Detector, the Applica- tion Controller and the Customizer. The Application Controller consists of the Script Engine and the Activator. An overview of the architecture is given in Figure 3 where the bi-directional communication is presented as solid lines and one-directional as arrows. The dotted lines from the Context Abstractor and Change Detector denote that these entities can also be implemented as scripts to be executed by the Script Engine. The Context Manager is the blackboard based central node of the framework. The Context Manager resides in the mobile terminal and provides the same interface for all entities including the applications. The Context Manager provides a publish and subscribe mechanism and a database. Instead of the Context Manager, the applications can also be controlled by the Application Controller. The Application Controller

(29)

can be customized with the Customizer. Each of the other entities can be implemented as either remote or local.(Korpip¨a¨a, 2005)

Figure 3: The context framework(Korpip¨a¨a, 2005)

2.6.1 Context Manager

The Context Manager is the central node of the handheld mobile device. The Context Manager stores the context information received from any source and serves it to the clients. The clients can produce and use the context information concurrently. The data can be requested by the context type or source.

The clients can subscribe to the various change notification services. The Con- text Manager provides a common API for the clients. The Context Manager blackboard is the common data space for communicating information between clients. The Context Manager blackboard is a context database where context values are stored. Each context type can have several values from the history.

The length of the history is restricted by specifying the number of the values to be stored. When the maximun amount is reached the number of the oldest values are deleted from the database.(Korpip¨a¨a, 2005)

(30)

2.6.2 Context Source

The Context Source connects the data source and the Context Manager. The source of the data can be device internal or external(see Table 1) as long as the information provided by it is correctly formatted for the Context Manager API. The requirements introduced in section 2.5 for the Context Framework say that the abstraction level of the delivered data should be high enough and the frequency low enough for good performance in a blackboard system. When dealing with the raw high-frequency data, the abstracting and change detection should always be performed before delivery. Otherwise, the abstracting or recognition should be performed in the context source when

• Raw data is not needed by any client

• The abstracting makes contexts easier or more efficient to use.

The Table 1 presents the three most common types of context sources according to where the information is coming from, and whether the type of the incoming data may change or not.(Korpip¨a¨a, 2005) The fixed type of context means that the origin of the source is known to produce always the same type of context.

The varying type of context -in turn- means that the type of the context coming from this origin can vary.

Table 1: Three types of Context Sources and their properties(Korpip¨a¨a, 2005) Context source Type(s) of context Examples

origin produced by the source

1. Device internal Fixed Device sensor, device profile, device settings 2. External Varying Bluetooth, cellular network,

RFID, other devices

3. External Fixed Bluetooth beacon

(e.g. weather station)

2.6.3 Context Abstractor

Context abstracting refers to the pattern recognition process up to and including either feature extraction or the classification phase. Context recognition

(31)

refers to the pattern recognition process up to and including the classification phase. Hence context recognition is also context abstracting. The Context Abstractor entity here refers to both of these processes which aim at producing human-understandable, easily usable descriptions of raw data.

The context abstracting and recognition can be implemented as a

• part of the context source

• separate entity

• Context Abstractor

• script executed by the Script Engine

For example, if we have a temperature sensor producing the temperature information as a voltage level, the abstraction level must be raised in order to get the human-understandable description of it. To perform the abstraction, the Context Abstractor can subscribe to this type. Each time there is a change in the subscribed type(s) the abstractor receives an indication and performs the abstracting and recognition raising the abstraction level. The abstracted context is then added back to the blackboard. The application can operate by using the higher level contexts without needing to know about the abstraction performed.

Plug-in Context Abstractors can be added and removed from the system on- line. Guidelines for the most performance-effective solutions are provided by Korpipää in his dissertation(Korpipää, 2005). From these guidelines it can be concluded that more overhead the abstraction causes, more likely it should be performed in the Context Source. For example, if the incoming data is raw, the type of the communication is continuous and the frequency is high then it should be abstracted in the Context Source. On the other hand, if the data is symbolic, the type of communication is event and the frequency is low, the data can be abstracted in the Context Abstractor.

(32)

2.6.4 Change Detector

The aim of the Change Detector is to reduce overhead caused by the context data processing. The idea is that only the relevant changes are provided to the rest of the entities in the chain of the context prosessing. There are five different options for implementing the Change Detector in the framework(Korpip¨a¨a, 2005).

1. Perform the change detection in the Context Source.

2. Perform the change detection in the Context Abstractor.

3. Use the Context Manager default change detection.

4. Use a separate Change Detector.

5. Implement the Change Detector as a script that is executed by the Script Engine.

The earlier the change detection can be performed, less overhead caused. In case there is a lot of raw data coming from the sensor while often the successive values remain unchanged there is no need to pass these unchanged values further but updated to the blackboard by the Context Source only when the change occurs. (Korpip¨a¨a, 2005)

2.6.5 Application Controller

The context-aware features can be implemented in the Context Framework either using the Context Manager API directly or using the Application Con- troller entity. The Application Controller can subscribe to the Context Mana- ger. The Application Controller then performs control actions when it receives indications about the changes in the subscibed context types. (Korpip¨a¨a, 2005) The Application Controller contains a script-based inference engine called Script Engine. The Script Engine can be used without implementing any executable code. The Script Engine enables describing context-based application actions as rule scripts. The rule scripts are text based Extensible Markup

(33)

Language(XML) scripts. A rule script can contain context types. The Script Engine can subscribe to the Context Manager for these types. When a change is indicated, the Script Engine evaluates the script and forwards the result of this evaluation to the Activator. The Script Engine can also perform simple abstraction and change detection by forwarding the evaluation result back to Context Manager blackboard. (Korpip¨a¨a, 2005)

The Application Controller contains also the Activator. The rule scripts include action expressions. When the rule is triggered the Activator launches designated application functions or system events based on the action expression. An action expression consist of the human understandable part and the machine executable function parameters. The human understandable part is visible to the user and the user can perform customization based on these action expressions.(Korpip¨a¨a, 2005)

2.6.6 Customizer

The Customizer is a tool for configuring the Application Controller. It can be used to connect the context events to the application actions i.e. inputs to outputs. The Customizer is targeted at end-user usage that lets the user define the context-action behaviour into existing mobile device applications at use time. The customized context-action features can be described as rule scripts that can be read by inference engine. The Customizer can generate such scripts based on the graphical descriptions given by the user. A tool for the rule script syntax verification and visualization of the rule logic and priorities is presented in Väyrynen’s Master’s Thesis (Väyrynen, 2007). This tool fulfills the 13th customization requirement set for the Korpipää’s(Korpipää, 2005) Context Framework.

2.7 Conclusion

So far, in this document, we have introduced Context awareness. As a conclusion, the relation between:

• The CAME

(34)

• The Context Framework

• The S60

must be explained. The CASA is part of the CAME. The CASA in the CAME is described as environment specific context provisioning system. The Context Framework introduced in Korpipää’s dissertation(Korpipää, 2005) has parts which are environment independent(frozen spots) and environment specific(hot spots). The Context Framework is suited to S60 platform using hot spots.

The resulting S60 Context Framework is also a CASA for S60 platform, S60 CASA. As mentioned in 2.3 the Context Aware Mobile Environment-section, the CASA is not mobile. Hence it resides on one device while the CP’s and the CAA’s can reside on the same device with the particular CASA or as well on some another one, as depicted in Figure 4 At the moment the S60 CASA lacks support for exchanging context with other S60 CASA’s. Thus -for example- the CAA1 can receive the context information only from CP2 and from CPn.

After we provide the support for the context exchange between devices, the CAA1 can receive the context as well from the CP1.

For providing the support, the communication channel must be chosen to be used for context exchange. The next section discusses mobile environment and answers also the research question 4:

What would be suitable communication channel for context exchange?

Figure 4: Context Exchange

(35)

3 MOBILE ENVIRONMENT

Mobile environment consist of the mobile devices using wireless communication. When the devices are mobile and connected and the computing is taking place in the separate computing entities, it can be called distributed computing. When mobile devices are using distributed computing, wireless communication is needed. These are explained in this section.

3.1 Distributed Computing

A distributed computing model means a programming model where the services, the data and the algorithms are run on several computational entities.

The purpose of the distributed system is sharing of the resources. This means e.g. dividing one bigger task to a smaller ones to be performed by many computers. The distributed system provides a transparent view to the underlying distributed systems, components and hardware, so that it appears to the user like one system, as Tanenbaum and van Steen(Tanenbaum, 2002) define it

a distributed system is a collection of independent computers that appears to its user as a single coherent system

The distributed system can be seen very loosely coupled from the definition by Coulouris et al. (Coulouris et al., 2001)

a system in which hardware or software components located at networked computers communicate and coordinate their actions only by passing messages

3.2 Mobile Device

A mobile device has limitations, due it’s smaller size, in comparation with stationary and infrastucture-centric computing. These are identified in (Kor- pip¨a¨a, 2005) as

(36)

1. less computing power 2. less memory

3. restricted network access 4. smaller screen

5. restricted input capabilities 6. limited battery capacity

These are emphasized by mobility. Long sleep mode periods are not possible since the location and situation can be constantly changing. Access to a network must be wireless and the signalling through the air consume more power than the use of wire.

3.3 Wireless Communication

There are lot of options for the wireless communication and these can be divided to

• radio frequency communication(3Hz-300GHz)

• infrared(IR, electromagnetic radiation whose wavelength is longer than that of visible light, but shorter than that of microwaves)

Moreover the part 300 MHz-300GHz of the radio frequency communication is defined to be microwave communication. In the scope of this thesis are the most common wireless communication techniques available for a mobile phone.

These are shortly introduced. The IR is left out because it needs visual contact between devices hence setting up IR connection and maintaining takes too much user effort. The requirements set in section 5.1 for the Context Exchange System state that the exchange should work with minimal user effort.

The mobile phone standards 1G, 2G, 3G and 3G evolution (pre-4G) are based on the International Telecommunication Union (ITU) family of standards. The

(37)

networks up to 2G were built mainly for the voice data and slow transmission. 3G technologies enable network operators to offer users a wider range of more advanced services. Services include wide-area wireless voice telephony, video calls, and broadband wireless data. Additional features also include the High-Speed Packet Access(HSPA) data transmission capabilities able to deliver speeds up to 14.4Mbit/s on the downlink and 5.8Mbit/s on the uplink. On a way from 2G to 3G there are also 2.5G and 2.75G which are technologies like high-speed circuit-switched data (HSCSD) and General packet radio service (GPRS) that provide some functionality domains like the 3G networks, but without the full transition to the 3G network. The Universal Mobile Telecom- munications System (UMTS) is one of the third-generation (3G) cell phone technologies.

The Wireles Local Area Network(WLAN) has several standards where the data rate is from 9600 kb/s up to 54 Mbit/s with the latest two standards 802.11a (5 GHz) and 802.11g (2.4 GHz). The WLAN needs an access point and infrastructure. The coverage of the one access point is couple of tens of meters. For the wider coverage a network of wlan access points is needed.

This gives the users the mobility to move around within a broad coverage area and still be connected to the network. The WLAN is just becoming common in mobile phones. In some cases the use of the WLAN can be free, for example some cities provide WLAN access in their area. One example is panOULU (pan is for public access network) in the area of the city of Oulu.

[http://www.panoulu.net/]

The Bluetooth is at the moment available very widely in mobile phones. It is an open communication standard for the devices in short range and is mainly used for the wireless personal area networking(WPAN). It uses the 2,4 GHz ISM(Industry, Medical, Science) unlicensed frequency. More accurately: the Bluetooth uses frequency hopping in the area 2,4000-2,4835GHz. The frequency is changed 1600 times per second. The Bluetooth can use 79 separate channels frequency shift being 1 MHz. The first Bluetooth standard 1.0 was published 1999. There exists also the standards 1.1, 1.2, 2.0 and the latest 2.1 published on July 2007. Main improvements between the different versions are higher data rates with less power consumption. The Enhanced Data Rate (EDR) was introduced with the standard 2.0 for faster data transfer. The nominal rate of the EDR is about 3 megabits per second. The Bluetooth standard 2.1 offers the Secure Simple Pairing when pairing should be possible by

(38)

just bringing 2 devices close to each other.

Bluetooth has 3 device classes (see Table 2). Device class 2 is used in mobile phones.

Table 2: Bluetooth device classes Class Maximum Permitted Power Range

mW(dBm) (approximate)

Class 1 100 mW (20 dBm) 100 meters

Class 2 2.5 mW (4 dBm) 10 meters

Class 3 1 mW (0 dBm) 1 meter

There exist also a ultra low power Bluetooth technology called the wibree, which is part of the Bluetooth specification. Main applications include devices such as wrist watches, wireless keyboards, toys and sports sensors where the low power consumption is the key design requirement.

The technology intended to be simpler and cheaper than other WPANs -such as Bluetooth- is theZigbee [http://en.wikipedia.org/wiki/Zigbee]

The Bluetooth as a communication channel was chosen for this work because it is commonly available on mobile phones and it can be used without charge.

Also no infrastructure needed, so when there is another mobile phone available for context exchange, there is most likely the communication channel available for this. The basics of the Bluetooth -which are in the scope of this thesis- are explained here.

• Slave A slave is a device that listens to incoming connections and adver- tises its available services. A slave cannot establish any connections.

• Master A master is a device that establishes the connections to remote devices, slaves. The master discovers slave devices and their services and is capable of connecting to a multiple slaves and holding these connections active simultaneously.

• Device discovery In the device discovery the master inquires for the Blue- tooth devices within range.

• Service discovery In the service discovery the master inquires the discov- ered Bluetooth devices for the services they offer.

(39)

• Connection establishment The master device is able to establish connection to the slave’s listening channel/port. Once the connections are established, the messages can be sent from the master device to the connected slaves, and vice versa, from a slave to it’s master device.

• Bluetooth piconet The Bluetooth ad-hoc network where the master can have simultaneous connections (point-to-multipoint) to up to seven slaves.

Formed by the slaves advertising services they offer and the master per- forming device/service discovery and connection establishment

(40)

4 DISTRIBUTED CONTEXT AWARENESS

The sections Context Awareness and Mobile Environment can be concluded to a term distributed context awareness.

Distributed computing helps what comes to the restrictions of the mobile device. Resources can be shared using the software and the hardware components located at connected computers, which communicate using messages. The context exchange can be done using messages. Acquisition of the context may take computing power, consume memory, need some hardware and need some network access that one single device does not have. Use of all these resources consume also battery. Since we are talking about mobile devices, wireless communication is the only possibility. Even the small screen size can be tackled by using perhaps a significantly larger screen of a laptop(if one is available in the context of the device) in comparation to the mobile phone. Or one could even play Tetris on a screen formed by the windows of a 12 store high block building. This was actually done in Tampere Finland starting on 4.12.2007.

Technical students of the Tampere University of Technology used the windows of the block house called Mikontalo [http://www.mikontalolights.fi/] as a screen. The object ofmikontalolights project was to create the world’s physically largest, colored graphics platform. This was realized by placing LED lamps in the empty rooms of the building under renovation. The audience of 2000 people was able to play tetris or show graphics on this screen using their mobile phones (see Figure 5). Possible connection methods were WLAN and Bluetooth. This was possible because there was a large screen and a for using it in the context of the mobile phone.

4.1 Definition

The Distributed Context Awareness can be defined as an ability of an application to dynamically change or adapt its behavior according to the context acquired from other devices. With push aspect of context awareness this can mean that one device can change other device’s behaviour by passing context to it. Correspondingly withpull aspect if the device is not cabable of producing some contexts needed for it’s applications to function, it can request these contexts from other devices

(41)

Figure 5: Mikontalolights

The Distributed Context Awareness could also be expressed as a device’s ability to ’see’, ’hear’ and ’feel’ using contexts acquired from other devices.

4.2 Examples

Couple of examples on the Distributed Context Awareness are presented below.

In addition to the described ’block house as a screen’-case the other push example case could be that a lecturer starts a context exchange session with the context-aware mobile phones which the audience has with them. At the beginning, the lecturer changes his/her phone profile to silent or meeting and the context aware lecturer application sends its profile to other connected devices.

Other devices then change also their profile accordingly. When the lecture ends and the lecturer changes his/her phone profile to, for example, general this profile is again sent to other devices and their profiles changed accordingly. One more example could be that there could also be device connecting to phones carried by persons who are entering to hospital or airplane and send-

(42)

ing appropriate context which causes a suggestion for switching the phone off to appear in persons mobile phones.

The example case for the pull aspect could be that the context-aware application of one device needs location context as GPS coordinates and this device does not have a GPS receiver. Possible there is another device with a GPS receiver available in near to the device and the location context as GPS coordinates -and updates to it- can be ordered from this other device.

The design and implementation to realize context exchange between devices in mobile environment including use cases described above is presented in the next section.

(43)

5 THE CONTEXT EXCHANGE SYSTEM

In the literature review, in section 3.3, we have already provided answer to the third research question: What would be suitable communication channel for context exchange? The chosen communication channel was the Bluetooth because it is commonly available on mobile phones and it can be used without charge. Also no infrastructure needed, so when there is another mobile phone available for context exchange, there is also most likely communication channel available for this. Moreover, since the range of the Bluetooth is limited, the devices connected using bluetooth share more or less the same location and most likely also the situation. This can be seen as an advantage in certain cases. For example, if there is a lecture beginning, the lecturer could order all mobile phones in the range to go silent, thus realizingpush aspect of context awareness. The assumption here is that all users of the mobile devices in the range are participating the same lecture. Or, with thepull aspect, the mobile phone -carried by the member of the audience- could infer the lecture by asking profiles from other devices. Same applies to other similar cases, the meeting situation being among them.

In this section we provide the answer for the first research question: What would be the efficient software architecture for the exchange of context information between mobile devices by presenting the design and the architecture of the Context Exchange System. The system is needed for enhancing the existing S60 Context Framework to provide distributed context awareness. The distributed context awareness is achieved by providing context exchange possibility between devices in mobile environment.

The following provides the requirement specification in subsection 5.1. The subsection 5.2 provides detailed descriptions of the use cases. The class diagram is in subsection 5.3 followed by the Class descriptions in the subsection 5.4. The operations with the sequence diagram are presented in 5.5. This section is ended to the architecture description in 5.6

Context exchange between devices in mobile environment