[Back to Main Page]

Global Keyset
Namespace

Intent

Provide a global namespace for referring to distinct elements or data types. Motes running different applications can communicate using the keys.

Also Known As

global ids

Example TinyOS Components

GenericComm, DripC, TinyDB

Motivation

Communication is a critical aspect of TinyOS programs, but in order for motes to communicate effectively, they must be able to name the data they exchange. Every mote must agree on the name used, so that different programs using the same system (such as a routing layer) can interoperate.

Examples include protocol IDs, sensor types, and management queries. A protocol ID should be unique not just within a particular application, but also across applications: if two physically copresent networks disagree, then they can start sending data to one another that confuses their protocols.

Similarly,if an external program (say, a Java tool) needs to communicate with motes, then it must know the names or identifiers for the data it sends, whether they be command numberss, system names, or protocol IDs.

The Global Keyset provides a solution to this problem. A Global Keyset is essentially just a set of constants, whose meanings are agreed on by all programs. However, because these keys must be globally meaningful, they are often sparse: although the full set may be packed tightly, the fact that a given mote only uses a few keys.

A Global Keyset is a set of constants allocated by TinyOS components that need keys. For example, TinyOS provides 256 types of Active Messages; protocols use one or more AM IDs for their traffic. The Dispatcher pattern uses a Global Keyset to identify which component to dispatch to.

Applicability

Use the Global Keyset pattern when:

  • You need to identify services or data that motes exchange or use
  • These indentifiers can be concise (integer values)
  • All programs should have the same key-value binding, for interoperability

Consequences

By agreeing on a key-value binding, motes can communicate using a Global Keyset. Additionally, external programs/tools can refer to elements of the keyset and communicate with mote networks.

Although the Global Keyset pattern assumes that keys are unique, nesC/TinyOS has no mechanism to ensure this is the case. If a program uses a Global Keyset in a parameterized interface, such as in the Dispatcher pattern, then nesC can detect at compile-time if a key is multiply bound in a single program through combine functions. If the command or event associated with a key fans out to multiple components, then its return value can be a non-combinable type; as nesC has no way to combine the result of the multiple calls, it will issue a warning, which indicates that the key is multiple bound.

Sample Code

Two networking protocols have keys in the AM global keyset for AM IDs:

enum {
  AM_EPIDEMICMSG = 20,
};

EpidemicC.Receive -> GenericComm.Receive[AM_EPIDEMICMSG];

enum {
  AM_ROUTEMSG = 43,
}

RouteC.Receive -> GenericComm.Receive[AM_ROUTEMSG];

Known Uses

GenericComm uses a Global Keyset for Active Message types.

DripC uses a Global Keyset for referring to configurable variables.

TinyDB uses a Global Keyset for its sensor types; in this case, however, the keyset is composed of strings, which are then mapped to a Local Keyset at runtime.

Related Patterns

The Local Keyset provides a way to allocate keys in an efficient and compact fashion, but those keys are only valid within a single program. The compacted key space allows for more efficient state management than a sparse Global Keyset. The Keyset Map provides a way to map between Global and Local Keysets.

The Dispatcher pattern typically uses a Global Keyset for its dispatch identifiers.

[Back to Main Page]

Last modified: Fri Jul 30 17:09:59 PDT 2004