Bristol Wearable Computing

[ Home | Plans | Meetings | Members | Search | Papers | Links | CyberWear | LocoSoft]

Policy and the Policy Manager (version 1.1)


There are many occasions when a LocoMedia User will have a particular preference about what to do with a note. For example, they may be interested in loading notes about Opera, but not about Architecture. Or they may want to trigger notes at a 20m range rather than at a 2m range. In all these kind of cases the policy manager acts as a user proxy. The user issues special policy statements to the policy manager to tell it what to do in different circumstances, thereafter LocoMedia components will consult the Policy Manager for a 'go or no-go' decision on possible actions as they arise. Policy can also be used to indicate when the user should be consulted about a possible action.

Reasonable policy requirements such as being able to add an expiry date to a note or a maximum number of replays are not easy to support with our current LocoMedia system. The current scheme is limited to matching a notes creation context against the current context and then automatically rendering the note. In order to support policy, we need to introduce more flexibility, this is described below.

An overview of Policies

Policy for Note Producers and Note Consumers

Policy is used to specify what to do with notes under certain conditions. Policy can be issued both by note producers (authors) or note consumers. We make this distinction because the two types of policy propogate differently and thus require different support. Note producer policies tend to apply to individual notes and are carried with those notes, whereas note consumer policies apply to individual LocoMedia machines and are held with the Policy Manager component. At different times an individual user may be both a note consumer and a note producer. In our scheme there are eleven actions that can be affected by producer and consumer policies. Policy statements also involve 'action prefixes' ('do', 'dont' and 'maybe') and 'domain expressions'. There are also 'note attribute prefixes'. All is explained in due course!

Action type Policy Issuer Note attribute prefix Action prefix Domain expression Description
AddSensedContext P render DDM simple Attach information from context drivers to a note when created
AddUserContext P render DDM simple Attach topic information to a note when created
MatchSensedContext C   DD complex Match notes against information from context drivers
MatchUserContext C   DD complex Match notes against topics of interest to the user
SuspendNoteUntil P suspend D complex Temporarily disable triggered rendering of a note
DeleteNoteWhen P delete DM complex Delete note under specified circumstances
SetRenderProfile C   D fixed Control the repetitive rendering of a note
TransmitNote P transmit DDM complex Transmit notes to another device
ReceiveNote C   DDM complex Receive notes from another device
FinishTransmit P finish DDM complex Consider alternative communication routes to complete transmitting a note
FinishReceive C   DDM complex Consider alternative communication routes to complete receiving a note

Table 1: Policy Statements by 'action type'.

Note attribute prefix: Note Producer polices result in 'note attributes' stored with subsequently created notes. These attributes have special prefixes reflecting the original policy.
Policy Issuer: C = Note Consumer issues this via the policy manager, P = Note Producer issues this via the policy manager.
Action Prefix: DDM = 'do', 'dont' and 'maybe', DM = 'do' and 'maybe', DD = 'do' and 'dont', D = optional 'do' only
Domain expression: complex = boolean expression,  simple = simple domain pathname, fixed = domain is fixed and maybe omitted

How Note Consumer Policy works

Note consumer policy is managed by the Policy Manager. The policy manager constrains the FootBridge Manager and the Trigger Manager, which left to their own devices would communicate and render notes unfettered by the preferences of the local user. The FootBridge and Trigger Managers are programmed to consult the Policy Manager before any render,  receive or transmit action. The policy manager then consults the policies that it holds and determines whether to let an action proceed. In general, there are three possible action prefixes:

The user can express policy in terms of an action type and a domain expression that allows them to base their rule on attributes of the note. So for example:

In the examples above the domain expressions were just simple domain path names. For many policies they could also be more complex boolean expressions combining domain path names. Some boolean operators such as 'and' and 'xor' allow new kinds of policy to be formulated, whereas 'or' and 'not' are just notational conveniences. An example:

The policy langauge suggested here is just for use with the Policy Manager. The policy manager itself has no end-user interface, other system components must pass on any policy requirements from the user. The end-user is not necessarily expected to be able to formulate policy statements in this syntax. See section below on How users describe policy?

How Note Producer Policy works

Note Producer Policy starts off in the Policy Manager just like Note consumer policy. When the local note server creates a new note it consults the Policy Manager to find what Note Producer Policy is defined. These policies are then copied into the new note and used to advise other system components how to handle the note.

How to express policy in a LocoMedia Note

Previously a note contained its context information as a list of contextual data items, each comprising a domain to specify the context information type and an optional tuple to represent quantities. To support we policy we must broaden the system to allow all kinds of note attributes to be held with a note, not just contextual information. This would include note producer policy data such as an expiry date. One way to allow note attributes to be expressed is to set up additional regions in the domain server to reflect the broader scope of attribute information compared to contextual information. We could, for example, establish an '/expiryDate' domain, however things quickly becomes cluttered if there is also a '/creationDate' domain. Eventually it becomes hard for users to navigate the domain structure. Instead in our scheme we use an action prefix (one of the actions from Table 1) with every piece of attribute information stored with a note. By default the action type has been 'render'. As an example, we can now mark a note to be played every sunday but deleted on the 20th August 1998 by including two pieces of attribute information that would look something like:

The point here is that the same '/date' domain is used for both expiry and for deletion. The notion of 'expiryDate' is separated into the notion of a 'date' (represented by domains) and the built in action type: 'deleteNote'. Note that the example above assumes the presence of a temporal Context Driver that supports '/date' and '/date/dayOfTheWeek'.

This scheme is mostly implemented by extending the functionality of the 'Trigger Manager'. Previously this component automatically rendered a note in the event of its context matching the current context. From now the trigger manager is also able to delete, receive or transmit notes according to the note attribute prefix. We will cover how this works for receiving and transmitting below.

What happens when policies conflict?

When two policies conflict, the more specific policy applies. This is only decidable in cases where one policy's domain path is a subdomain of the other.

In the case that the two consumer policies encompass the same note by virtue of two domains that are related, then the policy associated with the more specific domain applies. For example, a policy based on '/interests/music/opera' overrules one based on '/interests/music'.

But what about a note that is associated with two unrelated domains. For example, a note registered under '/location/name/uk/bristol' and '/interests/music/opera'. If one policy refers to Bristol notes and another to Opera notes and they conflict, then which should apply? Ideally we would support a meta-policy (resolvePolicy) describing what to do in the case of such conflicts. The meta-policy either could apply either to 'all' or per opportunity type, so a simple meta-policy might be: 'resolvePolicy receiveNote do' - if two load policies clash then go ahead and receive the note in question. Implementing even this simple meta policy may be hard within the time constraints, therefore as an initial scheme we will refer all such clashes to the user as if the policy were 'maybe'. Such clashes are possible for the four 'add..' and 'match context' policies and the four receive and transmit policies.

Different policy action types can interfere, for example, a note may be deleted just before being transmitted. This kind of conflict is resolved as you would expect according to 'first come, first served'!

The Policies in detail

Policies that affect note context matching

Both the producer and the consumer of a note have control over the conditions in which a note is to be rendered. There are four policy types that affect this: addSensedContext, addUserContext, matchSensedContext, matchUserContext.


AddSensedContext is issued by the note producer to control which context drivers are asked to contribute context information recorded with a new note. Here are three examples:


Publish is issued by the note producer to add context information directly to subsequently created notes. This command is similar to the 'record'  command except that context drivers are not consulted. This is context information supplied directly by the user rather than being sensed from the environment. Here are three examples:


MatchSensedContext is issued by note consumers who wish to control the way that notes are matched against context information received from sensors. By default all sensed contextual information is matched against each cached note's contextual information. Any match causes the note to be rendered. If the local LocoMedia system has no contextual sensors that relate to the kind of contextual information held on its notes, then the notes cannot be triggered automatically. It is hard to see why a LocoMedia user might wish to alter the default policy, but for completeness we allow it.


By default notes on all topics are rendered as soon as there is a match between the currently sensed context and the notes recorded context. MatchUserContext allows note consumers to refine their field of interest by only subscribing to particular domains representing particular topics.


The curious feature of this scheme is the way that user context (the user's field of interest) and sensed context (environmental conditions) are treated separately. This is odd since one might suppose that the only difference between user context and sensed context is our ability to build sensors that can detect such things, not their intrinsic role in the LocoMedia system. Nonetheless this is to be a pragmatic system, designed to optomise the number of useful note renderings. The hypothesis of LocoMedia is that there is interesting potential in computers that take the initiative in their interaction with users. To maximise computer initiative, we have favoured triggering on sensed information (namely, by default any sensed information match will cause triggering). At the same time we have attempted to maximize the usefulness of matches by providing users with a means to express their particular interests. Initially all topics are considered of interest to a user. With experience, users will become bored with some topics and they may then start to refine their topics of interest.

So what does this amount to for matching purposes? A note is deemed to match if at least one matchSensedContext policy matches and at least one matchUserContext policy matches. Thus for matchSensedContext policies MSCP1 to MSCPn and matchUserSensedContext policies MUCP1 to MUCPn we have:

match = (MSCP1 or MSCP2 ... or MSCPn) and (MUCP1 or MUCP2 ... or MUCPn)

Each policy will then have a simple or complex boolean domain expression. There should always be at least one matchSensedContext and matchUserContext policy.

Policies to control over-rendering

There are three somewhat arbitrary policies intended to protect users from become irritated by repeated rendering of notes: setRenderProfile, suspendNote and deleteNote. These policies depend on a temporal context driver that allow notes to be triggered on a certain hour of a certain day. They also use the '/note/rendered' domain to indicate the number of times the note has been rendered to the current user.


This note provider policy prevents a note from being rendered. The policy is removed once the domain expression is matched. Notice that the note is not instantly rendered once the policy has expired, it is merely available for rendering.


This note provider policy allows notes to expire under certain circumstances. For example, a note may become out of date or redundant:


This note consumer policy is used to suspend a note after it has just been rendered. The suspension period is specified in hours and depends on the number of times the note has been rendered to that user already.  This dependency is expressed through a list of suspension times, the first element applied after the first rendering, the second after the second and so on.
- The suspension periods in the render profile represent hours except for zero (0), which represents a short period of time, say 5 minutes. A gap of zero would otherwise mean that the note would be played repeatedly, and might even overlap with itself!
- A terminating zero in the expression indicates that the note is to be discarded at this point.
- If the final element is non-zero then it applies repeatedly once it is reached.
- Virtual visiting (see somewhere else) is taken to override suspension - the user is expressly seeking information.

Some examples of suspendNote:

[Mmm, there should really be an explicit domain type in the policy to make it conform to the form of policy statements: setRenderProfile /note/renderProfile:0,0,0,24,24,24,0 - but this just adds the opportunity for syntax errors in the case where the domain is incorrectly specified - what do you prefer, Ed? support both maybe?]

To implement this policy the LocoMedia system adds an attribute to all notes when created: '/note/rendered:0'. This value represents the number of times that the current user has rendered the note. The value is reset when the note is received at a remote LocoMedia system. After a note has been rendered the Note Cache checks how many times the note has been rendered proviously and then consults the policy manager to find out the appropriate suspension period or deletion action. If the note is to be deleted the Note Cache does this immediately, if it is to be suspended, the Note Cache calculates date and hour at which it should be available again and adds an appropriate 'suspendNoteUntil ..' policy to the note. The Trigger Manager is responsible for checking for a 'suspendNoteUntil' policy attached to a note and suppressing any triggered rendering as a result.

Policies about Receiving and Transmitting notes

Receiving and transmitting can only start when another device is within range. In our scheme, there is no attempt to address messages contol distribution according to the identity of the two systems that are to communicate, communication is controlled simply on the basis of the attributes of notes.  There is no addressing scheme whereby notes can be sent securely to a particular recipient, our scheme is more like a newsgroup service whereby you can mark which domain a message is to be associated with, but nonetheless the note remains potentially accessible to anyone who choses to subscribe to the domain. It is perfectly possible that users may want an Email service, but there is little research value in adding this to LocoMedia. In parallel with this communication scheme we need to add a transparent synchronisation/back up scheme such that whenever a user docks with an infoPost that is connected back to the users home server, new or updated notes are copied back to home. This should happen irrespective of the users communication policy.


For the note producer there is a policy statement 'transmitNote' that allows them to specify which notes may be transmitted and which are to remain local. When two FootBridge managers come into contact with each other they exchange domain expressions indicating which notes they are prepared to receive. This, together with the local 'transmitNote' policy is used to determine which notes to transmit.


For the note consumer there is a policy statement 'receiveNote' that supplies a domain expression used by the FootBridge Manager to restrict which notes are to be received. The associated domain expression is passed to the remote FootBridge Manager. This is then used at the remote end to restrict the set of notes passed across:

FinishTransmitNote and FinishReceiveNote

These policies affect whether two FootBridge devices will attempt to complete an interrupted communication by seeking other communication channels. This is 'integrated networking'. As yet we have no implementation of integrated networking, but when we do basic policy would be to statements of the form:

The exact interpretation of this policy is open to discussion. Which end should attempt to seek alternative connections - probably both according to their policy. Should the other end reject a reconnection attempt if their policy doesnt encourage reconnection, or should they accept it provided that they are not paying communication tarrifs?!

How does the LocoMedia System work when another FootBridge device comes into range?

The FootBridgeManager is notified by the underlying layers when a new FootBridge device has been detected. Handshaking between the two FootBridge devices allows them to exchange domain expressions describing the type of notes they are prepared to receive. Each FootBridge device then calls the local note server to generate a list of appropriate notes that also meet the note's own transmitNote policy. If the note has no transmit policy then it is eligible for transmission by default. The two FootBridge Managers then each attempt to send suitable notes to each other. Some suitable feedback should be given to users to allow them to know how many notes are to be transmitted and received and to monitor progress. Ideally the transfer of notes should occur within a second or so, in practice transfer is likely to take longer and thus integrated networking becomes desirable.

FootBridge can also act like an active badge system. As part of the iteraction between two devices a domain name can be exchanged and this can be passed to a FootBridge Context Driver generating location and/or companion information.

FootBridge is also used to register peripherals and again this works through the device manager.

The default policy set

By default the Policy Manager starts with the following policies:

maybe addSensedContext /    - when new sensors are added the user is asked whether to add their output to new notes...
addSensedContext /location   - ...unless they relate to location, location information is always recorded with new notes
matchSensedContext /            - all installed sensors can cause a note to be triggered in the event of a context match
matchUserContext /                 - all notes matching the current sensed context are rendered irrespective of their topic
setRenderProfile /note/renderProfile:0,0,0,24 - notes can be re-rendered 3 times, thereafter they are held 24 hours between rendering
transmitNote /                         - all notes are transmitted to other LocoMedia system when in range...
dont transmitNote /personal    - ...unless they are associated with a '/personal' domain

[Mmmm it makes sense for all notes to auomatically be associated with the identity of their author, but this needs to come from the user one way or another - so there will generally also be a policy something like:
addUserContext /organisation/hewlett-packard/jim_bedford-roberts and /people/bedford-roberts/jim

How do users describe Policy?

By various mechanisms. Note the Policy Manager will support a particular policy language that we have sketched out here, but that the end user might work through various Policy Input Modules each of which may interact differently with the user.

For example, the user can issue policy on the fly using the 'publish' and 'unpublish' speech commands, or at a desktop while docked at a server. There will also be default policy coded into the Policy Manager - see above. The policy manager will provide an interface to allow new policy to be submitted, but it does not currently restrict who uses this interface or when they use it.

For security reasons we need to be careful about the possibility of loading new applications on the fly that can then access the policy manager. [TBD Currently notes are just passive things, but in the future, they are likely to be active. We already to plan to be able to load context drivers on the fly - what are the security implications here?]

unicrest.gif (4191 bytes)

The material displayed is provided 'as is' and is subject to use restrictions.
For problems or questions regarding this web contact Cliff Randell.
Last updated: January 14, 2000.
logoep.gif (1404 bytes)
ęCopyright Hewlett-Packard 1997-2000.