Issues in Triggering

Many context-aware applications will utilise the available context information in a reactive manner. That is, they will adapt or enhance some aspect of their behaviour based on changes in their current context. The stick-e note framework enables such behaviour with its triggering model, where stored stick-e notes whose context matches that of the current environment will be triggered and delivered to clients who are interested in them. In effect it facilitates a contextual form of event driven programming where the context of the stick-e note determines when the event should occur and the content of the stick-e note determines the type of event or reaction. It is

entirely up to the client to create and utilise the latter, in the case of the electronic Post- It note the content was a textual note that was displayed on the screen when it was triggered. However, it could just as easily be some executable content that is run when triggered, e.g. an environmental control system that turns off the lights when a room becomes vacant.

Although useful in many applications, triggering is not the only way of utilising context. Some applications may be more interested in a continual monitoring of context, such as continuously showing the current value of a context element, e.g. the current time, temperature, or location. Triggering, and the stick-e note framework in general, also attempt to hide or abstract context information from the client and/or user. This is an incentive for many applications/users as they wish to concentrate on their application- specific functionality and data, with contextualisation provided transparently via the triggering mechanism. However, there are some tasks in which the application or user desire to be actually immersed in the context information, where triggering and stick-e notes in general may not be so helpful, e.g. an interactive electronic mapping program. In developing the stick-e note framework we have deliberately focused our efforts on supporting the reactive/adaptive type of applications, exploring how a triggering service can be operated and provided.

The trigger process that we developed for the framework prototype operates as anticipated but has highlighted a number of inefficiencies that could be addressed in the future. One of the main concerns is that a trigger checking cycle is quite slow in execution, especially on the resource-starved handheld computer. It is the extraction of context data from the physical sensor devices, in particular from a GPS receiver with the electronic Post-It note program, which is the primary cause of delay. Every time the framework needs to check if a stick-e note’s location matches the current location, the attached GPS receiver is consulted. This is performed by the GPS sensor device class that listens in to the communications port that it believes the GPS receiver is attached to, watching out for the location information in the NMEA data [Bennett 2000 - #10] [NMEA 2001 - #92] that is intermittently broadcast by the GPS receiver. The time delay lies in the intermittent nature of data broadcast, where a period of one or two seconds can pass by before the next set of data is transmitted. Often the delay is much smaller than this, but, for example, with one or more location context elements in each

Chapter 2: Stick-e Notes - a Metaphor for Context-Aware Applications

of a group of twenty or more stick-e notes, the delays can soon mount up.

Unfortunately this delay is out of our control: it is a predetermined setting of the GPS hardware that will be incurred irrespective of whether we model sensor devices in a hierarchy or as autonomous sensor monitors (as we proposed in the previous section). However, what can be enhanced is the framework’s method and frequency of interaction with a sensor device. At present, the current location is retrieved every time a location context element is checked, ensuring that the most up-to-date location data as possible is used. However, the amount of time between the individual checks of stick-e notes in a matching process is very small (if we exclude the GPS data extraction time) and hence the location is unlikely to change by any significant amount in that short space of time. Therefore we could simply retrieve the location data once per triggering cycle and cache the value so that the checks could be performed using this cached location instead of extracting the location direct from the physical GPS receiver each time.

This caching method could be further enhanced using the proposed autonomous sensor monitors. Each monitor could keep a cache of the most recent location data (or whichever context element is being captured) and could pass this cached value to the

SeEnvironment on demand. However, unlike a SeEnvironment based cache that

would be updated each time the matching process was performed, the monitor’s cache could be kept for an indefinite period without requiring an update. The monitor could employ a more advanced cache refresh strategy so that it is only updated when necessary, not at arbitrary periods defined by the trigger checking frequency. Clients may have a quality-of-service arrangement whereby the monitor will examine the GPS receiver just enough times to keep within the specified location granularity, e.g. to keep the location updated so that it is always within 50 metres of the actual GPS receiver’s current reading. The monitors could also adjust their sampling rate so that if, for instance, they detect the speed of movement is increasing then they can increase their sampling rate of the GPS receiver in order to keep within the quality of service threshold, and vice versa. As the autonomous sensor monitors are constantly running in the background as independent processes, they could also schedule their access of physical sensor devices for times of low processor load to further reduce the bottleneck

surrounding the matching process. Caching can also help in estimating the current value of a sensor that is temporarily not working, e.g. a GPS receiver in a tunnel.

Through autonomous sensor monitors the process of capturing current context for use in trigger checking can be made much more efficient, but we also need to consider the broader perspective of how the to improve the trigger checking cycle as a whole. Currently a manager component in the framework is configured to perform a trigger checking cycle of a specified number of stick-e notes at specified intervals, i.e. it is a static timer driven process. If the current context or stick-e notes have not changed since the last trigger cycle then this is a redundant activity as we already know what stick-e notes will and will not trigger in such circumstances. More subtly it is also a redundant activity if the current context or stick-e notes have not changed enough, i.e. not enough to cause any differences in triggering. This redundancy is as a result of the trigger checking process being designed around a polling mechanism rather than an event driven one.

The trigger checker could be converted an event driven mechanism with the introduction of the autonomous sensor monitors. The SeManage could register an

interest threshold in a context element, causing any autonomous sensor monitor producing such a context element to send a notification message if the threshold were exceeded. For example, consider a wildlife guide family of stick-e notes on an African game park visitor’s GPS-enabled handheld computer. The SeManage may deduce that

none of the stick-e notes is going to trigger until the user has reached the park gate. Therefore it could tell the GPS sensor monitor to not inform it of the location until within a certain distance of the entrance gate, and only then need it start trigger checking. Of course, the same general method could be applied on a much finer scale too, e.g. information on hippopotami does not need to be triggered until near the river. An alternative strategy would be to calculate a “super-context” that is the union of all contexts that the user is likely to have in the next hour (or some other defined time period). The system could then trigger all the notes that match this super-context and use the resulting group of notes as a cache until the user strays out of the super-context, thus reducing the processing overhead for each trigger-checking cycle.

Chapter 2: Stick-e Notes - a Metaphor for Context-Aware Applications

Having addressed the way in which changes in context are obtained and the manner in which the trigger checking is invoked, we now need to address the remaining aspect of trigger checking: the method in which a collection of stick-e notes is checked. The prototype framework simply cycles through the collection in the order in which they were opened. However, by applying some ordering to the stick-e notes, it should be possible to perform the process in a more efficient manner. For example, if the context element of primary importance is location (which is likely to indeed be the case for many applications that we envision) then the stick-e notes could be ordered by proximity to the current position. This can be visualised as lifting up a fishing net by a single knot in the centre and having the other knots (representing stick-e notes) cascade down from this central point. Given such an ordering we need only continue checking through the set of notes until reaching the first one that does not match the current context, as all notes after that are inherently more distant and hence not going to match either. Further work needs to be carried out to investigate whether the overhead involved in the sorting of stick-e notes necessary for this type of matching will be small enough to make it worthwhile doing, especially in large collections of notes. Further thought is also required on how ordering could be applied to many context elements simultaneously; perhaps by having several orderings of stick-e notes for each type of context element and then only checking the stick-e notes that are within range in every context element. Some context elements may not be sortable into any form useful for processing, e.g. names of animals can be sorted into alphabetical order but it doesn’t really help in determining which is closest to matching the current with context element. Other more conventional techniques to improve triggering performance also need to be considered. For example, making use of database technology to extract a set of active stick-e notes by applying a query, which reflects the current context, to a relational database table, which represents the set of open stick-e notes. Further investigation is required into such possibilities to see if they are feasible, e.g. in the case of employing database technology to see if the varied, dynamic, and complex forms of context element data could be successfully represented and manipulated within a relational database. Essentially, these are all general problems of structuring and ordering in order to improve search speed.

previous cycles in order to determine what stick-e notes should trigger. For example, using the electronic Post-It note program I could create a stick-e note attached to Geraldina so that the next time I see her the Post-It program pops up the reminder I recorded to “Don’t forget to ask Geraldina out for lunch”. Whilst I am in the presence of Geraldina the stick-e note’s trigger condition will continue to evaluate to true and each subsequent trigger checking cycle will result in the triggering of the note. However, it would clearly be inappropriate to display a new copy of the note each time it was triggered as I would soon end up swamped with hundreds of identical stick-e notes. We prevent such circumstances from occurring in the prototype framework through a selection of temporal restriction mechanisms that the author can apply to a stick-e note:

Re-trigger Timeout. This is the simplest form of restriction, where a minimum duration between the triggering and re-triggering is specified. For example, a 20- minute re-trigger timeout would mean that, once triggered, the note could not be re-triggered until at least 20 minutes have elapsed. In the meantime the current context may have changed, preventing a re-triggering occurring directly after the re- inclusion of that stick-e note in the triggering process.

Specific Interval Restriction. Prevents a stick-e note from triggering more than once in a given interval. The interval is expressed in terms of two bounding time and/or date stamps, e.g. 9:00 to 13:00 (which would prevent the stick-e note from triggering more than once during that period). The granularity of the interval can be extended to days, months or even years. Note, however, that a year interval will not be re-entered, unlike a time of day or day of week interval, e.g. a 9-12 interval could be re-used each day but a 1999-2000 interval will only be entered and exited once. Unlike the other two restriction mechanisms, it may be useful to specify multiple specific interval restrictions.

Generic Interval Restriction. Similar to the previous type of restriction but instead of specifying the trigger restriction interval as two bounding time/date stamps it is defined as the current minute, hour, day, week, month or year. For example, specifying the restriction interval as the current day would prevent a

Chapter 2: Stick-e Notes - a Metaphor for Context-Aware Applications

triggered stick-e note from re-triggering until tomorrow; specifying the specific day is not required.

In addition to restricting re-triggering there are some circumstances we have encountered in which the explicit de-triggering of stick-e notes is useful, which is currently not supported in our framework. To illustrate the need for de-triggering we can extend the previous example so that the invitation to lunch reminder is attached to the context of Geraldina’s presence and also Helena’s absence, i.e. to remind me to ask Geraldina out to lunch but only if Helena isn’t around. In our current model if I was in the presence of Geraldina and not Helena then the reminder would, of course, be displayed. But if Helena were to enter the room a couple of seconds later the reminder would still be displayed even though I now do not wish it to be visible, i.e. it should be de-triggered and removed to prevent Helena from seeing it.

To support de-triggering the framework could maintain a list of active stick-e notes to which it could add any notes that are triggered. During each trigger checking cycle it could then remove any stick-e notes that no longer trigger and inform the clients who had received a copy of the note when it originally triggered that it now has been de- triggered. Depending on the application the client may chose to react to or ignore the message.

When employing triggering and de-triggering an interesting effect we call ‘boundary hovering’ can be encountered. For example, if I am on the boundary of what is deemed to be ‘in the presence of Geraldina’, and I start shuffling back and forth, then the stick- e note will be rapidly triggered and de-triggered as I appear to move in and out of that context. The problem is heightened if a temporal restriction on re-triggering is in place, in which case the reminder will be removed from my screen on my first shuffle and then not replaced until the temporal restriction has expired, which is clearly not what I want to happen. To avoid such problems a de-trigger suspension period could be enforced by the framework so that the stick-e note has to be consistently in a non-triggering state for a specified time period in order for it to de-trigger. This compensates for the border hovering effect as the elapsed time in a consistent non-triggering state will continually be reset if I am shuffling in and out of the context.

Although the temporal methods of restricting de-triggering and re-triggering are effective they require a good degree of judgement from the stick-e note author in order to define an appropriate amount of time. For example, exactly how long do I have to be out of Geraldina’s presence before the stick-e note is de-triggered? It is not immediately obvious. Having the success of the framework’s re-triggering/de-triggering strategy so dependent upon the author’s sensible choice of restrictions and time periods is not entirely satisfactory. A preferable mechanism that we have proposed in later work is to define separate contextual zones for triggering and de-triggering, based on the user entering and leaving the context rather than on different timer mechanisms. We present this concept in chapter eight.

One final aspect of the triggering to consider is its distribution. Given the very limited processor resources of many platforms that will wish to utilise the stick-e note framework, offloading the bulk of the processing onto another computer may be desirable. The model-view-controller structure of the framework makes this a relatively easy task as the client device can simply implement a view interface and receive triggered stick-e notes from the remote controller and model components (though of course the communications medium used to connect them will differ). Distribution issues are the focus of the work presented in chapter eight.