a framework for mobile context-aware applications

BT Technology Journal • Vol 25 No 2 • April 2007106

A framework for mobile context-aware applications

S Johnson

This paper presents a framework for the rapid development of context-aware applications for mobile devices. We introducethe concept of a context fingerprint which is a characterisation of the context that a mobile terminal can determine from thesensors available to it. These sensors not only include the obvious RF transmitters such as Wi-Fi, GSM and Bluetooth, but alsoany device state information that is accessible through the operating system’s APIs, such as device profile or battery level. Theproposed framework allows a number of context fingerprints to be defined, together with events and actions that are fired ontransition between contexts. Context-aware applications can be created simply by defining the key elements in a mark-upscript that is loaded into an implementation of this framework.

1. IntroductionThe field of context-aware computing has long beenconcerned with developing truly intelligent systems — onesthat react appropriately by understanding the circumstancesin which they and their users operate. A major goal yet to befully realised in the context-aware vision is that of ubiqui-tous awareness of location. A system that is continuouslyaware of location can provide users with many benefits, suchas the timely delivery of information at the point and place itis most relevant.

Over the years, many platforms have been developed toinvestigate pervasive and context-aware systems, one of theearliest forays into this area being Xerox PARC’s ParcTabproject [1, 2]. The system comprised custom-made hand-held mobile computing devices called ParcTabs. EachParcTab was connected to the local network through infra-red (IR). Due to the limited range and the fact that IR signalsdo not penetrate through walls, the device’s location couldbe determined to the room level. Applications used thisinformation to provide features such as location-based Post-it notes and contextual reminders. The ParcTab project wasthe inspiration for many other context-aware systemsincluding frameworks for context-aware applicationdevelopment. The Stick-e Document [3] is an early exampleof such a framework and in many ways it is similar to whatwe are trying to achieve. Its premise is that a context-awareapplication can be described by a portable document thatidentifies contexts and associated content. The targetdevices that receive this context document have a pre-installed application running on them that can match thecontexts and render the associated content. The motivationfor this work was to make context-aware applications as

simple to develop as Web pages. Dey et al created a contexttool-kit [4, 5] to enable developers to build distributedcontext-aware systems. The tool-kit introduced the conceptof context widgets that had a common interface thatenabled other components to subscribe to sensor changeevents as well as retrieve other information such as contexthistory. The tool-kit offered other components to facilitateaggregation, mediation and interpretation of widget output.Georgia Tech’s Aware Home [6] provides a fine example of asystem built on the context tool-kit. Similarly, theContextPhone [7] is a platform for application prototypingtargeted specifically at Symbian and Nokia Series 60smartphones. There are many research projects that haveused the ContextPhone to investigate social networking andinteraction, such as the MIT reality mining project [8].

In this paper, we present a generic framework for context-aware applications that, like the Stick-e Document [3],enables applications to be defined by a mark-up script. Ourmotivations for this work are twofold:

• to provide a mechanism for third parties to explore andquickly develop innovative context-aware applications,

• to understand the current boundaries placed oncontext-aware applications by device and technologylimitations.

The initial target platform for this work is a WindowsMobile 5 smartphone (Fig 1), as not only are these becomingubiquitous, but they are increasingly used for a multitude oftasks and hence provide a great opportunity for enhancingthe user experience by exploiting context. The main reason


BT Technology Journal • Vol 25 No 2 • April 2007 107

for choosing a Windows Mobile device is the .Net CompactFramework development ecosystem which currently offers arich and extensive open API that provides access to many ofthe device’s key capabilities. Other development platformsoffer much narrower APIs with limited visibility of devicesensors, and in some cases access to essential APIs arestrictly controlled by either the device manufacturer or theoperator as they are deemed to be commercially sensitive.

2. Sensor technologiesAt the heart of any context-aware system lie sensors thatobserve the environment and provide state information forthe application logic. Mobile devices provide an increasinglyrich set of sensors for any context-aware application. Thelatest smartphones combine GSM, Wi-Fi (IEEE802.11),Bluetooth and GPS radios together with cameras, and evenRFID and motion sensors. Additionally a huge amount ofcontext information can be derived through the operatingsystem APIs, such as battery level, memory and CPU usage,applications running and call details.

One of the key attributes in which many context-awareapplications are interested is location. The most obvious wayfor an application to discover its location is through GPS if itis available. However, GPS does have its limitations — it doesnot work indoors and performs poorly in urban canyons. Fortruly ubiquitous location determination a combination oftechniques must be used.

Location does not necessarily need to be a geographicco-ordinate as specified by a latitude and longitude, it maysimply be a tag that represents a location such as ‘office’.With so many different radios available on modern devices,each having their own propagation characteristics, there aremany options as to how location can be determined.Visibility of a particular radio transmitter will indicate that

the device is within a certain radius of that transmitter, theradius being determined by the radio type, e.g. typically10 m for Bluetooth, 100 m for Wi-Fi, etc. In many cases, just‘seeing’ the transmitter is all that a context-awareapplication requires; however, if a geographic co-ordinate isnecessary, then an approximate location may be determinedif the geographic co-ordinate of the transmitter is known.

Improved location accuracy can be derived throughobserving multiple transmitters at a location. For example,the location, ‘office’, might be characterised by a couple ofWi-Fi access points and a number of Bluetooth devices. Wecall this a location fingerprint as it captures the significantradio transmitters that uniquely represent a location as far asa context-aware application is concerned. Even greaterlocation accuracy can be achieved by employingtriangulation techniques on the observable radio trans-mitters to determine a geographic co-ordinate. In thisapproach, it is necessary to maintain a database of knowntransmitters together with their geographic location. It isthen possible to calculate the location of the device by usingthe transmitter positions combined with their respectivesignal strengths. Place Lab have pioneered research in thisarea [9] and conclude that in areas where client devices seeat least three Wi-Fi beacons within a 10 sec interval, medianaccuracies of 10—15 m can be achieved. A comprehensivereview of positioning technologies can be found inMannings [10].

In addition to the standard sensors on a device, it ispossible to produce new virtual sensors by manipulatingmeasurements taken from the physical sensors. The RFtriangulation technique described above to determine ageographic location is a fine example of a virtual sensor. Onecan envisage other virtual sensors such as a motion sensorbased on changes in visible RF transmitters — anaccelerometer approach is unlikely to detect motion over theground when in a vehicle. A busy sensor could be derivedfrom various cues taken from the device, such asapplications running, call in progress, etc.

3. FingerprintsA location fingerprint is described by a set of features thatcan be observed by a mobile terminal at a specific location(Fig 2). Each feature typically identifies a radio transmitterthrough its network ID (e.g. MAC address or cell ID) and mayalso include an anticipated signal strength. One of the issuesassociated with matching fingerprints is the potentiallytransient nature of the features. As the fingerprintingapproach may rely heavily on an open source infrastructure,there is little control over the availability and identifiabilityof individual transmitters. For example, the access pointsmay be switched off at weekends or the hardware replaced.To counter this, we need to use a matching algorithm thatwill accommodate this behaviour, and potentially can learnand adapt to longer term transmutation of the fingerprint.

Fig 1 Qtek 8310.



This is one of the areas that we intend to explore with theframework proposed here.

In this paper we extend the idea of a location fingerprintto include the additional context a device may observe — acontext fingerprint. A context fingerprint represents asignificant and unique characterisation of a context in whichan application is interested. One additional attribute of thecontext fingerprint is the possibility to identify features thatmust not be visible. For example, the location ‘office’ can be

described by the visibility of two Wi-Fi access points as wellas not being able to observe a specific Bluetooth device.

4. Context activation engineThe context activation engine (CAE) is essentially a processthat runs on a mobile terminal — its purpose is to executeactions based on the device’s context transitions. It is readilyconfigurable through an XML mark-up file that defines thecontexts, events and actions that make up a context-awareapplication. Its main components are identified in Fig 3.

Fig 2 Location fingerprints.

airport

bus station

Fig 3 Context activation engine.

sensordatabase

fingerprints

contexts

events

rules

actions

contextdatabase

virtualsensors

compoundevent

compoundevent

context matcher

sensors

activationengine

contextevent

actions

contextobservation

mark-upscript

sensorscan



The context database is a repository for all of theelements that make up a context-aware application. Theseelements are briefly described below.

• Fingerprint

This is the primary component that the CAE is trying tomatch.

• Contexts

A device can be said to be in a specific context whenmatches are found against one or more associatedfingerprints. The relationship between a context and itsfingerprints is described by the context’s conditionexpression. This expression is a simple logical statementthat allows matches to fingerprints to be combined,e.g. ‘fingerprint<id=1> | fingerprint<id=2>’ impliesthat the context is true if either fingerprint has beenmatched. In its simplest form, a context is a fingerprint.

• Events

Events define the context transitions in which anapplication is interested. There are two types of contextevent that the CAE supports:

— unary events that relate to a single context transitionsuch as an entry into the context or exit from it,

— compound events which match ordered or un-ordered sequences of events and are potentially timebound.

• Actions

Actions are the tasks that the application shouldperform in response to seeing a context event. Theseinclude sending a message, downloading anddisplaying multimedia content, running an applicationor altering the device configuration.

• Rules

Rules associate an event with a sequence of actions thatshould be executed when the event is observed.

The CAE monitors its sensors periodically. The frequencywith which it does this may depend on the nature of theapplication as well as the sensor type. Sensors, together withthe features that they observe, have different characteristicswhich may dictate the scan frequency; for example, GSMcells have large coverage and are therefore unlikely tochange regularly. Conversely, Bluetooth, which has a muchlower range, should be scanned more frequently, but due tothe nature of the Bluetooth protocol, the scanning processitself takes a significant amount of time. Another factor thatmay govern the scan frequency is the power consumption ofthe sensor. Wi-Fi and GPS radios are currently very powerhungry and so an application that requires frequentscanning of these sensors will have a huge impact on the

battery life of the device. The context activation engine willemploy two strategies for attempting to minimise this powerconsumption:

• a list of all sensors that are required to match thefingerprints is maintained — only these requiredsensors are enabled and scanned periodically,

• an incremental match will be performed against thesensors starting with the lowest power consuming onesfirst — any fingerprints that fail to match against aparticular sensor will be excluded from the matchingprocess in an attempt to reduce CPU consumption.

The observations captured by the physical sensors areprocessed by any virtual sensors that have been registeredwith the CAE. The output from the virtual and physicalsensors are combined to produce a context observation thatrepresents the current device state.

The context matcher receives the context observationand performs the following steps:

• match the observation against all fingerprints in thedatabase,

• determine in which contexts the device is by evaluatingeach context’s condition expression against the suc-cessfully matched fingerprints,

• identify the context transitions by comparing the newset of device contexts against the previous set,

• search the database for event definitions that cor-respond to these context transitions and generate aunary context event for each match,

• if any unary events are generated, the matcher thenlooks at the recent history of events (both compoundand unary) in order to determine whether newcompound context events should be triggered.

All generated context events are propagated to anactivation engine, the role of which is to retrieve rules thatcorrespond to each event and then process the associatedsequence of actions. When firing the actions, the activationengine has to manage:

• synchronous and asynchronous execution of the actionsas specified by the action definition,

• running actions either in sequence or simultaneously,

• handling of errors generated by the actions,

• prerequisites being satisfied, such as network con-nectivity, prior to running an action.



5. Application creation toolsSo far we have discussed a framework for runningapplications on a mobile terminal. One important aspect ofthe framework that should not be overlooked is how wecreate the application scripts that are loaded into it. A simpleapproach here would be to provide an editing tool on thedevice through which a user could capture the fingerprintwhen in the context or location of interest and thenassociate actions with it. This mechanism would not reallylend itself to creating the rich and complex applications thatthe framework can support, primarily because of therestricted user interface that a device-based editing toolwould present. A novel approach for determining locationfingerprints is to use a PC-based tool that combines aninteractive map together with a database of RF beacons andtheir location. Selecting a point on the map would initiate asearch to find transmitters that would be visible at thelocation. Events and actions could then be associated withthe calculated fingerprints before the application isdeployed to the device. A graphical tool would also simplifythe process of creating sequences or compound events asthese would be much better understood throughvisualisation. The key component in such a tool is thedatabase. There are a number of open source projects thatare attempting to build Wi-Fi access point databases,wigle.net [11] being the most notable. These projects arelikely to grow in number, scale and reach as wireless devicepenetration increases. In an implementation of such a tool, itis likely that these wireless databases would be augmentedwith personal context information harvested from the user’sdevice.

A family context manager is an interesting scenario thatcan be built on the interactive creation tool described above.It provides a good example of how the context activationengine framework can be used and extended to help co-ordinate family activities. A central management facilitycaptures, manages and co-ordinates the different contextsof the family members and deploys family member tailoredmark-up scripts to the CAE process running on their devices.Micro applications could include:

• SMS containing the current location/context of thedevice when its battery is low,

• send message to indicate that a family member hasarrived at/left a location,

• latest shopping list appearing on parent’s device onarrival at a supermarket,

• automatic switch to voicemail when the phone is in acar,

• personalised location-based directions and routeguidance,

• contextual reminders.

6. Future workThe context activation engine provides a ‘self-contained’framework for applications where all sensing and processingis performed entirely on the mobile device. This assumesthat devices are sufficiently powerful to be able to carry outa large number of matching calculations at regular intervalswithout adversely affecting the device’s responsiveness,together with having a large storage capacity for holding themany fingerprints, events, rules and actions required byapplications.

A less computationally intensive alternative toperforming all calculations on the device is to send thesensor information to a network-based server to determinethe context. When an appropriate context transition isidentified, messages are sent to the device informing it ofthe specific actions that it should take. This effectivelyremoves any restrictions on the complexity of the match andthe size of the context database, and also has the significantadvantage that the context can be extended beyond thatvisible solely on the device. It may also help to extend therange of devices supported as some inaccessible sensorinformation, such as cell ID, may be acquired through thenetwork. However, this approach has a few significantdisadvantages. Firstly, the need for frequent delivery ofsensor information to the network would prove costly.Reducing the amount of data sent would result in decreasedresolution and potentially limiting the number of usefulapplications. Secondly, this approach requires reliablenetwork connectivity at all points of interest to anapplication, and, finally, delivering all sensor output to aserver would prevent the implementation of the powerefficiency strategies described earlier, with the consequenceof reduced battery life. There may also be significantreluctance on the part of users to have such large amountsof personal context information delivered into the network,no matter how secure it is.

A hybrid approach that distributes the matchingbetween the device and network appears to be the obviousway forward and is the direction our future work in this areawill take. It has the benefit of providing the broader contextas well as reducing the load on devices by configuring themto match within their capabilities. The server only receivespartial-match messages from a device which it thencombines with its own context observations to complete thematch. The areas that we have identified here that meritfurther investigation are:

• extending the framework to support distributedcontext-aware applications that potentially includemany devices,

• mechanisms for creating, deploying and updating theseapplications,

• addressing the many issues that burden distributedmobile applications, such as availability, as identified by



Beddus et al [12] — some of the ideas described in theirconverged Web Services concept may well beappropriate here.

7. ConclusionsMuch of the previous work carried out in the context-awaremiddleware arena has been undertaken on closed orcontrived systems that require the support of specifichardware or infrastructure. It is only recently, with theavailability of more open and highly connected devices andincreasingly pervasive networks, that these systems are ableto become mainstream. We have presented a frameworkthat takes advantage of these trends and enablessophisticated context-aware applications to be easilycreated and deployed to a device. This framework not onlyallows applications to respond to immediate changes incontext, but also enables them to modify their behaviourbased on recently observed context transitions. It is ourintention to now use this framework as a rapid prototypingplatform for the creation of innovative applications as well asto better understand the current limitations placed oncontext-aware applications by the technology.

References1 Want R, Schilit B, Adams N, Gold R, Petersen K, Ellis J, Goldberg D and

Weiser M: ‘The PARCTAB Ubiquitous Computing Experiment’, (CSL-95-1), Technical report, Xerox Palo Alto Research Center (1995).

2 Schilit B, Adams N and Want R: ‘Context-Aware ComputingApplications’, IEEE Workshop on Mobile Computing Systems andApplications (1994).

3 Brown P J: ‘The Stick-e Document: a Framework for Creating Context-aware Applications’, in Proceedings of EP’96, Palo Alto, pp 259—272(1996).

4 Dey A, Salber D and Abowd G: ‘A conceptual framework and a toolkit forsupporting the rapid prototyping of context-aware applications’, inMoran T P and Dowish P (Eds): ‘Context-Aware Computing: A specialtriple issue of Human-Computer Interaction’, Lawrence-Erlbaum(2002).

5 Dey A K and Newberger A: ‘The Context Toolkit — A toolkit for context-aware applications’, (2001) — http://contexttoolkit.sourceforge.net/

6 The Aware Home, Georgia Institute of Technology — http://www-static.cc.gatech.edu/fce/ahri/

7 Raento M, Oulasvirta A, Petit R and Toivonen H: ‘ContextPhone: APrototyping Platform for Context-Aware Mobile Applications’, IEEEPervasive Computing, 4, No 2, pp 51—59 (2005).

8 Eagle N and Pentland A: ‘Reality mining: sensing complex socialsystems’, Personal and Ubiquitous Computing, 10, No 4, pp 255—268(2006).

9 Lamarca A, Chawathe Y, Consolvo S, Hightower J, Smith I, Scott J,Sohn T, Howard J, Hughes J, Potter F, Tabert J, Powledge P, Borriello Gand Schilit B: ‘Place Lab: Device Positioning Using Radio Beacons in theWild’, Pervasive, pp 116—133 (2005).

10 Mannings R: ‘Whereness: Ubiquitous Positioning’, The Journal of TheCommunications Network, 4, Pt 1, pp 38—48 (2005).

11 Wigle.net — http://www.wigle.net/

12 Beddus S, Hosking M and Roxburgh D: ‘Examining the role of terminalmiddleware in convergence applications’, BT Technol J, 25, No 2,pp 112—119 (April 2007).

Stephen Johnson joined BT's laboratories atAdastral Park in 1989 after graduating withan honours degree in Electronic Com-munications Engineering from the Universityof Hull. He spent his first spell at BTresearching statistical speech recognitionalgorithms as well as developing innovativeinteractive voice demonstration systems.During this period he delivered key algorithmsinto BT's Callminder service. After a six year spell working for a couple ofstart-up companies, he rejoined BT's MobilityResearch Centre to investigate context

awareness as an enabler for mobile applications and services.

He is a Chartered Engineer and a member of the IET.

a framework for mobile context-aware applications

Documents