wiki:TestbedOverview

Testbed Overview

Table of Contents

  1. Roles
  2. System Components
  3. Main Interfaces
  4. How does it work?

The SENSEI Pan-European testbed realizes the SENSEI system for integrating heterogeneous sensor networks with the Internet. This section gives an overview of the testbed deployment, its main components and the roles played by various entities involved with the testbed. Finally, a short description about how the testbed works is given.

The figure below shows the deployment architecture of the testbed. The central components of the testbed are deployed on a data center. These components provide services like the Resource Directory (RD), AAA along with the Semantic Query Resolver (SQR) for applications. Embedded devices and sensor networks interact with the SENSEI system using web interfaces for registering and accessing resources. The entity that makes resources on devices or in sensor networks available to SENSEI is called a Resource End Point (REP). Finally, applications can be developed that discover and use these resources. Unlike middleware solutions, SENSEI uses a decoupled approach based on the web architecture. Resources are discovered by making resource directory lookups or semantic queries, but are accessed directly using the resulting URL(s). A management GUI is provided with the central components in order to manage and test the whole system. For more information about the SENSEI architecture, see the SENSEI White Paper.

Testbed overview

Roles

In the SENSEI project we have identified a number of technical and business roles played in the machine-to-machine ecosystem. Three of those roles are important when deploying a testbed of the SENSEI system: Resource Providers, System Framework Providers and Resource Users. These are logical roles, and the same entities might play multiple roles. Resource Providers operate the embedded devices and sensor networks used in a SENSEI system. SENSEI Framework Providers host the central components of the SENSEI system, usually located on one or more well-known servers. This Cookbook is organized by these roles played in the system.

System Components

The SENSEI system is made up of loosely coupled components which can be categorized by their purpose. Framework Components are hosted by System Framework Providers, and they provide the core functionality of the SENSEI architecture. Community Management Components provide security, authentication, privacy and billing functionality, usually also hosted by System Framework Providers. Resource Interaction Components are used by Resource Providers for making devices and sensor neworks available to the SENSEI system, and by Resource Users for interacting with the SENSEI system.

The main Framework Components include:

  • Resource Directory - The Resource Directory acts as the repository about all the resources available in a SENSEI domain. It accepts resource publications over the Resource Publication Interface (RPI) from REPs, and can be queried by Resource Users and other components over the Resource Lookup Interface (RLI). Resource directories in different SENSEI domains can also be peered.

  • Semantic Quert Resolver - The Semantic Query Resolver provides a higher level interface to the SENSEI system by supporting the search for resources semantically. This is achieved using either simple or language-based queries over the Semantic Query Interface (SQI).

  • Entity Directory - The Entity Directory holds context information about resources, complimenting the Resource Directory. Entity context information is either entered in the ED manually, or built-up automatically each time a REP includes an advanced research description when publishing to the RD.

  • Execution Manager - The Execution Manager provides a way to specify execution plans, which describe a sequence of resource access or actuation steps.

The main Comminity Management Components include:

  • AAA - The SENSEI AAA component provides access control for the entire SENSEI system. This includes both a security token service for providing identities, and a AAA service against which REPs and other components check access control rights for requesting resources. A section on REP access control is also provided, describing how to use AAA from a REP.
  • Privacy and Billing - The Privacy and Billing component provides a complementary approach to the access control provided by the AAA component, with an accounting service that allows access to be denied due to insufficient funds. A security token installed in the resource user (a Firefox plug-in is also provided) is used to authenticate a resource user.

Server components

The main Resource Interaction Components include:

  • Resource End Points - A Resource End Point (REP) is any implementation of SENSEI RAI interfaces accessible via a URL described in the Resource Directory. Several different REP implementations are provided by SENSEI. The Java REP Framework is an extisible Java SE implementation of SENSEI interfaces.

  • Gateways - In order to expose resources hosted in embedded sensor networks, entities called gateways are used to provide those resources as SENSEI REPs (thus implementing the RPI and RAI interfaces). In a native SENSEI island the sensor nodes also support IP, but realize a subset of the SENSEI interfaces with the Constrained Application Protocol (CoAP). The Native SENSEI Gateway proxies these resources to the rest of the SENSEI system. A ZigBee Gateway has also been provided to expose ZigBee nodes in an island to the SENSEI system.
  • Embedded REPs - Two different embedded REP implementations, compatible with the Native Gateway, have been realized. The Contiki REP provides an implementation of the embedded REP for the popular Contiki embedded operating system. The TinyOS REP provides an realization of the embedded REP for the popular TinyOS on a TelosB compatible hardware platform.
  • Management GUI - The SENSEI Management GUI is used in order to manage, test and demonstrate a SENSEI system using a set of graphical web interfaces. Although the Management GUI acts as a Resource User in many aspects, it is included as part of the System Provider virtual machine package because it plays an important management role for the framework components.

Main Interfaces

Since the SENSEI architecture is designed to be distributed with loosely coupled components, the definition of interfaces between them is important. In this section a short overview is given of the most commonly used SENSEI interfaces. In this realization of the SENSEI system the interfaces are realized using a REST design with HTTP.

  • Resource Publication Interface (RPI) - This interface is provided by a Resource Directory in order for REPs to register, update or remove so-called Resource Descriptions. This publication and maintenance procedure is automatically handled by the Java REP and Gateway implementations.
  • Resource Access Interface (RAI) - There is no single resource access interface in the SENSEI architecture, instead each resource description published by a REP includes information about the interface(s) available to access it, for example the URL and interface description. In order for Resource Users to easily access resources, a set of well-known resource interfaces have been defined for sensor, parameter, actuator and code-update resource types.

  • Resource Lookup Interface (RLI) - This interface is used by Resource Users and other components (e.g. the SQR) to find Resource Descriptions based on resource ID or other information contained in the Resource Description.

  • Semantic Query Interface (SQI) - This interface is used by Resource Users to query for resources or entities of interest. Instead of using low-level information in resource descriptions as with the RLI, this interface accepts high-level declarative queries. After performing query analysis, one or more resource descriptions are returned.

How does it work?

So how does the SENSEI system work in practice? The easiest way to find out is try it for yourself. First a System Provider is needed. There are two options: either the Pan-European testbed can be used or you can host your own system. By default Resource Provider components like the Java REP and Gateways are configured to use the Pan-European testbed. Deploying your own system is also not too difficult, all the needed components including the Management GUI are included in a virtual machine image.

Next some resources need to be connected to the system. The Resource User guide includes several different implementaions of resource end points. The easiest way to get started is to use the Java REP, which creates dummy resources on a standard PC. The Java REP can then be extended with your own resources. If suitable sensor node hardware is available, then the Native Gateway can be used on a PC to interconnect sensor nodes running either TinyOS or Contiki. In addition a ZigBee Gateway and Android Java REP implementations are provided.

So how to use the resources now available in the SENSEI system? The easiest way to start is with a simple web browser. Most resources return their value upon an HTTP GET, so entering the URL or the resource in your browser will display the value. The Management GUI is a more complete way to access resources, along with configuring the SENSEI system. Finally, as resources have simple REST HTTP interfaces, it is straightforward to create your own Resource User that looks up resources using e.g. the RLI interface and then accesses them with their RAI interface.

Last modified 13 years ago Last modified on Nov 1, 2010, 11:35:34 AM

Attachments (3)

Download all attachments as: .zip