- Decision Boards
- Research Clusters
- Joint Seminars
- Testbed & Simulation
- Summer School
- Visitor Programme
- In the News
- News Archive
Two COOJA plugins and manuals have been published to integrate the TWIST testbed in COOJA and to take checkpoints and perform rollbacks both in TWIST and COOJA.
The 4th International Workshop on Networks of Cooperating Objects for Smart Cities 2013 (CONET/UBICITEC 2013), colocated with CPSWeek 2013, accepts submissions until January 28th, 2013.
The 19th CONET newsletter has been published. You can read on Virtual Organizations for Multi-Model Based Embedded Systems and on the UvA Bird Tracking System.
Without a federation substrate, the users can access the resources of the individual testbeds only over their native APIs: API . This means that for each experiment, and after completing the native authenticating and authorization process, she needs to use a proprietary way to discover and reserve the required resources, to define and control the experiment, and finally, to collect the results.
The user needs to do this on each testbed separately. For N testbeds, she has to potentially use N different interfaces and processes. Without a federation substrate, there is no way to reuse the authentication and authorization credentials, no way to perform resource discovery across the multiple testbeds, no way to reuse the experiment specification, no way to reuse the client-side code for the on-line control of the experiment or for storing and post processing the results. In addition, there is no way to share this content with other users, so they can repeat the experiment and validate the results. There is also no common way to provide access to the results to external service providers that can provide storage or post processing (statistical analysis, plotting, etc.)
The CTF platform tries to address these limitations. Due to the large variability in the services offered by the individual testbeds this requires a two-step approach as described below.
As a first step, a common abstraction over the existing capabilities of the testbeds needs to be defined. This abstraction exports an interface, called Testbed Adaptation API (TA API), that can be used by the users to access the resources on the individual testbeds via a standardized interface. In this process of interface unification, some specific features of the individual testbeds will be undoubtedly remain unrepresented. Due to this, as well as to our coexistence and autonomy principles, we expect that this common interface will be used in parallel, and not instead of the native interfaces.
The TA API offers a new service level to the users. Instead of using the various native testbed interfaces as in the baseline scenario, users can now access the resources over a standardized Application Programming Interface (API). When they need some testbed-specific capabilities they can always leverage the native interfaces. By incorporating adequate arbitration mechanisms, the implementation of the TA API will make sure that no conflicts in the access of the resources between the native and the federation users can occur.
The CONET Testbed Federation Server (CTFS) leverages the services of the individual testbeds, exported through the standardized Testbed Adaptation API (TA API), to build a higher level abstraction over the federation aggregate, thus offering new service level to the user.
The figure below illustrates the relation between the individual testbed servers exporting the native and adaptation interfaces, the federation server and the users (both native and federation) plus external services in the scenario. The presented architecture has the flexibility to satisfy the major requirements outlined in our motivating use-case, and represents the basis for the CTF platform solution.