FIRE RoadmapFIRE Roadmap V1.2
Deliverable/Milestone: D3.4
Date: 16 August 2011
Version: 1.2
| Editor: | Serge Fdida, UPMC |
| Deliverable nature: | Report (R) |
| Dissemination level: (Confidentiality) | Public (PU) |
| Contractual Delivery Date: | 31/05/2011 |
| Actual Delivery Date | 31/07/2011 |
| Suggested Readers: | Network researchers, system architects, FIA and FI-PPP projects’ stakeholders, EC |
| Total number of pages: | 63 |
| Keywords: | future networks, experimental facilities, testing |
| Authors: | Serge Fdida, UPMC Jerker Wilander, Dimes Timur Friedman, UPMC Panayotis Antoniadis, UPMC Sophia MacKeith, UPMC Susanna Avéssta, UPMC Mike Boniface, IT Innovation Mauro Campanella, GARR Consortium Vania Conan, Thales Jérémie Leguay, Thales Piet Demeester, University of Ghent Tim Wauters, University of Ghent Anastasius Gavras, Eurescom Stefan Fischer, University of Lübeck Jacques Magen, Dimes Luis Muñoz, University of Cantabria José M. Hernández-Muñoz, TID Alex Gluhak, University of Surrey Martin Potts, Martel Timo Lahnalampi, Dimes |
Abstract
Future Internet Research and Experimental facilities have open and versatile offering to the network researchers. This first report of the FIRE roadmap provides an outlook at this existing and in the short-term available services of the mentioned experimental facilities. For the moment FIRE benefits from the four already finished projects: OneLab2, PII, WISEBED and FEDERICA. The running projects providing and building facilities are: BonFIRE, CREW, OFELIA, SmartSantander and TEFIS. Finally, there are three new projects starting in the autumn 2011: Confine, EXPERIMEDIA and OpenLab. The testing offering to date ranges from virtual switches to cloud services.
This first report provides a uniform description of the FIRE facilities including a short description of the current operational offering and use conditions. This report’s objective is to give the potential experimenter an idea about the experimenting possibilities before contacting the facility directly. The new projects’ details will be added in the next updates of the deliverable. Requests for a federated use of more than one FIRE facility could be directed either to the involved facilities or to the FIRE Office/FIRE Architecture Board for an analysis of the feasibility of the proposed experiments.
Executive Summary
This first version of the FIRE roadmap provides an overview of all FIRE facilities currently available. It indicates conditions of usage and timelines for the availability of the FIRE experimental facilities. This version includes Report I “Testbed Offerings”. The next version of the roadmap will also include Report II “Sharing among testbeds: components and standards”, with sections on sharing resources between testbeds, sustainability, federation and interoperability which now are only outlined.
The Call 2 projects (OneLab2, PII, WISEBED and FEDERICA) are now formally finished but the FIRE facilities developed in these projects are still available. For longer term guarantees of the availability of the resources, please consult the individual facilities.
The Call 5 projects (BonFIRE, CREW, OFELIA, SmartSantander and TEFIS) are about to accept users on their facilities under development. BonFIRE, OFELIA and TEFIS held their first Open Call during spring 2011 and plan to integrate the new experimentation on their facilities after summer 2011. CREW and SmartSantander will hold their first Open Calls in September, 2011 and the accepted experiments will start in the latter part of 2011.
The Call 7 projects (EXPERIMEDIA, Confine and OpenLab) will start their projects after summer 2011. The availability of their resources will be presented in later versions of the FIRE roadmap.
All facilities in FIRE may be selected for experimentation by Call 8 research projects, with consideration of availability, cost and other specific conditions for usage. Every proposal must include an agreement with the facility provider. Projects outside the FIRE research portfolio are either directed to the Open Calls of the facilities or to the facility directly. Requests for a federated use of more than one FIRE facility could be directed either to the involved facilities or to the FIRE Office/FIRE Architecture Board for an analysis of the feasibility of the proposed experiments.
There are very many individual experimental facilities available in FIRE since most facility projects offer more than one facility. E.g. CREW includes several different testbeds that may be used individually even though the CREW project expects researchers to perform experiments benchmarking different radio technologies on several of the testbeds included in CREW. Thus as an experimenter one has to perform a thorough analysis of what is offered in each facility. This roadmap and the individual facility websites will support such decisions.
A brief overview of the FIRE providers and their facilities is found below:
BonFIRE (www.bonfire-project.eu) offers a multi-site cloud testbed with heterogeneous cloud resources, including computing, storage and networking resources, for large-scale testing of applications, services and systems.
CREW (www.crew-project.eu) offers an open federated test platform, which facilitates experimentally-driven research on advanced spectrum sensing, cognitive radio and cognitive networking strategies in view of horizontal and vertical spectrum sharing in licensed and unlicensed bands.
FEDERICA (www.fp7-federica.eu) is a Europe-wide infrastructure based on computers and network physical resources, both capable of virtualization. The facility can create sets of virtual resources according to users' specification for topology and systems. The user has full control of the resources in the assigned slice which can be used (for example) for Future Internet clean-slate architectures, security and distributed protocols, routing protocols and applications.
OFELIA (www.fp7-ofelia.eu) provides an infrastructure enabling network innovations through the OpenFlow protocol: users can “control their part of the network” rather than simply conducting experiments “over” the network.
OneLab (www.onelab.eu) includes PlanetLab/PlanetLab Europe, NITOS (wireless), Etomic (high precision measurements) and Dimes (large scale measurements). By enabling a user to request resources using OMF controllers in a PlanetLab slice, OneLab allows a user to run an experiment on PlanetLab. The PlanetLab wireless extensions allow experiments to span PlanetLab and an OMF-controlled wireless testbed. NITOS consists of nodes based on commercial Wi-Fi cards and Linux-based open-source platforms, which are deployed both indoors and outdoors.
Panlab Infrastructure Implementation (PII) (www.panlab.net) has elaborated the concept of a Panlab office. The Panlab office is a testbed resource broker, whereby the brokered testbed resources are specialized ICT resources owned by testbed owners available for testing and experimentation by customers.
SmartSantander (www.smartsantander.eu) is building a city-scale experimental research facility in support of typical applications and services for a smart city. The results are expected to influence the definition and specification of Future Internet architecture design from the viewpoints of the Internet of Things and the Internet of Services.
This experimental facility will support horizontal and vertical federation with other experimental facilities and stimulate the development of new applications by users, including experimental advanced research on IoT technologies, and a realistic assessment of user acceptability tests.
TEFIS (www.tefisproject.eu) supports the Internet of Services community, by providing testbeds supporting the entire service lifecycle, including user behaviour, scale, performance and SLA compliance. It brings together test facilities for IT-based testing with Living Labs. The combination of testbeds offered by TEFIS allows a broad range of service characteristics including functionality, performance, scalability, usability, maintainability, user experience/acceptability, and standards compliance.
WISEBED (www.wisebed.eu) offers a federated wireless sensor network testbed that comprises approximately 1000 nodes distributed over 9 European sites and a library for the platform-independent and efficient implementation of algorithms.
Table of Contents
Report I: Testbed offerings 12
2. Individual testbeds offerings 13
2.2.4. International liaison 17
2.3.4. International liaison 20
2.4.4. International liaison 22
2.5.4. International liaison 25
2.6.4. International liaison 32
2.7.4. International liaison 36
2.8.4. International liaison 41
2.9.4. International liaison 48
2.10.4. International liaison 52
Report II: Sharing among testbeds: Components and Standards 53
3. Sharing among testbeds – components and standards (editor UPMC) 55
3.1. Control Plane and Experimental Plane 55
3.3. Operation and legal framework 55
3.5. Liaison with PPP and international initiatives 56
4. Sustainability, legal and business issues (editor A. Gavras/JaCQUES MAGEN) 57
4.3. Business and other issues 57
5. Federated testbeds (editor M. Boniface) 58
6. Integration and interoperability plans (editor P. Demeester) 59
6.1. Common interconnection 59
6.2. Federation of Tools for experimentation 59
6.3. Timing of interconnection within FIRE 59
6.4. Individual / case-specific objectives in the FIRE context 59
7. Conclusions and recommendation (editor J. Wilander) 60
Figures
Figure 1. FIRE projects' timing. 12
Figure 2. BonFIRE testbed facility. 14
Figure 3. BonFIRE timeline. 14
Figure 6. FEDERICA physical topology. 20
Figure 7. Five OFELIA islands. 22
Figure 9. OneLab Trust and resource discovery (SFA-based) federation. 25
Figure 10. OneLab experiment control (OMF) federation. 26
Figure 11. OneLab Measurement system federation. 27
Figure 12. SmartSantander Architecture. 35
Figure 13. SmartSantandder Sensors. 36
Figure 14. SmartSantander light sensors in the city. 36
Figure 15. SmartSantander Timing. 37
Figure 16: TEFIS functional architecture. 41
Figure 17: TEFIS detailed work plan. 43
Figure 18. WISEBED architecture. 47
Figure 20. Performing experiments in WISEBED.. 49
Tables
Table 1. TEFIS service testing objectives. 40
Table 2. TEFIS Use Case summary. 43
1. Introduction
FIRESTATION is the main venue where discussion and interaction is taking place, related to the analysis of the FIRE testbed offering as well as the definition of some guidelines for their evolution and, potential federation.
The first task of the FIRE roadmap is to clearly identify the offering of the FIRE projects and facilities, in terms of their capabilities, operation and conditions for usage. This will provide a clear status of the offering and identify the strengths and weaknesses of the current European offering with respect to the ecosystem needs and international competition. This work has delivered this first stand-alone report dedicated to the FIRE offering. It will be updated as new services and testbeds become available.
Secondly, the FIRE roadmap will identify the common features that could be shared with - or differentiated from - the current projects. It includes the so-called control and experimental planes, as well as the various tools used to collect and monitor the data from the experiments. Similarly, best practices for operating the facility, as well as the legal framework and user management aspects will be highlighted.
An ultimate objective for FIRE is the federation of the various testbeds into a global offering, leading towards an open federation. The FIRE roadmap will discuss its definition and rationale for the federation as well as a skeleton architecture and major components to enable it.
The roadmap will therefore address the development path and process of the federated facility, including its business model and sustainability approach. In addition, it will discuss how we can better incentivize the utilization of the facility by the users as well as the liaison with other EU programmes such as the FI-PPP and other initiatives worldwide.
The workplan is designed in 3 stages:
Report I: Testbed offerings
Report II: Sharing among testbeds: components and standards
1. Sustainability. Legal and business issues
2. Federation – Federation among facilities
3. Integration and interoperability plans
4. Conclusions and recommendation
Report III: Updated version for Report I and Report II
2. Individual testbeds offerings
2.1.1. FIRE Facilities
Currently, FIRE has facilities from the four already finished projects: OneLab2, PII, WISEBED and FEDERICA. The running projects providing and building facilities are: BonFIRE, CREW, OFELIA, SmartSantander and TEFIS. Finally, there are three new projects starting in autumn 2011: OpenLab, EXPERIMEDIA and Confine. Figure 1 depicts the timing of these FIRE projects and (for some) their thematic roots.
Figure 1. FIRE projects' timing
Each following sub-section has been written by the currently available facilities. The information is not exhaustive but provides a short description of the current operational offerings and use conditions plus a short description of their vital components. This section provides a uniform description of the FIRE facilities and will be also published on the FIRE web. It provides the potential experimenter with answers to the following questions before contacting the facility directly. The details of the 3 new projects from Call 7 will be added in the update of this deliverable.
a. Basic offering – the target usage of the testbed, the description of the facility
b. Main components including the timeline for the availability of the facility component (two year plan) for the open use of the facilities
c. Examples of Use Cases
d. Usage policies – How to connect to the facility. How to perform experiments (on site or remote). Support organization for experimenters. Contract requirements for usage.
e. Plans how to accommodate new requirements for experiments not presented in the time plan.
f. Cost of usage, allowable duration of experiments and permitted resource usage.
g. International liaisons
2.2. BonFIRE
2.2.1. Offering
2.2.1.1. Description of the facility
BonFIRE offers a multi-site cloud testbed with heterogeneous cloud resources, including computing, storage and networking resources, for the large-scale testing of applications, services and systems.
BonFIRE supports the following features:
- Advanced monitoring tools provide access to performance metrics for the virtualized resources and to specific experiment monitoring results.
- Both real and emulated networking resources are available on interconnected testbeds. Controlled networks will be available from the third year of the project (June 2012).
- In addition to in-depth user documentation, BonFIRE offers support for experimenters, to facilitate the uptake of the facility and increase the quality of the research.
- Access to BonFIRE resources is through the standard, Open Cloud Computing Interface (OCCI). The BonFIRE Portal generates OCCI for the user while a “Restfully”[1] client-side library allows scripting of commands. OVF-based, declarative experiment descriptors will be available in late 2011.
- In total, 250 cores, with 460GB of RAM and 12TB of storage are available permanently; this will increase to 350 cores, with 700GB of RAM and 30TB of storage by December 2012. On-request access to about 2300 additional, multi-core nodes is also possible.
- Single sign-on, root access to the VMs and support for elasticity come as standard.
Figure 2. BonFIRE testbed facility
2.2.1.2. Main components - the timeline for the availability of the facility components
The BonFIRE facility will be constructed in four major cycles, each time mainly providing additional experiment functionality. The first cycle (starting at M1 in June 2010, until M10) aims at rapid prototyping, while the second cycle (M15) will add functionality based on requirements from internal experiments. The third cycle takes input from Open Call experiment requirements and incorporates federation with external facilities (such as FEDERICA and Open Cirrus; M24). In the last cycle (M34), results from the second Open Call experiments and any non-funded experiments are taken into account to construct the final version of the facility.
Three facility scenarios are supported: one involving an extended multi-site cloud facility with heterogeneous resources, one involving a controlled emulated network cloud and one involving a federated cloud with complex networking. The first two scenarios will be available from the first cycle (M10), while the combination of both these scenarios, as well as the third scenario, will be available after Release 3 (M24).
In terms of functionality, additional features for experiment description, experiment lifecycle management, virtual machine image management, monitoring, networking, elasticity, data management, security, heterogeneity and scalability will be provided.
2.2.2. Use Cases
Use Cases for experimentation on the BonFIRE facility focus on large-scale testing of applications, services and systems that require scalable and elastic provisioning of heterogeneous and controllable computing, storage and network resources.
For the first project phase, three experimental Use Cases have been provided by the BonFIRE consortium.
• Experiment Use Case 1: Dynamic Service Landscape Orchestration for Internet of Services
The objective of the experiment is to investigate the requirements arising from the composition of services at the different layers of the future Internet ecosystem (cloud composition and services composition). The end goal is to produce performance, deployment, management and life cycle models for a federated enterprise SOA application deployed within a cloud environment.
• Experiment Use Case 2: QoS-Oriented Service Engineering for Federated Clouds
This experiment aims to discover whether it is possible to describe virtualised hardware resources using high-level application-style benchmarks such as "dwarfs". The intention is that by describing hardware in terms closer to the computational work of real applications, making predictive models for application QoS will become easier than making predictions based on raw descriptions of the hardware such as CPU type and clock speed. These models can then be used to compare IaaS providers and make better resourcing decisions, amongst other benefits.
• Experiment Use Case 3: Elasticity Requirement for Cloud based Applications
The target of the experiment is to determine the elasticity requirements for cloud based web applications, helping providers to comfortably adhere to SLA levels without excessive over-provisioning of resources.
These experiments were incorporated in BonFIRE from the beginning so as to drive the facility and validate its first implementation. Based on these and on the experience and expertise of the BonFIRE partners, 27 Use Cases have been captured; from these, 101 functional and non-functional requirements were elicited. The development of Use Cases continues on BonFIRE, with additional Use Cases to be collected from the two Open Call processes in Months 12 and 24.
Representative Use Cases for BonFIRE from the First Open Call experiments originate from various research areas, including thin client computing, distributed cluster computing, security and dynamic service compositions.
These experiments make use of BonFIRE's functionality for controlling network characteristics, federating heterogeneous resources, monitoring infrastructures and support for elasticity, and aim to assess the influence of such functions on their developed system.
2.2.3. Usage policies
2.2.3.1. How to connect to the facility
The BonFIRE facility will be made available to registered experimenters from the scientific community and from interested companies, both through Open Calls and through non-funded mechanisms.
2.2.3.2. Plans how to accommodate new requirements for experiments
BonFIRE is committed to developing in line with user requirements. Initial Use Cases and requirements have been identified early on in the project, as a basis for the first prototype release of the facility. For each of the following three releases, additional input from experimenters will be gathered in order to drive future architecture and deployment plans. For the second release, requirements from the internal BonFIRE experiment Use Cases are taken into account. For the third and fourth release, requirements from the Open Call and non-funded experiments are considered as well.
2.2.3.3. Cost of usage
The usage of the infrastructure is free of cost for the embedded experiments and those selected through the two BonFIRE Open Calls. No limitations on the duration and reservation of the resources are set for the permanent infrastructure, while on-request access to additional resources is possible depending on the availability and usage policies of the individual testbed providers.
The project is working towards developing a sustainable business model and an associated business plan. This will investigate options for charging for usage.
2.2.4. International liaison
BonFIRE assumes federation as a key vehicle in order to achieve some of its goals. BonFIRE has selected facilities and projects whose functionality could be of use to BonFIRE and analysed the benefits and synergies that could be exploited by both parties. This analysis covers the FEDERICA, PII, OFELIA, OneLab2 and OpenCirrus initiatives.
In particular, federation with FEDERICA is identified as means to achieve experimentation involving controlled networks. To this end, BonFIRE is in close contact with the FEDERICA consortium; NOVI, whose consortium overlaps with FEDERICA and whose results can provide better access to FEDERICA (see section 2.4); and GN3, which has written to BonFIRE confirming that the involved NRENs “are fully committed to continue support of the FEDERICA infrastructure within the GN3 Project”. Release 3 of BonFIRE (M24, May 2012) will include support for federation.
2.3. CREW
2.3.1. Offering
2.3.1.1. Description of the facility
CREW offers an open federated test platform, which facilitates experimentally-driven research on advanced spectrum sensing, cognitive radio and cognitive networking strategies in view of horizontal and vertical spectrum sharing in licensed and unlicensed bands.
CREW federates a Software-Defined Radio testbed at Trinity College Dublin, a heterogeneous ISM wireless testbed at IBBT, a sensor network testbed at TU Berlin, an outdoor heterogeneous ISM/TVWS testbed at the Josef Stefan Institute[2], a spectrum sensing platform developed at imec, and an LTE/LTE+ cellular testbed at TU Dresden.
CREW offers the following federation functionalities:
• a common portal to all its testbeds. giving a comprehensive description of the individual testbeds and the functionalities of the federated testbed and further providing clear guidelines on how to access and use the federated testbed
• advanced cognitive components such as spectrum sensing agents and configurable radio platforms, by linking together software and hardware solutions from multiple partners
• open data sets for spectrum sensing data and primary user activity, created under benchmarked conditions and using a common sensing data structure
• a benchmarking framework for cognitive radio and network experiments, offering automated procedures for experiments and performance evaluation methodologies, enabling fair comparison between subsequent developments or competing cognitive solutions.
2.3.1.2. Main components - the timeline for the availability of the facility components
CREW is a five-year project, which started in October 2010 (see CREW roadmap below). Its first year is dedicated to the basic formation of the federation and experiments by both academic and industrial partners. In the following two years, the consortium will be expanded through two Open Calls for proposals. During that time, the testbeds in the federation will be enhanced with demand-driven extensions. For the Open Calls, funding is available for experimentation. We note that applying for funding is not a requirement: (unfunded) use of the infrastructure, for smaller projects or exploratory use will also be possible starting from October 2011. The final years of the project will allow the transition to a sustainable usage model for the federation, which is expected to evolve into a self-sustaining platform for cognitive radio experimentation.
2.3.2. Use Cases
Use Cases include, but are not limited to:
• Context awareness for cognitive networking: spectrum sensing in unlicensed (ISM) and licensed bands (TV white spaces, cellular systems)
• Robust cognitive networks: applications that require robust communications though avoiding harmful interference and using frequency agility to improve communication quality
• Horizontal resource sharing in the ISM bands: algorithms, protocols and networking architectures for coexistence of and cooperation between independent heterogeneous network technologies
• Cooperation in heterogeneous networks in TV bands: new techniques for context awareness in unlicensed (ISM) and licensed bands (TV white spaces, cellular systems)
• Cognitive systems and cellular networks: the impact of dynamic spectrum access by secondary users on LTE cellular primary systems.
2.3.3. Usage policies
2.3.3.1. How to connect to the facility
The individual test facilities are very diverse and as a consequence have their own access and usage policies. However the common CREW portal provides clear guidelines on how to select the most suited facility and corresponding policies. The CREW facility providers commit to offer sufficient capacity for external experimenters and to provide the necessary support during experiments. The CREW portal will redirect the experimenter to the different remote login interfaces for the different facilities. Each local facility will further organize its own support.
We note that cognitive radio / cognitive networking experiments are per definition co-located; hence the booking of resources is always local. The CREW platform does not support concurrent wireless experiments at different locations.
2.3.3.2. Plans how to accommodate new requirements for experiments
New requirements and functionality will be defined in a demand-driven way from (1) the needs defined by Open Call usage scenarios; (2) gaps identified during operational use by internal/external experimenters and; (3) common needs identified with other FIRE facility projects.
2.3.3.3. Cost of usage
From October 2011, the CREW facilities will be open for external experimenters. External experimenters joining the CREW project as a result of the Open Calls will be funded by CREW. During years 2 and 3 of the project (October 2011 – September 2013), external experimenters not joining the CREW project will be granted free access to the CREW facilities under clear conditions: (1) there are no guarantees on availability (as federation is still under development); (2) feedback on usability of the facilities is required.
From October 2013, full open access will be offered to external experimenters. Terms and conditions (tariff scheme and access policies) will be applied according to the sustainability business model developed in the CREW project (in collaboration with other FIRE projects).
2.3.4. International liaison
CREW aims to set-up a joint project with US research groups in the framework of the FIRE-GENI collaboration. More liaisons may be established as a result of the Open Calls (September 2011 and September 2012).
2.4. FEDERICA
2.4.1. Offering
2.4.1.1. Description of the facility
FEDERICA is a Europe-wide infrastructure based on computers and network physical resources, both capable of virtualization. The facility can create sets of virtual resources (slices) according to users' specification for topology and systems. The user has full control of the resources in the assigned slice which can be used (for example) for many types of research, from Future Internet clean-slate architectures to security and distributed protocols, routing protocols and applications. The infrastructure has European size and it is open to interconnection to external facilities. Information and detailed description is available at http://www.fp7-federica.eu
Figure 6. FEDERICA physical topology
The FEDERICA substrate comprises 4 core PoPs located in CESNET (Czech Republic), DFN (Germany), GARR (Italy), and PSNC (Poland), and 10 non-core PoPs located in FCCN (Portugal), GRNET (Greece), HEAnet (Ireland), I2CAT (Spain), ICCS (Greece), KTH (Sweden), NIIF (Hungarnet), PSNC (Poland), RedIRIS (Spain), and SWITCH (Switzerland).
The Core PoPs are interconnected in a full mesh topology by 1Gbps dedicated Ethernet network circuits, terminated on Juniper MX480 routers. Non-core PoPs are attached to core and non-core PoPs in a highly meshed topology, also using 1Gbps Ethernet circuits and EX Juniper switches.
Each PoP hosts at least one Sun X2200M2 server. In the core PoPs the number of servers is increased to at least two. VMware ESXi operating system was chosen as hypervisor.
The facility allows disruptive testing in a wide area environment. All components of the slices are created using virtual resources and can host any type of protocol and application.
2.4.1.2. Main components - the timeline for the availability of the facility components
The FEDERICA project ended in October 2010. However, the substrate is still fully functional and is currently supported by the partners and partially by the GN3 project. The current plan is to maintain the facility, without upgrades, up to 2012. A sustainability plan is being developed, including collaboration with the GN3 project.
2.4.2. Use Cases
The FEDERICA consortium has served more than 20 user groups, the paper [P.Szegedi et al, ‘Enabling Future Internet Research: The FEDERICA Case’ IEEE Communications Magazine • July 2011] details the most interesting ones.
The experiments may be divided in three areas:
• Validation of Virtual Infrastructure features: this group of experiments aims at validating the basic principles of virtualization capable infrastructures in general and particularly the measurement and the configuration of reproducible virtual resources
• Evaluation of multi-layer network architectures, using the capability of connecting external testbeds or virtual slices provided by other facilities to the FEDERICA user slice
• Design of novel data and control protocols: this group of experiments aims at designing and validating novel data and control plane protocols as well as architectures
2.4.3. Usage policies
2.4.3.1. How to connect to the facility
FEDERICA is open for accepting requests for use. The requests are examined by a User Policy Board which discusses technical feasibility and details with the user. There is currently no API or automated system to connect to. The slice is created initially by the NOC and then handed over to the full control of the user.
2.4.3.2. Plans how to accommodate new requirements for experiments
Until 2012 there is no plan to modify the facility. Through the collaboration with the NOVI project, there is an ongoing effort to adopt SFA and extend the ProtoGENI RSpecs to represent the FEDERICA facility. This will enable the possibility to use more automated control and management and to better federate with SFA compatible facilities.
2.4.3.3. Cost of usage
Currently the usage is free of charge. The suggested duration of the experiment is three months. The total number of resources to be allocated varies case by case and it is agreed initially with the users.
2.4.4. International liaison
FEDERICA had various contacts with Future Internet initiatives worldwide, in particular in the US and Japan. A direct collaboration is planned with Internet2 and GENI.
2.5. OFELIA
2.5.1. Offering
2.5.1.1. Description of the facility
• OFELIA provides an infrastructure enabling network innovations through the OpenFlow protocol: users can “control their part of the network” rather than simply conducting experiments “over” the network
• Users receive a network slice consisting of
o virtual machines as end-hosts
o a virtual machine to deploy their OpenFlow-capable network controller/application
o Parts (slices) of the network nodes that connect to the user’s OpenFlow controller
By the end of the project, five islands will provide heterogeneous network technologies to experiment with. These five testbeds are operated by partners with complementary technological strengths and user groups from five countries with strong research communities in networking:
Figure 7. Five OFELIA islands
2.5.1.2. Main components - the timeline for the availability of the facility components
There are three phases in OFELIA (duration 37 (36) months from Sept. (Oct.) 2010):
• Phase i: OpenFlow controllers and switches in place, first local experiments concluded
• Phase ii: Connect islands and extend the OpenFlow experimentation to wireless and optics
• Phase iii: Automate resource assignment and provide connections to other FIRE and non-European research facilities
Detailed timeline for Phase I and II:
Phase I:
• March 2011: islands deployed + closure of 1st round of Open Calls
• June 2011: finalization of 1st round of Open Calls + public offering (= external users can make use of the facility)
Phase II:
• March 2012: islands extended and interconnected + closure of 2nd round of Open Calls.
• June 2012: finalisation of Open Calls
2.5.2. Use Cases
In generic terms, OFELIA aims at Use Cases in which researchers need control over the network in terms of routing, traffic engineering, etc. The Open Calls resulted in typical applications such as: Network virtualization / provider virtualization, Content centric networking, Gaming / real-time applications, Multi-domain routing and Social networks.
Besides a pure lab environment, in two islands students / employee workplaces will be wired to the OFELIA facility and thus experiments involving real users could be supported.
2.5.3. Usage policies
2.5.3.1. How to connect to the facility
From July 2011 until the end of the project (Sept 2013) the facility is open free-of-charge for external users as a best-effort service.
• A usage policy document has been prepared and will be published soon. Users will need to agree with this usage policy document
• A user manual is under development
• Connecting to the facility happens through OpenVPN connections through the hub in Ghent
• Each island runs an expedient web-based user interface. This interface will also allow in Phase II (from March 2012 onward) controlling resources from aggregate managers running in other islands. Credentials will be valid across all islands (single sign-on).
2.5.3.2. Plans how to accommodate new requirements for experiments
New requirements and functionality will be defined in a demand-driven way from (1) the needs defined by Open Call usage scenarios (for this purpose, also a workshop co-located with ECOC2011 is planned to learn about requirements from other proposals than those that could be accepted within the available budget); (2) gaps identified during operational use by internal/external experimenters and; (3) common needs identified with other FIRE facility projects.
2.5.3.3. Cost of usage
· During the project lifetime usage will be free-of-charge
· For experiments inside a single island, the appropriate island manager decides on duration of experiments and permitted resource usage
· For other experiments, a decision is taken by the OFELIA policy committee
· So far, no general policies on resource usage have been set
2.5.4. International liaison
Initial communication links have been established to a number of related test facility projects, including:
· EU/Brazil call: via i2CAT (contact: Michael Stanton), starting June 2011
· China/OFELIA cooperation: via EICT (contact: Prof. Xing Li, TsingHua University Prof. Yan Ma, BUPT), initial contact established during ICT 2010, further talks were planned for FI week in Budapest, May 2011
· NICT/JGN2+ trials: via NEC VC in January 2011, continued in May 2011
2.6. OneLab
2.6.1. Offering
2.6.1.1. Description of the facility
The OneLab experimental facility offers access to a range of different Future Internet testbeds and research tools. Building on the results of former EC projects “OneLab” in FP6 and “OneLab2” in FP7, the OneLab offering will continue to be developed though the OpenLab project, starting in September 2011.
OneLab has three types of federations implemented in its experimental resources, each serving their specific functions: 1. Trust and resource discovery, 2. Experiment control federation - adding wireless resources and their OMF experiment controller, and 3. Measurement systems.
1. Trust and resource discovery federation
This federation builds on PlanetLab and its methodologies: Through an SFA interface, the PlanetLab Europe user community can access testbeds worldwide OneLab’s flagship testbed is the PlanetLab Europe (http://www.planet-lab.eu/), the European branch of the global PlanetLab system, a geographically-distributed platform for testing novel ideas in network overlays, content distribution systems, distributed systems, and peer-to-peer technology. It consists today of over 250 server-class computers (nodes), located at over 140 sites across Europe, and users have access to over 1000 PlanetLab nodes worldwide. Each node runs the PlanetLab operating system, which is based upon the Linux-VServer virtual server architecture. OneLab is a slice-based facility: a researcher obtains a slice across the system that consists of virtual machines on any or all of the nodes.
Figure 8. Map showing PlanetLab nodes in Europe. Click on the image to see an interactive map on the PlanetLab Europe website
MySlice - PlanetLab Europe slice management interface
A key OneLab component is MySlice (http://myslice.planet-lab.eu/), specially-developed for PlanetLab Europe, which gives users both a web interface and a programmable API through which to manage their slices. With a service that starts with slice setup, through experiment run-time, to retrospective analysis of experimental data after an experiment is concluded, MySlice also offers visualization tools for data that has been collected.
SFA (Slice Federation Architecture)
SFA is designed to be entirely decentralised, which is deemed to be the only way to achieve massive scale. It defines a web services interface between federation peers. Information and requests are performed online. It comprises: (a) naming conventions for referring to all entities in the federation, (b) a trust layer that implements secure/authenticated API calls, and (c) a set of APIs for using the different services that constitute the federation. It makes no assumptions about the nature of the resources on heterogeneous testbeds and so does not impose a model on resource descriptions, instead conveying them as-is, much like a payload is handled in a network packet. Privacy and policy constraints may be implemented in the SFA layer at each peer. Non-public data can be hidden and failures can be returned if policies would be violated. Emerging from GENI [geni.net], SFA currently has two interoperable free open source implementations: the PlanetLab one, that OneLab2 has been involved in implementing, and the ProtoGeni one, that the Emulab platform has started to use extensively.
Figure 9. OneLab Trust and resource discovery (SFA-based) federation
On top of the original PlanetLab Europe testbed, the OneLab experimental facility has been expanded to include the other two types of federation, adding testbeds and measurement techniques. These added heterogeneous features include:
2. Experiment control federation – adding wireless resources and their OMF experiment controller
By enabling a user to request OMF resource controllers in a PlanetLab slice, Onelab allows an OMF user to easily run an experiment on PlanetLab. With our PlanetLab wireless extensions, this experiment can easily span PlanetLab and an OMF wireless testbed. The European wireless testbed joining OneLab federation is:
NITOS (Network Implementation Testbed using Open Source code) located in Volos, Greece and developed by CERTH, in association with NITLab, the Network Implementation Testbed Laboratory of the Computer and Communication Engineering Department at the University of Thessaly. NITOS consists of nodes based on commercial Wi-Fi cards and Linux-based open-source platforms, which are deployed both inside and outside of the University of Thessaly's campus building. Currently, three kinds of nodes are supported: ORBIT-like, diskless Alix2c2 PCEngines, and GNU/MIMO.
Figure 10. OneLab experiment control (OMF) federation
3. Measurement systems
Onelab’s measurement system federation builds on TDMI, TopHat Distributed Measurement Infrastructure. TopHat is a topology information system integrated on every PlanetLab virtual machine. Researchers use the PlanetLab facility for its ability to host applications in realistic conditions over the public best effort Internet. TopHat has federated with two other measurement systems, DIMES and ETOMIC in order to gain higher measurement precision and wider coverage and hence observability of the Internet beyond PlanetLab nodes.
ETOMIC testbed - A high-precision traffic measurement infrastructure
The specially designed nodes of ETOMIC (European Traffic Observatory Measurement Infrastructure) are distributed throughout Europe, and are able to carry out active measurements that are globally synchronized to a high temporal resolution, providing extremely accurate readings (~10 nanoseconds).
DIMES testbed - A distributed measurement infrastructure
Aimed at studying the topology of the Internet, DIMES is based on distributed light-weight software agents, hosted by a community of thousands of volunteers worldwide. DIMES offer the ability to launch topology measurements of the Internet from multiple vantage points, as well as access to a vast database of accumulated measurement data. On a typical day, the DIMES server records 3.5 million measurements from 1300 agents in over 50 countries.
Figure 11. OneLab Measurement system federation
2.6.1.2. Main components - the timeline for the availability of the facility components
OneLab’s governing consortium was set-up by INRIA and UPMC in August 2008 to oversee the development of OneLab’s first testbed, PlanetLab Europe. This partnership was expanded in 2010 to include two other key contributors, HUJI and the University of Pisa, and currently has no defined end-date, showing that these institutions are committed to sustainability and the long-term supervision of OneLab’s facilities. Although two key EC projects backing OneLab have now ended, further public funds have been actively sought and won, safeguarding the future development of the facility offerings and helping to continue the comprehensive support services currently available to users, ensuring that all OneLab offerings remain open to the public Internet research community, involving real-world end-users.
2.6.2. Use Cases
Since the majority of OneLab’s testbed nodes are open to the public Internet, the researcher can experiment with distributed applications in a real-life testing environment. This ability makes the PlanetLab environment, for example, an essential complement to controlled experiments in simulation or emulation environments. Unpredictable real-world traffic loads, routing changes, and failures put applications to the test in ways that a controlled environment cannot. Furthermore, researchers can deploy services that are used by regular Internet end-users worldwide. For example, one content distribution experiment on PlanetLab offers faster web downloading to thousands of end-users in countries across the world. The researchers who deployed this service use it to study application performance and end-user behaviour. A key benefit of OneLab’s offer to researchers is that it allows them to deploy their experiments at a global scale, exposing their applications to geographic and network topological diversity and allowing them to deploy services in proximity to end-users. While the testbeds’ own nodes are scattered essentially across Europe, federation with the global PlanetLab system (http://www.planet-lab.org/) provides European researchers with access to the combined system, which consists of over 1,000 nodes at over 500 sites worldwide.
OneLab Use Cases include the following:
· Network topologies
o Delays
o Available bandwidths
· Routing paradigms for wired and wireless networks
o Real-life routing changes
o Routing and content sharing topologies: minimizing routing traffic or content queries
· Real-world Internet traffic measurements
o Unpredictable traffic loads
· Applications failure recoveries
· Concurrent multipath transmissions
· System optimization for multi-hop networks
2.6.3. Usage policies
Users of testbeds within or federated to the OneLab facility are required to adhere to the OneLab Acceptable Use Policy (AUP) or a compatible AUP that governs their behaviour when making use of OneLab resources. This allows OneLab to handle incidents that arise across testbed boundaries, facilitating communication and allowing easy identification of those responsible. However, members of OneLab testbeds remain free to prioritize their own users or even allow them exclusive access to some resources. An additional service offered by OneLab is the management of the AUPs of participating testbeds.
2.6.3.1. How to connect to the facility
Over 140 institutions in Europe, representing over 1500 researchers, have signed user membership contracts with the PLE Consortium. To join as a user member (distinct from partnership), an institution contributes two server-class computers as PlanetLab Europe nodes. These machines are made freely available to all other PlanetLab users via the Internet. Because this openness requires responsible behaviour, member institutions legally commit their researchers to follow an AUP. At present, users of PlanetLab Europe have automatic access to the NITOS wireless testbed (which is freely available even without resource contribution). The DIMES testbed is open to any user provided that they install the DIMES software, and ETOMIC requires the contribution of a specially designed ETOMIC measurement box.
2.6.3.2. How to perform experiments
The PlanetLab Europe slice management interface is called MySlice (http://myslice.planet-lab.eu/). MySlice gives users both a web interface and a programmable API through which to manage their slices: starting with slice setup, through experiment run-time, to retrospective analysis of experimental data after an experiment is concluded. MySlice also offers visualization tools for data that has been collected.
The researcher can log in to each of these virtual machines via the SSH secure remote login tool, and will then be the root user in a Fedora 12 Linux environment. They can deploy whichever software they prefer on these virtual machines, subject only to a few restrictions based on the shared kernel. The researcher can also configure a delay and drop profile for packets entering and leaving a virtual machine, thereby turning its standard Ethernet link into an emulated wireless or DSL link for their slice. (The system also provides a few nodes that are connected via real Wi-Fi links.)
The NITOS wireless testbed in Volos offers researchers access using cOntrol Management Framework (OMF) open-source software. OMF simplifies the procedure of defining experiments and offers a more centralized way of deploying experiments and retrieving measurements.
2.6.3.3. Support organization for experimenters
UPMC and INRIA established the PlanetLab Europe Consortium in August 2008 as a partnership responsible for running the testbed, and the Consortium was expanded to include HUJI and UNIPI in 2010. CNRS (the French national research agency) funds the chief operations engineer position, UPMC itself provides additional legal and administrative support, the OneLab NOC (Network Operations Centre) employs a three-person development team at UPMC and INIRA, and also updates the documentation and tutorial videos offered through PlanetLab Europe online channels:
· Dailymotion: http://www.dailymotion.com/PlanetLabEurope
· YouTube: http://www.youtube.com/user/PlanetLabEurope.
2.6.3.4. Contract requirements for usage
Once you become a member of PlanetLab Europe, you can provision private virtual servers on any of over 1000 PlanetLab nodes. These virtual servers can be used to deploy live Internet services that are exposed to the same issues that arise in genuine production environments: variable bandwidth, diverse latencies, realistic robustness, and failure modes.
2.6.3.5. Plans how to accommodate new requirements for experiments
OneLab, through its core partners, is involved in numerous national and EU initiatives, either underway or soon to begin. Any new requirements from users will be developed during these new projects. The FIRE Architecture Board will also contribute to the development of these successors of the OneLab2 project, and in due course the new projects will define methods to attract, collect and meet the evolving requirements of users.
2.6.3.6. Cost of usage
Usage requirements vary depending on the testbed. PlanetLab Europe and ETOMIC require that a member institution contributes some hardware resources in exchange for the testbed access enjoyed by their users. DIMES is available to any user who installs its agent, while the NITOS wireless is freely open to any individual user, provided that they register with OneLab before using its scheduler to reserve a slice on the testbed.
2.6.4. International liaison
At present most of OneLab’s international liaisons are related to the PlanetLab Europe testbed’s connections with other PlanetLab-based structures worldwide. Federation between the PlanetLab Europe Consortium and the global PlanetLab Consortium is based on a Memorandum of Understanding between participating institutions. The OneLab coordinator, Professor Serge Fdida, sits on the Steering Committee of the global PlanetLab Consortium. On an international level, in addition to the federation between PlanetLab Europe and PlanetLab Central, OneLab has federated with PlanetLab Japan, Private PlanetLab Korea (PPK) and has also expanded the facility to include Chinese partners.
2.7. PII
2.7.1. Offering
The Panlab Infrastructure Implementation (PII) project and its predecessor Specific Support Action Panlab have elaborated on the concept of a Panlab office. The Panlab office is a testbed resource broker, whereby the brokered testbed resources are specialized ICT resources owned by testbed owners and normally available for testing and experimentation purposes by the customers.
The Panlab office arranges transactions between an organization and an individual interested to use testbed resources owned and operated by one or more testbed resource owners.
The Panlab office helps organizations owning testbed resources advertise service capabilities. The Panlab office then makes a commission when the deal is made and a contract is signed.
The Panlab office develops relationships with testbed owners and testbed operators and negotiates testing and experimentations contracts on behalf of the customers. The purpose of the Panlab office is to provide a single point of contact in which customers can access the entire available testbed resource market globally or regionally. The Panlab office will commonly advertise both managed and best effort testing and experimentation services.
A testbed owner is a special form of a Panlab office customer, called a Panlab partner.
To fulfil the goal of finding customers to lease testbed services, the Panlab office will do the following:
· Find testbed resources suited to the customers’ needs and specifications
· Request terms and conditions for lease that may be imposed by the testbed owner
· Request information about the testbed resources available and describe them for successful advertising
· List the testbed owners that offer testbed resources
· Advertise the testing and experimentation services available through listing in the resource broker tool (Teagle), newsletters, promotions and other methods
The primary business objective of the Panlab office is the provisioning of testbed resource brokering services.
The secondary business objective is the deployment and operation of a Network Operation Centre (NOC) for all available resources in the Panlab federation of testbeds.
2.7.1.1. Description of the facility
The facility offers through Teagle www.fire-teagle.org a number of central services to testbed providers and users. Such services include the description, registration, orchestration and provisioning of heterogonous federated testbed resources across participating provider domains. Currently, different resource types can be handled such as physical and virtual machines, devices, software, as well as abstract concepts and services. By means of a common information model, resources can be described, allowing for advanced control in a federated environment. The existing Teagle and federation framework prototypes that were developed in the Panlab/PII projects are available as open source under the Apache 2.0 license.
RADL (Resource Adapter Description Language) trac.panlab.net/trac/wiki/RADL is a component of the Teagle architecture that provides a textual syntax for describing the Resource Adapter (RA) middleware that provides the link between a user and a testbed resource. RADL decouples the RA from its underlying implementation code and can be used to publish a resource description to a resource repository.
Beyond the brokering service that the facility offers, a number of resources are available that allow the design and deployment of infrastructures for testing Next Generation Network (NGN) services and applications. These can be (for example) advanced multimedia services, such as conference calling and handling of presence information. Aspects that can be tested include session management, subscriber management, addressing, as well as Internet Multimedia Sub-system (IMS) interworking with the relevant gateways for connectivity to other networks. Important business relevant aspects that can be supported include provisioning, charging, device configuration, operation and management, and roaming across different IMS domains. Recently the facilities have been upgraded to support P2P/NGN QoS reservation mechanisms allowing for testing application level P2P traffic routing algorithms.
2.7.1.2. Main components - the timeline for the availability of the facility components
The current facilities are available independent of the Panlab/PII projects either as autonomous test centres or laboratories at the respective operators’ locations, or via the brokering service of the Panlab office. More specifically, the following operators have initially expressed their commitment to offer services via the Panlab office:
· Fraunhofer Fokus – IMS playground and other related capabilities, depending on demand
· TSSG/WIT NGN IMS testbed – including carrier grade IMS Communications Systems
· University of Patras – IMS testbed
· Cosmote – IMS infrastructure and computing resources
· …
2.7.2. Use Cases
A large number of different and quite heterogeneous Use Cases have been implemented in the PII project. The following list presents the Use Cases which can be retrieved in detail via http://www.panlab.net/use-cases.html:
· Testing trans-coding video through dynamic cloud allocation
· Testing Multicast Streaming on Dynamic Networks
· Testing Uncompressed HD Streaming
· EzWeb application over TID SDPLabs: “PII Message Sender”
· Testing end-to-end Self-Management in a Wireless Future Internet Environment
· Testing enhanced Web TV services over mobile phones
· Testing Adaptive admission control and resource allocation algorithms
· Stress testing the Open IMS core
· Testing a VOIP user agent
As can be inferred by the above examples, typical Use Cases that can be directly supported by the PII testbeds are Next Generation Network (NGN) services and applications.
2.7.3. Usage policies
The typical usage policy is based on a customer contract between the Panlab office and the experimenter or testing customer. The terms and conditions are typically commercial.
Subject to negotiations, other than commercial terms and conditions may be negotiated, in particular if experiments or tests are embedded in a joint research and development project with the participation of the owners of the testbeds.
Additional usage policies have been defined for owners of testbeds that join the Panlab federation via a contractual relationship with the Panlab office.
2.7.3.1. How to connect to the facility
The Panlab office supports customers to construct and deploy a so called VCT (Virtual Customer Testbed), which is a specific configuration of resources that match customer requirements. By default, a VCT is interconnected over a Virtual Private Network (VPN) that is automatically created to connect the resources that are part of a VCT. The customer can then access the resources in the VCT either via a secure remote access tool (e.g. SSH), or the customer equipment is connected to the VPN in which case the customer equipment becomes inherently part of the VCT.
User access to the System Under Test (SUT) that is deployed by the customer in the VCT is depending on the customer requirements and the availability of access networks at the desired locations. Typical commodity commercial access networks are available in most locations.
2.7.3.2. How to perform experiments
This is out of scope of the facility and is left to the experimenter to decide. A number of tools supporting experimentation can be booked as part of the VCT.
The most exciting capability is the Federation Computing Interface (FCI) and the Federation Scenario Description Language (FSDL). The FCI [trac.panlab.net/trac/wiki/FCI] is an Eclipse-based SDK and API for developing applications that access and control an experiment’s requested resources. The closely related FSDL is a domain specific language for specifying experimentation scenarios. FSDL provides an abstract syntax of a resource broker meta-model. The FSDL concrete syntax is supported by a text editor that implements instances of this meta-model. Syntax highlighting, context assistance, validation errors and warnings are some of the features. FSDL is available for the Eclipse workbench and the specification framework is provided as Eclipse plug-ins.
2.7.3.3. Support organization for experimenters.
The Panlab office will offer a development group and a support group.
The development group is responsible for the development of advanced services and enhanced service features that are deployed and operated by the Panlab office. Typically these services are related to the core technology for brokering and remotely managing testbed resources (Teagle, repository, Panlab testbed manager, resource adaptors, and interconnection gateway.). New services and features are deployed in consent with the Eurescom technical support director. The development team comprises Panlab partner organizations that work collaboratively in a virtual organization type of structure.
The support team is responsible for the operation of the Panlab office servers and the operation and troubleshooting of customer testing sessions. Similarly to the development team. the support team comprises Panlab partner organizations that work collaboratively in a virtual organization type of structure. One member of the Eurescom technical support team is member of the Panlab support team.
2.7.3.4. Contract requirements for usage
A contract with commercial terms and conditions must be negotiated and signed. Under certain conditions other terms and conditions are possible (see introduction to section 2.7.3 above).
2.7.3.5. Plans how to accommodate new requirements for experiments
In the case that the existing offering cannot support a certain experiment, the Panlab office foresees a “Call for testing” procedure that allows the Panlab office to procure external resources that can satisfy the requirement. These external resources will be offered under a reselling agreement with the external service provider or testbed owner.
In the case that the requirements are communicated in advance, the Panlab office and its partners can evaluate the possibility to develop the required offering “in-house” and possibly in collaboration with the customer.
2.7.3.6. Cost of usage
The main cost of usage is typically based on the estimated personnel cost that is necessary to support the construction, deployment and operation of a VCT and the experiment. The possible costs may vary due to the large variation of complexity of the possible experiments. The only meaningful measure is the average personnel cost of an engineer that will be assigned to support an experiment. Normally the cost will be fixed in the contract following the definition of the services that must be provided.
2.7.4. International liaison
At present the Panlab office maintains a liaison to the Synchromedia consortium and laboratory at École de technologie supérieure at the Université du Québec.
2.8. SmartSantander
2.8.1. Offering
SmartSantander is building a unique city-scale experimental research facility in support of typical applications and services for a smart city. The results achieved are expected to influence the definition and specification of Future Internet architecture design from the viewpoints of Internet of Things and Internet of Services.
This unique experimental facility will be sufficiently large, open and flexible to enable horizontal and vertical federation with other experimental facilities and stimulate the development of new applications by users of various types including experimental advanced research on IoT technologies, and a realistic assessment of user acceptability tests.
The facility will comprise more than 20,000 sensors. It is being built upon the results of two major EU-funded projects, SENSEI and WISEBED, and creating a secure and open platform aimed at the support of heterogeneous technologies.
Besides providing support to the experimentation, the infrastructure deployed will also deliver end services to the city authorities and citizens in general. It is this dual profile which makes SmartSantander unique.
2.8.1.1. Description of the facility
The SmartSantander architecture is depicted in the figure below, in which the three main interfaces: ASI (Application Support Interface), ESI (Experimentation Support Interface) and MSI (Management Support Interface) are shown.
Figure 12. SmartSantander Architecture
The constituent modules are running on top of the IoT nodes, gateways and the testbed Runtime Server. This architecture provides support to both experimentation and service provision. Currently, it is mapped onto the corresponding systems deployed around the city. In particular, 25 gateways, 750 repeaters (each of them integrating two IEEEE 802.15.4 devices one for experimentation and one for service provision) and 375 parking sensors buried in the asphalt (besides 500 temperature sensors, 60 noise sensors, 60 for presence detection, 60 for light intensity and 60 for CO) will be available for the scientific community. Hence, around 2,000 IoT devices will be available from the end of September 2011.
All these devices allow the experimenters to configure their own tests aiming at analysing different services, protocols and techniques by using OTAP/MOTAP (over-the-air/multihop over-the-air-programming) fully supported by the repeaters and gateways.
Figure 13. SmartSantandder Sensors
Finally, next figure shows some details of the experimental facility deployed in one of the streets parallel to the sea.
Figure 14. SmartSantander light sensors in the city
2.8.1.2. Main components - the timeline for the availability of the facility components
The SmartSantander experimental facility will be developed in 3 main cycles, with each cycle adding considerably more size and functionality. The main part of the deployments will concentrate on the city of Santander. Cycle 1 (to be finished in month 17) will have as a result a facility consisting of 2000 IoT devices. Cycle 2 (after 29 months) aims at offering 5000 nodes, and the final cycle will provide 12000 nodes plus the possibility to federate with other experimental facilities deployed in Belgrade, Guildford, Lübeck and possibly Melbourne. In terms of functionality, the consortium will gradually add features for testing and/or using experimental data management, horizontality (run several experiments from very different domains concurrently), verticality (testing of all different layers), mobility, security, heterogeneity and scalability.
Figure 15. SmartSantander Timing
The development of the platform for phases 2 and 3 will consider the demands of the platform beneficiaries (e.g. City of Santander and its citizens), advice from the stakeholder group and project reviewers as well as inputs from the community captured through Open Calls, surveys and workshops.
2.8.2. Use Cases
SmartSantander has identified a considerable number of Use Cases both for scientific experimentation and service execution for the citizens on the platform. In terms of services, Use Cases have been defined in the fields of traffic control (for instance, load/unload area management, disabled parking management, a virtual corridor for emergency vehicles, control of vehicles parked in bus stops), supporting people with disabilities and illnesses, cultural activities, smart metering, environmental monitoring, public transportation, urban waste management, multipurpose physical space interaction, smart schools, a precision irrigation management system, and aquifer management-monitoring system. In the first cycle, the implementation of these Use Cases concentrates on traffic control application areas.
For the scientific usage, a huge number of possible experiments have been devised, such as network coding techniques on top of massive wireless sensor nodes, IPv6 multicast in wireless sensor networks, geocasting routing protocols applied to a WSN environment, geographic routing for wireless sensor networks in the presence of network dynamics, IPv6-based interaction of sensor nodes and the Internet, Distributed Game-Theoretic Vertex Colouring for Frequency assignment and energy aware node partitioning and the evaluation of video quality under complex network deployment and different transmission technologies. The platform is open for further Use Cases.
2.8.3. Usage policies
Using some of the core WISEBED testbed runtime functionalities and others being - or to be - developed during the SmartSantander project duration, the experimental facility will be available under specific conditions to the scientific community as well as to companies or entities interested in testing a new technology or service in the framework of a smart city. Remote execution of the experiments is initially considered, although this aspect is subject to the specificities of each experimentation case. During the project duration, research activities will be supported by the project itself. Later, the experimental use of the facility will need specific resources to be dedicated to fulfil these requirements on a flexible approach. Contractual issues will be defined following a common basis according to FIRE principles.
2.8.3.1. How to connect to the facility
As a first approach, the project will provide some basic experimentation Use Cases in order to illustrate the different testing levels available, and the type of research suitable to be performed on top of the infrastructure. This will help to improve the external understanding of the testbed, and introduce potential researchers to the use of the experimentation support tools and the capabilities of the system.
Instructions describing the precise way to proceed to connect to the facility, make resource reservations and run the experiments will be provided once a fair usage commitment and the administrative pre-requisites have been fulfilled by the external user.
2.8.3.2. How to perform experiments
The first step to be able to run an experiment on the SmartSantander facility is to specify the experiment according to the on-line form that will be made available. To familiarize with the testbed architecture and its capabilities, it is highly recommended to read the information publicly released at the Open Calls Information Days, including the basic experiments description.
In order to be granted access to the testbed, any experiment proposer must provide a clear description of the tests to be performed and the essential information related to the proposed activities. These will include (among other aspects):
· The physical elements of the infrastructure required for the experiment
· The changes required on the different elements involved, if any (i.e. SW reprogramming, etc.)
· The data that needs to be collected during the execution of the experiment
· The time span: proposed time schedule and required duration of the tests
For resource reservations and configuration of the testbed elements, a management interface is being developed, and further information might also be required by the users through the experimenter’s web interface. The information required to remotely connect to the testbed in case it is necessary, and to gather experimental data once experiment is concluded, will be also provided through the web (programmable APIs, etc.).
2.8.3.3. Support organization for experimenters.
Experimenters becoming involved through the Open Calls mechanism will be provided with support by the consortium itself during the execution of the proposals. Apart from the on-line material and help that will be made available for external experimenters through the project website, specific resources will be provisioned according to the model developed within the exploitation and sustainability plan to guarantee the proper support to experimental activities beyond the duration of the project.
2.8.3.4. Contract requirements for usage
In general, to be granted access to the usage of any part of the facility, the experimenter’s entity will have to provide some administrative and legal guarantees related to the confidentiality of the information provided (NDA) and the commitment to a fair usage policy. The precise terms will be defined within the project. Specific contractual conditions apply to those institutions accessing the infrastructure through the Open Calls. These entities will become members of the consortium for a limited time span, and will have to accept the conditions of the project’s Consortium Agreement and other European regulation related to EC projects. These may include privacy issues, restrictions with regard to data management, etc..
2.8.3.5. Plans how to accommodate new requirements for experiments
Although a huge number of requirements have already been identified, the fact of having a cyclic approach in terms of design, implementation and deployment means that the project approach allows to gradually evolve and accommodate new requirements coming from external experimenters. Section 2.8.1.2 provides an overview of the 3 phases envisioned. While the first phase has been mainly driven by the consortium interest to establish a usable platform as soon as possible, the community has an opportunity to influence phase 2 and 3 design of the platform, in which the majority of the envisioned infrastructure will be deployed. Community requirements can be expressed as part of the 2 Open Calls for experiments. Furthermore, SmartSantander pro-actively seeks community requirements through surveys and workshops. An example has been the survey on IoT experimentation needs and the subsequent workshop organised at the IoT week in Barcelona on the 8th of June 2011. A further survey and workshop are planned for the next years.
2.8.3.6. Cost of usage
During the next two years the use of the platform will be cost free. Once the project has ended, an appropriate sustainable exploitation model will be fixed. This model is being conceived, taking into consideration the most relevant stakeholders. Both Regional Government and City Council have already initiated actions for providing economical support once the project has ended.
2.8.4. International liaison
The platform developed in SmartSantander is intended to be used in other smart city environments. Currently, activities to prepare the deployments are already going on in Guildford, Belgrade, and Lübeck. Furthermore, synergies and complementarities are being identified with Aarhus, Berlin, Birmingham and Trento. The main idea is to experiment on the service plane aiming at correlating and extrapolating the results obtained on the mentioned sites. This collaborative experimentation in the service plane is facilitated by the interaction brought by the OUTSMART project belonging to the FI-PPP. A number of links are also being maintained with other European smart city initiatives, like the SenseSmartCity project developed in Skellefteå (Sweden). Some discussions concerning collaboration with US testbeds under the GENI program have already started at previous EC workshops. First steps are being given to enhance co-operation with the ORBIT testbed at WINLAB.
2.9. TEFIS
2.9.1. Offering
TEFIS, a Testbed for Future Internet Services, seeks to support the Internet of Services community, by providing testbeds which can support the entire service lifecycle, including user behaviour, scale, performance and SLA compliance. It brings together FIRE-type test facilities for traditional IT-based testing with Living Labs to offer a full range of experimental capabilities. The combination of testbeds offered by TEFIS allows a broad range of service characteristics to be explored including functionality, performance, scalability, usability, maintainability, user experience/acceptability, and standards compliance.
Table 1 below summarises the testing objectives and how they relate to the ITIL Service Lifecycle. In supporting experimentation with a view to improving services, all of these requirements need to be catered for.
Table 1. TEFIS service testing objectives
| Objective | ITIL Service Lifecycle Phase(s) | Requirements |
| Functional | Transition | Validate that all function is available and works as expected |
| Performance | Design; Transition | Validate that the service continues to operate during all predicted loads; validate that configuration recommendations are appropriate. |
| Scalability | Design; Transition; Operation | Validate that the service continues to operate in the same way at different levels of load; validate that all requirements for deployment scenarios can be met. |
| Usability | Transition | Validate that users are able to access and use the functions offered. |
| Maintainability | Transition; Operation | Validate that the service can be deployed and continue to run in the operational environment. |
| Acceptance | Transition | Validate that users are comfortable with the design and how to use the service. |
| Standards Compliance | Design | Validate that all appropriate standards or regulations have been met. |
Individually, the testbeds made available to experimenters can be expected to be able to provide support for these objectives. However, it is not necessarily the case that all of these objectives will be met by a single test facility. This is a major contribution of TEFIS: managing access to a range of different testbeds which can support all of these objectives within a single experiment and test run, or across multiple experiments and test runs.
2.9.1.1. Main components - the timeline for the availability of the facility components
TEFIS provides a single access point to be guided through and supported during all phases of experiment design and execution on federated test resources. Figure 16 shows the TEFIS infrastructure from experimenter (top) out to the federated testbeds (bottom). The platform itself in made up of five basic components: the TEFIS portal, the TEFIS middleware embedding the TEFIS core services supporting overall operation and control, the Experiment data manager, and a connector interface to communicate with the federated testbeds.
Figure 16: TEFIS functional architecture
The TEFIS portal is the main access point for the user to create an account (the TEFIS Identity Manager Interface), to search for resource (the TEFIS Directory Interface) and to design the workflow for their experiment (the TEFIS Experiment Manager Interface). Each of these is supported by a corresponding component within the TEFIS middleware (the Identity Manager, the Resource Directory and the Experiment Manager, respectively). In addition, the TEFIS Experimental Data Interface allows the experimenter to search any existing experiments to locate those with similar goals or set-up to what they are proposing, as well as to interact with monitoring data and experimental results once the experiment or an individual run completes.
The Core Services manages the whole platform and the execution of the experimenter’s test runs. The Experiment and Workflow Scheduler takes the workflow created by the experimenter and presents it for execution to the appropriate test resource. The Resource Manager interacts with the resources to reserve and initiate them. The Supervision Manager handles all monitoring activities, checking performance within the TEFIS environment itself as well as communicating with the testbeds to retrieve monitoring output from them.
The Connector Interface provides the central control for all communication to and from the testbeds. It is a significant benefit of TEFIS that it can offer not only support to experimenters, but also to testbed providers. Both users (experimenters) and providers (testbeds) are essential participants in the TEFIS platform and vision. It is the Connector Interface that provides the mechanism for these communities to co-operate.
The Data Services support the other TEFIS components as well as experimenters and testbed providers with all of the data needs associated with an experiment. The TEFIS data filesystem holds all data and information necessary for the satisfactory execution of an experimental test run, as well as providing storage for output data from each workflow step. Through the experimental metadata we have defined, experiments can be tracked and browsed in support of experimenters within the community wanting to find or review related work.
TEFIS implements a step wise approach spanning over 3 phases:
- Phase 1: Architecture and development of the TEFIS platform (M1-M9). During this first phase activities are dedicated to define the overall architecture of the TEFIS platform, to develop the TEFIS portal and user tools, to implement the core services of the platform, to define, specify and develop the connectors for experimental facilities provided by TEFIS consortium, develop the experimental data management tools and integrate the building blocks to form the TEFIS platform prototype (WP2)
- Phase 2: Operation of the TEFIS platform and Open Call (M9-18). During a second phase the focus is put on the deployment and operation of the TEFIS platform, assessment of the platform with the start of the experiments with the eHealth and eCommerce Use Cases and execution of the Open Call process to select new Use Case applications and identify new requirements to expand the functionalities of the platform
- Phase 3: Functionalities expansion of the TEFIS platform and experiments (M18-30). As the project reaches its last period, particular efforts will be made to strengthen and expand the functionalities of the TEFIS platform in a demand-driven way according to the new requirements arising from the Open Calls to support users in running experiments on the platform
Figure 17: TEFIS
detailed work plan
2.9.2. Use Cases
The TEFIS platform has examined a number of representative Future Internet scenarios, including eCommerce, multimedia services and eHealth. The scenarios provide a powerful demonstration of the benefits of TEFIS in each requiring multiple test facilities to be managed as a single, complete test entity for various stages of the specific tests.
Table 2. TEFIS Use Case summary
| Test Case | ITIL Service Lifecyle Stage | Description | Testbeds Used | Benefits |
| eCommerce | Design: performance and capacity planning Transition: validation, change management, service validation Operation ; incident and problem management | For complex services which dynamically aggregate functions from different SOA-type components, there is a basic requirement to be able to validate performance in different environments and within strict SLA-terms. This Use Case investigates optimal service creation and performance. Requires multiple operational environments. | · ETICS: to build the application(s) and check functional coverage · PACA Grid and PlanetLab: to evaluate performance in different client environments | TEFIS provides a single access point for all test stages. TEFIS provides the seamless integration and management of test steps across different environments, including the automatic transfer of appropriate data from output of one process to input of another. TEFIS can be used to generate simulated load to drive stress testing. |
| Multimedia services | Design: investigation of business model Transition: evaluation, service validation and testing Operation: none | A mobile network operator wants to offer a new IMS service to its customers. Before deployment in the live network, they want to ensure that: · The user experience is positive; and · The best business model is chosen.
The test is to be run in a number of stages including usability, end-user testing, and the evaluation of the business model. The test includes the operator, the application developer, as well as end-users. | · The IMS platform is used to provide the infrastructure where the tests are to be run · BOTNIA living lab will provide the end-users to interact with the service for evaluation | TEFIS manages all stages of the experimental design and execution as well as each of the test roles. TEFIS provides a single access gateway to the different stakeholders as well as the different sets of data required as input and generated as output from the experiment. |
| eHealth | Design: Service level, risk, capacity management Transition: Evaluation Operation: access and event management | For a multi-disciplinary medical team, especially when working in different locations including the patient’s home, it is important to be able to make medical records available to all team members as quickly as possible. As multi-media records, these are large data objects; as personal data, they are also sensitive. This is based on the GIMED project. | · KyaTera: will provide the ability to transmit, store, search and recover multimedia information or an electronic PMR (Patient Medical Record). · ETICS: provides measures of software quality for the utilities used to manage and access the data. · PACA Grid: supports the simulation of geographical distribution and processing as well as to generate a suitable stress test for the eHealth system. | The TEFIS platform provides the management of the test across different environments. The TEFIS platform will also generate mock-up PMRs for use during the tests, since real data would be very sensitive. |
Table 2 summarises an initial set of Use Cases that will prove the capabilities of the TEFIS platform in enabling complex testing across the various ITIL Service Lifecycle phases. The three initial tests for eCommerce, multimedia services and eHealth exploit the different test facilities available within the TEFIS platform. For the experimenter in each case, the TEFIS portal provides the appropriate support for the design and execution of the various tests using different facilities as described in the table. In addition, TEFIS would allow the experimenter to search for and review related experiments that have been run previously on the platform. This is an important feature in support of experiment definition. In the next section, such features of the TEFIS platform which are intended to support all testing activities are summarised and described in more detail.
2.9.3. Usage policies
The TEFIS facility will be made available to registered experimenters from the scientific community and from interested companies, both through Open Calls and through non-funded mechanisms.
2.9.3.1. How to connect to the facility
The TEFIS portal is already online but initially for private use only. Its opening is envisioned to be progressive until the end of the project. The consortium will however carefully consider every access requests as a mean to enrich the set of functionalities that will be offered.
2.9.3.2. How to perform experiments
TEFIS offers a portal for experimenters which provide:
· Faster experiment development in supporting review and searching of previous and related experiments, as well as supporting experimenters through the various stages of preparation, workflow definition and execution
· Brokerage of test resources; testbed providers are given access to a wider potential user audience through a common and experimenter-supportive interface; and experimenters can submit a single experiment to be run across as many testbeds as are appropriate to satisfy their test requirements
· Multiple test facilities. The TEFIS platform provides access to different facilities offering different services and capabilities, from large computer clusters to highly distributed systems and network simulators. A significant benefit that TEFIS currently provides is the availability of a Living Lab (Botnia) within the current test facilities that may be federated
· Community Support through the facility to be able to share results as well as set-up. TEFIS may also enable the exchange of information and data between experimenters with similar goals and aspirations
2.9.3.3. Support organization for experimenters.
The support organization for experimenters is the consortium itself for now, represented by its coordinator (Thales Services SA).
2.9.3.4. Contract requirements for usage
The contractual requirements for TEFIS usage is currently being discussed within the project.
2.9.3.5. Plans how to accommodate new requirements for experiments
TEFIS intends to explore community building as a way to gather new requirements that may not have been anticipated in the beginning. Sharing experimental outcomes and set-ups between different experiments does in itself promote a sense of community. However, over time and with the co-operation of its users, the TEFIS platform can offer more, not only as a portal to access different facilities and review other experiments. As experiments are run and information about them (experimental metadata) becomes available, it will become possible to profile experiment types, usage patterns, and even begin to categorise experimental domains entirely on the basis of real experience. Such information will help the community of users directly as they run their own experiments, but will also provide valuable insights for the Future Internet community at large.
2.9.3.6. Cost of usage
The TEFIS facility relies on a distributed set of testbed facilities which each have their own technical requirements, usage protocols and administrative policies. For the duration of the project there is no additional constraint applied by the TEFIS project on top of those of the pre-existing infrastructures. One of the activities in the project is targeted towards the identification of suitable models for continuing the support (in particular maintenance costs) after the end of the project.
2.9.4. International liaison
One of the testbeds that TEFIS encompasses is the KyaTera facility in Brazil. KyaTera is a high-performance fibre-optic network, which grew out of an original effort to support collaboration between different members of the Brazilian scientific community for the development of the science, technologies and applications appropriate to the Future Internet. It provides the capability to evaluate the quality of the network, especially when complex objects, such as multi-media data, need to be transmitted to a specific level of quality. The different parameters affecting Quality of Service can be identified and explored. The benefit for TEFIS users is advanced and controlled network capabilities to be able to investigate all aspects of transmission and Quality of Service.
2.10. WISEBED
2.10.1. Offering
WISEBED offers a federated wireless sensor network testbed (www.wisebed.eu) that comprises approximately 1000 nodes distributed over 9 European sites and an algorithm library for the platform-independent and efficient implementation of algorithms (www.wiselib.org). In addition, the WISEBED consortium maintains a set of open APIs for testbed management, use, and operation as well as a reference implementation of these APIs. Both are used to run the testbeds of WISEBED and SmartSantander.
2.10.1.1. Description of the facility
The main feature of the WISEBED platform is its virtuality. It is easy to interconnect all kinds of sensor networks or even only single sensor nodes into one huge virtual testbed. WISEBED’s architecture and main features are shown in Figure 18.
Figure 18. WISEBED architecture
One of the main ideas is that it is possible for providers to install their own implementations of the APIs and clients of these APIs. Figure 19 shows the available APIs and their functionality. A formal description is available at the WISEBED website.
2.10.1.2. Main components - the timeline for the availability of the facility components
The full functionality is available now; there is no further development plan, since the project has already ended.
2.10.2. Use Cases
The WISEBED consortium has collected more than ten Use Cases giving a good overview of the potential of the platform. The Use Cases range from single student projects, for instance on the evaluation of cryptographic protocols, to industry projects (coalescences GmbH evaluated their implementation of the CoAP protocol) to complete EU projects running a vast set of experiments (in this case the FRONTS project).
2.10.3. Usage policies
WISEBED is open for any registered user. Registration information is available on www.wisebed.eu. Each individual testbed and the federated testbed offers a set of WISEBED Web Service APIs and a number of clients (web-based, command-line driven, etc.) exist. Experiments are conducted by uploading programs to the sensor nodes via the APIs, by receiving performance metrics emitted by the nodes, and by sending messages to the nodes for experimentation control.
2.10.3.1. How to connect to the facility
In order to perform experiments, users first have to obtain an account. This is done by following the instructions on the WISEBED website. Once an account has been set-up, experimenters use their account information in order to access the testbed management application. Currently, authentication is done via Shibboleth, though this left open to the implementer of a testbed (someone who wants to set-up his own testbed).
2.10.3.2. How to perform experiments
Experiments are performed following the “algorithm” shown in Figure 20.
Figure 20. Performing experiments in WISEBED
First, the experimenter has to create the software implementation of the protocol/algorithm/application to be experimented with. Afterwards, he has to select the nodes and networks to be included in the virtual testbed. Then, he asks for a reservation and is given a secret key (a handle) for it. At the scheduled time for the experiment, the necessary nodes will be reserved and the testbed will be instantiated. Then, the experiment will be executed. During this time, the testbed can even be reconfigured. Finally, when the experiment is ended, the user can collect the resulting data.
2.10.3.3. Support organization for experimenters.
Currently, all 9 WISEBED partners offer support for the experimenter. Since the project has ended, this is currently a temporary solution; the partners are in the process of creating a WISEBED foundation which will have the goal of running the infrastructure and further developing the software.
2.10.3.4. Contract requirements for usage
WISEBED usage is still free of charge, however, this will change in the near future. For running new FP7 and FP8 projects, the WISEBED partners expect to be contacted first in order to become involved in the application process.
2.10.3.5. Plans how to accommodate new requirements for experiments
Further API and platform enhancements are realized in cooperation with SmartSantander. The process is open for third parties and the reference implementation is open source (https://www.itm.uni-luebeck.de/projects/testbed-runtime).
2.10.3.6. Cost of usage
During the project runtime (until end of May 2011), the usage of the platform was free of charge for everyone interested, without any limitations in experiment duration or permitted resource usage. In order to keep up the infrastructure and continue developing the WISEBED software, the former consortium currently plans to build a foundation which would be responsible for operating the WISEBED infrastructure, including AAA issues. In the meantime, WISEBED can still be used free of charge.
2.10.4. International liaison
WISEBED has already been used and extended by non-European partners, namely an Argentinean university which created a testbed and connected it to the WISEBED, and a university from New Zealand which ran experiments on the platform.
Report II: Sharing among testbeds: Components and Standards
3. Sharing among testbeds – components and standards (editor UPMC)
This part relies on section I and aims at identifying the common parts and main differences as of today.
Sharing/interconnecting data, not only resources, is crucial since it will enable the sharing of data across experiments. Benchmarking and repeatability of experiments is key to experiments of high quality and scientific impact. This will put requirements on format, storage, and access to experimental input data and results. It will also require comparable methods for measurement. Data archiving will become increasingly important as user projects evolve. Standards and shared tools in this area should be organized once the shape of the experiments performed under the Open Calls is visible.
FIRE coordination should take the lead in identifying appropriate levels of user support and ensuring that the best practices are shared across the FIRE portfolio.
This coordination needs to be streamlined in the light of the upcoming PPP and the Calls 7 and 8.
3.1. Control Plane and Experimental Plane
3.2. Tools
3.3. Operation and legal framework
The most critical conditions for offering the FIRE testbed in a federation are:
1. If the federation is meaningful and beneficial
2. If there exist suitable policies for managing the federated resources efficiently
To answer both questions one needs to formulate a suitable economic model that will capture the utilities, costs, and overall behaviour of the main actors of federation. Our objective is to devise a qualitative way to compare different types of policies and federation architectures. The ultimate goal is to design policies that lead the system to the desirable equilibrium based on the high-level objectives.
3.4. User’s management
3.5. Liaison with PPP and international initiatives
4. Sustainability, legal and business issues (editor A. Gavras/JaCQUES MAGEN)
Sustainability of each FIRE experimental facility shall be studied in the context of a sustainable FIRE federated facility.
4.1. Sustainability
4.2. Legal framework
4.3. Business and other issues
5. Federated testbeds (editor M. Boniface)
The selection on use of facilities when heterogeneous federation is required has to be a decision based on implementation cost and goals/interest of the involved individual facilities. As a result, the combinations (projects, Use Cases, and users) leading to the most exciting advances are - and will be - rare. These must be cultivated. There has been progress in top-down federation in FIRE projects, while SFA (in FIRE + GENI) has shown potential for scalability in bottom-up federation. FIRE should address the integration of these two approaches.
5.1. Definitions
5.2. Rationale
5.3. Experimenters needs
5.4. Offered services
6. Integration and interoperability plans (editor P. Demeester)
6.1. Common interconnection
6.2. Federation of Tools for experimentation
6.3. Timing of interconnection within FIRE
6.4. Individual / case-specific objectives in the FIRE context
7. Conclusions and recommendation (editor J. Wilander)
8. References
[1] A. Bavier, M. Bowman, B. Chun, D. Culler, S. Karlin, S. Muir, L. Peterson, T. Roscoe, T. Spalink, and M. Wawrzoniak, Operating System Support for Planetary-Scale Network Services," in First Symposium on Networked Systems Design and Implementation, 2004.
[2] L. Peterson, A. Bavier, M. Fiuczynski, and S. Muir, Experiences using PlanetLab, in Proc. 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI '06), 2006.
9. List of abbreviations
3GPP 3rd Generation Partnership Project
AAA Authentication, Authorization and Accounting
API Application Programming Interface
ASI Application Support Interface
AUP Acceptable Use Policy
B2BUA Back-to-Back User Agent
CoAP Constrained Application Protocol
ESI Experimentation Support Interface
FCI Federation Computing Interface
FSDL Federation Scenario Description Language
GSM Global System for Mobile communications
IaaS Infrastructure as a Service
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IMS Internet Multimedia Sub-system
IP Internet Protocol
ISM band Industrial, Scientific and Medical radio frequencies
ITIL Information Technology Infrastructure Library
LTE Long Term Evolution
MOTAP Multihop Over-The-Air-Programming
MSI Management Support Interface
NGN Next Generation Network
NOC Network Operations Centre
OCCI Open Cloud Computing Interface
OF OpenFlow
OMF cOntrol Management Framework
OTAP Over-The-Air
OVF Open Virtualization Format
PoP Point of Presence
QoS Quality of Service
RA Resource Adapter
RADL Resource Adapter Description Language
SDK Software Development Kit
SFA Slice Federation Architecture
SIP Session Initiation Protocol
SLA Service Level Agreement
SUT System Under Test
TVWS Thermal/Visible Weapon Sight
UE User Equipment
UMTS Universal Mobile Telecommunications System
VCT Virtual Customer Testbed
WiFi Wireless Fidelity (IEEE 802.11)
WiMAX Worldwide Interoperability for Microwave Access
VLAN Virtual LAN
WLAN Wireless Local Area Network
VM Virtual Machine
VoIP Voice over IP
VPN Virtual Private Network
WSN Wireless Sensor Network
[1] https://github.com/crohr/restfully
[2] Outdoor testbed from the Josef Stefan Institute will be only available for the second Open Call (September 2012)