Contract Delivery Date Actual Delivery Date Deliverable Type

1 Introduction

With the advent of powerful Internet-connected objects such as smart phones, personal digital assistants and tablet computers, an ever increasing number of European citizens have constant access to the wealth of information stored on the millions of servers connected via the Internet. At the present time, the availability of such connected objects is causing a drastic paradigm shift in the way people deal with information. Instead of collecting – and printing – potentially relevant information in advance using a personal computer that is only available at particular locations, they now access more and more information on-demand and on-the-go.

Yet, despite this significant change in behavior, the technical means to access information have only changed marginally. In most cases, information is accessed via the web which requires users to memorize long URLs, click through sequences of web pages or browse through irrelevant search results. Alternatively, if they are frequently accessing the same service, they may install an app or application that provides more convenient access. However, such an installation requires advance planning and does not provide suitable support for services that are primarily useful in a particular environment. Moreover, even if they are using a local proxy, the utilization of a more complex service, for example, to book a train ticket, requires users to specify numerous inputs such as destination, time, etc. using miniaturized and often, inadequate peripherals. As a consequence, the state-of-the-art puts a natural limit on the complexity of the software and thus, on the level of support, that can be gained from existing services.

In contrast to this, ubiquitous computing envisions services which provide seamless and distraction- free support for simple and complex everyday tasks of their users. In order to realize this vision, the set of services that is available and the services themselves must adapt to the user’s situation, behavior and to varying user intents. Thereby, this adaptation must be performed autonomously in order to ensure that it does not conflict with the goal of providing a distraction-free user experience. This, in turn, requires services to gather a broad range of characteristics of the user's context at runtime. Examples for these characteristics include the user's location, activity, plans and goals.

Internet-connected objects such as smart mobile phones and personal digital assistants provide a promising basis for determining user context in an automated manner on a large scale. The reasons for this are manifold. First and foremost, many Internet-connected objects are self-contained and do not require additional infrastructure support, but existing cellular and wireless local area networks can provide the backbone for object-to-object interaction if needed. Secondly, though these objects are often resource-constrained, newer generations are designed to support more complex tasks such as displaying a high-resolution movie. As a consequence, the objects are often not utilized to their fullest capacity, leaving enough resources to perform context recognition. Thirdly, with a variety of on-board sensor, many Internet-connected objects have access to both physical and virtual data sources which allows multi-modal context recognition with high precision. Lastly, since the objects are often carried by and owned by a single user continuously, the object’s context is tightly correlated to the user's context and the recognition alone does not invade privacy.

In the past, these characteristics have contributed to the development of a number of context recognition systems for Internet-connected objects. The recognition methods applied by existing systems are usually fine-tuned for specific requirements in order to provide reasonably accurate results while requiring limited resources. Although, these methods are suitable for accurately In the past, these characteristics have contributed to the development of a number of context recognition systems for Internet-connected objects. The recognition methods applied by existing systems are usually fine-tuned for specific requirements in order to provide reasonably accurate results while requiring limited resources. Although, these methods are suitable for accurately

The vision of ubiquitous computing, however, extends beyond the boundaries of a single service as it envisions seamless support for everyday tasks. As a consequence, achieving the overall vision of ubiquitous computing raises a number of novel research challenges which include:

- the development of concepts to support the automated recognition of a broad range of context information types to support a variety of application scenarios in a generic fashion, - the development of context recognition methods that are able to cope to the limited resource availability and energy-constraints of resource-poor connected objects, - the development of novel data acquisition and distribution protocols to share context

information in order to increase the recognition accuracy without endangering privacy, - the definition of an interoperable data representation model for context information and associated query models to support object to object communication, - the design of a scalable data infrastructure to share and aggregate possibly frequently changing context information gathered by a large number of connected objects, - the development of tools to reduce the required amount of manual configuration of policies and the mechanisms to validate them in order to protect the privacy of users, - the design of new context-based human computer interaction techniques that are able to incorporate user goals and intents.

1.1 Objectives

GAMBAS is geared towards addressing the complete set of challenges listed in the previous section in order to provide a truly integrated solution, thereby closing a significant gap be tween today’s systems and the vision of ubiquitous computing. Towards this end, the primary result of the project is the realization of a Generic Adaptive Middleware, i.e. a set of application-independent services, to support the development and utilization of Behavior-driven Autonomous Services.

The GAMBAS middleware will enable the development of novel applications and Internet-based services that utilize context information in order to adapt to the behavior of the user autonomously. To do this, the middleware will provide the means to gather context in a generic, yet resource- efficient manner and it will support the privacy-preserving sharing of the acquired data. Thereby, it will apply interoperable data representations which support scalable processing of data gathered from a large number of Internet-connected objects. In order to make the resulting novel services accessible to the user, the middleware will also support intent-aware interaction by providing a constant stream of relevant recommendations for services.

The realization of the GAMBAS middleware requires the development and integration of a flexible context recognition framework that is able to capture the context of users (e.g. location, activity, plans, intents), an interoperable data model to represent context information, a scalable data processing infrastructure to query and aggregate context information and to integrate context into services, a suite of security protocols to enforce the user’s privacy when sharing context information and last but not least, a recommendation system to largely automate the discovery and selection of relevant services available to the user. In addition, it requires tools to simplify the configuration of The realization of the GAMBAS middleware requires the development and integration of a flexible context recognition framework that is able to capture the context of users (e.g. location, activity, plans, intents), an interoperable data model to represent context information, a scalable data processing infrastructure to query and aggregate context information and to integrate context into services, a suite of security protocols to enforce the user’s privacy when sharing context information and last but not least, a recommendation system to largely automate the discovery and selection of relevant services available to the user. In addition, it requires tools to simplify the configuration of

In order to validate the project’s results in a realistic environment, the GAMBAS consortium will develop a prototype application that builds upon the concepts and mechanisms provided by the middleware and the associated tools. In particular, the GAMBAS prototype application will be

developed for the public transportation domain since it is truly ubiquitous and it exhibits all challenges described previously. Furthermore, robust working solutions in this domain exhibit a high potential to achieve a significant impact.

Thus, in summary, the GAMBAS project has the following scientific and technical objectives:

1. Development of a generic adaptive middleware for behavior-driven autonomous services that encompasses:

a. Models and infrastructures to support the interoperable representation and scalable processing of context.

b. Frameworks and methods to support the generic yet resource-efficient multi-modal recognition of context.

c. Protocols and tools to derive, generalize, and enforce user-specific privacy-policies.

d. Techniques and concepts to optimize the interaction with behavior-driven services.

2. Validation of the middleware and its components using lab tests and a prototype application in the public transportation domain.

1.2 Purpose

As a requirements specification, this document describes the results of the requirement elicitation for the GAMBAS project performed as one of the activities of the first work package. Thereby, it acts as a main deliverable of the work package. Apart from that, this document provides the key starting point for the research and development activities of the GAMBAS project by identifying requirements for the work packages two to five. Naturally, these requirements may not be static but they may evolve to some extend over the course of a European research project, especially, when it lasts for several years.

Yet, having a clearly communicated and commonly shared understanding of the goals at the very beginning of the project is an invaluable tool for ensuring that the final results are satisfactory and achievable within time and budget. Furthermore, the specified requirements can also be used as a measurement tool to track the overall progress of the individual activities. Finally, the successful and joint execution of a complex process such as a requirement elicitation, whose results are documented in this specification, demonstrates the consent of the whole project consortium on the scope and goals of the individual project parts.

The intended audiences for this document are primarily the GAMBAS stake-holders as well as the GAMBAS research and development teams of the consortium. However, as a public document this requirements specification will be freely available for other interested parties as well.

1.3 Scope

This requirement specification document describes the final requirements that have been gathered, discussed and reviewed as part of a joint activity of the whole GAMBAS consortium. For the sake of brevity, it does not describe the intermediate versions of requirements or the steps that have been This requirement specification document describes the final requirements that have been gathered, discussed and reviewed as part of a joint activity of the whole GAMBAS consortium. For the sake of brevity, it does not describe the intermediate versions of requirements or the steps that have been

Moreover, this requirement specification document does not include use cases and application scenarios. These are described within a separate document developed simultaneously within the first work package of the project. However, the separation of use-case specification and requirements specification does not mean that they have been created in isolation. Naturally, important modifications to the use-cases are reflected appropriately in the requirement specification by updating the derived requirements. Furthermore, the requirements described in this document will provide a valuable input for the use case analysis in order to identify application prototypes that demonstrate the important aspects of the software infrastructure.

It must be noted that the requirement specification describes all requirements that have been gathered in WP1 at the beginning of the project. Thus, it may contain requirements that may not be implemented due to time or budget constraints later on. To ensure that the important requirements are covered by the later specifications and implementations, the consortium has jointly assigned priorities to the requirements. These priorities group the requirements into three classes: high, medium and low. If it is not possible to realize all requirements, the project consortium will relax or drop low priority requirements before medium priority requirements and medium priority requirements before high priority requirements. However, the project consortium has already committed to implement all high priority requirements and the majority of the medium priority requirements.

1.4 Methodology

Gathering the requirements from all stake-holders in a project is a key success factor. The requirements not only describe different aspects of a project but they also help to identify conflicting features in early stages. For such an important step – that identifies and affects the overall outcome of the project – it is worth investing considerable efforts and utilizing proper tools. Considering this, we have chosen the Volere methodology [VOLE12] for describing and managing requirements which we have extended with a consecutive prioritization phase. In the following, we discuss the rationale for using Volere and we describe the classification categories and the process.

1.4.1 Elicitation

The Volere methodology is not new to the project partners. It was first used by a number of the project partners in EMMA and PECES projects where it was used mainly because of its simplicity. It helped project partners to describe, formalize and track the project requirements in an explicit and unambiguous manner. Besides being a success in the EMMA and PECES projects, the Volere methodology was selected for the following three reasons:

1. The Volere methodology requires simple steps to identify and formalize the requirements in an unambiguous manner.

2. The Volere methodology provides an easy process to track and evaluate the progress of the project.

3. A number of the project partners have already experience with the Volere methodology. Hence, they did not experience an extra learning effort.

The consequent application of the Volere methodology is not only useful in the initial phases of the project for specifying requirements but it is also helpful in specifying a reference point for the later stages. During the use case analysis, for example, it can be used to ensure that different use cases cover different aspects of the requirements and that all important requirements are covered by them. During the implementation and management, it can be used to track and evaluate the progress of the individual work packages and the overall project. Besides being efficient and easy to use, the Volere methodology provides a mechanism for all partners to specify the requirements in a standard format. Thereby, specifying additional context of a requirement such as the rationale and the acceptance criteria for every requirement helps to build a common understanding of the overall system. Furthermore, defining priorities helps to clarify the focus of the project.

1.4.2 Prioritization

In order to prioritize requirements, the project consortium has introduced three different classes of priorities. These classes range from high over medium to low and the consortium has defined them as follows:

 High: Requirements in this class are either realizing a key innovation of the project or they are needed to realize a key innovation or the prototype application. These requirements are

necessary to achieve the goals of the project or they are necessary to demonstrate the project’s success.

 Medium: Requirements in this class represent optimization criteria that shall be investigated once the high priority requirements have been realized. These requirements are important to increase the applicability of the concepts and implementations developed by the project.

 Low: Requirements in this class are neither realizing a key innovation nor (strictly) necessary for the prototype application. However, in a broader context – possibly beyond the scope of the project – they may be important.

As a consequence, for the success of the project, it is essential to realize the requirements with high priority. In order to ensure the broadest possible applicability of the developed concepts it is furthermore necessary to ensure a high level of achievement with respect to medium priority requirements. The requirements with low priority, however, are not of immediate relevance for the project. However, their realization may provide additional features or benefits for applications or users that should be considered after all requirements of the other two classes have been implemented successfully.

In order give all stake-holders and interested parties an insight into the prioritization process, the consortium has not only assigned categories to each requirement but it has decided to include the main rationale for this classification in this document. Besides from being informative, this can be helpful in later stages of the project where unforeseeable issues may require the introduction of new requirements or changes to existing requirements.

1.5 Tool

Aiming at defining an optimum and complete list of requirements, a web tool based on the Volere methodology was used. This web tool has facilitated the definition, the validation and the prioritization of the project requirements.

Figure 1 – Volere Tool

For security reasons, the access to the web tool has been restricted to authorized users. User accounts have been created for each of the partners participating in the requirements elicitation process.

1.5.1 Process

The overall process of Volere as supported by the web tool is depicted below. After an initial specification of requirements, the users can specify conflicts, dependencies and objections. After specifying them, they can iteratively revise the specification and identify additional issues until it is free of conflicts, dependencies and objections.

Definition

Validation

Revision

Issues

No Issues

Final Requirements

Figure 2 – Process

The result will constitute the final list of requirements. The following subsections briefly outline the individual steps.

1.5.2 Definition

In this first stage all the requirements needed to accomplish the project objectives must be defined. These will be refined in future stages. The most useful information and the main functionalities at this stage available at the home page are:

Figure 3 - Definition

 Create a new requirement: All the fields are required except for “Comments and supporting material” which is optional. The required fields are: o Type: The scope of this appended by an automatically generated sequential number,

this ID uniquely identifies each requirement. o Description: A one sentence statement which describes the intention of the

requirement. o Type: The type of the requirement as defined by Volere. o Rationale: A justification of the requirement.

o Acceptance criteria: A measurement of the requirement for further verification that the solution matches the original requirement.

o Satisfaction: The grade of satisfaction for the customer if the requirement is successfully implemented.  Help: An external link to Volere requirements specification template.

 List of requirements: The list of requirements with some additional options. o Filtering options: The list of requirements filtered by type and/or filtered by author.

o Expand table: Show/hide some columns, displaying more or less information about the requirement.  Requirements management: Modification options for requirements. o View a requirement. o Edit a requirement (only available for the author).

o Delete a requirement (only available for the author).  Requirements tracing: After the first validation, a new service is made available for keeping

track of all the requirements history.

1.5.3 Validation

After the initial definition of requirements, the validation process begins. All the requirements should

be approved by all the users. At this stage, conflicts and dependencies between requirements must

be detected. Furthermore, any objection must be pointed out:  Dependency: Requirements that have some dependency on other requirements.

 Conflict: Requirements that cannot be implemented if another requirement is implemented or a conflict due to an insufficient definition of the requirement.  Objection: A reason or argument offered in disagreement, opposition, refusal or disapproval of the requirement.

Figure 4 – Validation

1.5.4 Revision

All the dependencies, conflicts and objections encountered by the experts during the validation stage must be revised and solved. However, if the authors do not agree with the validator’s opinion, then they can make use of t

he “Reviser’s comments” option for pointing out their disagreement or clarifying the intention of the requirement. Note that only the authors of the requirements that have to be revised are able to add comments to the dependency, conflict or objection.

Figure 5 – Revision

The checkboxes in “Requirements revised” column and “Validator’s approvement” column help the users to check the status of the revision and together with the possibility of adding comments The checkboxes in “Requirements revised” column and “Validator’s approvement” column help the users to check the status of the revision and together with the possibility of adding comments

The revision process consists of four steps:  Firstly, the authors should identify which requirements have been objected to or are

involved in any conflict or dependency.  Secondly and after analyzing the validator’s opinion: o The author may agree with the validator and proceed to modify or delete the requirement.

o The author may disagree with the validator, therefore he/she should make appropriate comments trying to clarify the requirement with a better explanation or justify the intention of the requirement.

 Thirdly, the author should mark the checkbox of the requirement as revised.  Finally, the validator should be aware of the revised requirements and approve the actions

taken by the author for resolving the dependency/conflict/objection.

1.6 Structure

For the purpose of structuring the requirement document, we follow an adapted version of the IEEE recommendations on requirements specifications [IEEE98] for this type of project. Since this requirement document is a public document, adhering to such a standard seems a reasonable approach. As a consequence, the specification does not only list the requirements on the functionality realized by the individual work packages but it also lists a set of general requirements to create a more complete picture. The general requirements will be realized by the integration of the work of the individual work packages as foreseen by the project.

The structure of the remaining parts of the document is as follows. Section 2 describes the general requirements. To put these requirements into context, the section outlines the related work and discusses the gap that is filled by and the innovations that are brought by the project. Sections 3 to 6 describe the requirements on the individual research and development activities. Similarly to the general section, they also describe the state of the art and the existing research gaps. Section 3 starts off with the requirements on adaptive data acquisition whose components are responsible for recognizing contextual information and user intents. Section 4 continues with a description of the requirements on the automated privacy preservation functionality that will be provided to protect the user’s privacy. Section 5 describes the data representation and query processing requirements that will ensure interoperability and scalability and Section 6 details the requirements on the intent- aware user interface that will enable users to interact with the artifacts of the project. After the description of the requirements, the requirement specification closes with a short summary in Section 7.

For the sake of brevity, the individual sections will only list a short form of the requirements that consists of the description, the type, the id as well as the priority. The complete version of the requirements can be found in the annex of the document.

2 General Requirements

The main objective of GAMBAS is to develop an innovative and adaptive data acquisition and processing middleware to enable the privacy-preserving and automated use of behavior-driven services that are able to adapt autonomously to the context of their users. While there are more and more applications that can be considered to be context aware or even context adaptive, these applications are usually focused on a narrow field of application. As a simple example one might consider a location-aware notification service that notifies a user about messages with local relevance. In contrast to this, the middleware developed in GAMBAS is focusing on enabling the development of a more innovative set of services that not only adapt to the current context but also to the behavior by enabling the recognition and use of intents by a service. As an example for this consider that when the system can provide a close estimate of the future location of the user, it can provide the user not only content that has a local relevance but also messages that are relevant in the close future.

In order to achieve this ambitious goal, the description of work lists four main technological research and development areas, namely, adaptive data acquisition, automated privacy preservation, interoperable data representation and query processing as well as intent-aware user interfaces. Besides these research and development areas, the realization of a comprehensive system as targeted by GAMBAS will require additional support to enable a spontaneous service-oriented communication between different devices. To optimally leverage the project’s limited resources, the work in this area will be covered by an existing middleware that has been implemented by some of the project partners in a previous FP7 project, namely, the PECES (Pervasive Computing in Embedded Systems) project. Due to this, the following requirements analysis will omit the requirements on service-oriented communication as these will be met by the available software.

As a result of the comprehensive middleware approach taken by the GAMBAS project, not all requirements can be directly assigned to one of the four main technological research and development areas listed in the description of work. Instead, some requirements can only be realized by the appropriate combination of all parts of GAMBAS. We categorize them under the term general requirements, and separate them for the requirements in the individual research and work packages. The following section focuses on describing these general requirements. From a high level perspective, the general requirements consist of requirements that are either targeted towards all parts of the middleware or they are jointly realized by the integration of all parts as targeted by the project. In addition, they explicitly state requirements that are assumed to be fulfilled by legacy systems that will be integrated as part of the development of the prototype application. To put these requirements into the appropriate frame, in the following, we first outline the current state of the art before we describe the resulting gaps and innovations. Finally, we list the requirements as well as their priorities. In the subsequent sections, we will then detail the requirements on the individual technological research and development areas.

2.1 State of the Art

Although it has not been realized so far, overall, the vision of ubiquitous computing as defined by Mark Weiser [WEIS91] is not new. Ever since its formulation in 1991, researchers and practitioners have focused on closing different research gaps. With respect to middleware issues, a significant amount of research has been performed in the area of enabling seamless device interaction as well as application adaptation. Furthermore, there have been considerable efforts in the area of enabling Although it has not been realized so far, overall, the vision of ubiquitous computing as defined by Mark Weiser [WEIS91] is not new. Ever since its formulation in 1991, researchers and practitioners have focused on closing different research gaps. With respect to middleware issues, a significant amount of research has been performed in the area of enabling seamless device interaction as well as application adaptation. Furthermore, there have been considerable efforts in the area of enabling

2.1.1 Hardware Technologies

As for any other software project, the execution environment for the GAMBAS middleware is defined by a subset of the existing hardware platforms. Due to the specific focus of GAMBAS on enabling adaptive data acquisition with Internet connected devices, in the following, we briefly discuss the available hardware technologies with respect to devices, communication and sensing. The focus thereby is not to provide a comprehensive list of available technologies, as this list would be hard to keep up to date over the course of a 3-year research project. Instead, we take a more high-level perspective that uses current technology as examples but, in principle, is independent from the concrete implementation. Based on the resulting discussion of device, communication and sensing technology, we then introduce a classification of device types that are relevant for GAMBAS. Thereby, it is noteworthy to mention that not all features of the GAMBAS middleware will be necessarily realized for all types of devices. However, GAMBAS will enable their integration.

2.1.1.1 Devices

Based on our present day perspective, we can assume that the devices forming the Internet of Things will be heterogeneous. For example, besides traditional personal computer systems, a significant number of devices will be either mobile or integrated. When analyzing the different types of devices, we can categorize them with respect to several orthogonal axes.

 Specialization: Naturally, we can classify devices on the degree of specialization. This degree may range from general purpose devices such as PCs or laptops to special purpose devices such as micro-controllers that are integrated into all kinds of objects. Although, in principle,

the concepts developed by GAMBAS should be applicable to all kinds of objects, GAMBAS will not focus on the latter. The reason for this is that highly specialized devices are often closed systems that cannot be programmed easily. Intuitively, we can expect that many closed devices will open up in the future.

 Resources: Independent from the degree of specialization, we can classify devices on the available resources. On the one end of the spectrum, the set of devices forming the Internet of Things may encompass resource-rich devices such as mainframes or clusters of

workstations. On the other end, they may contain resource-poor devices such as simple sensor nodes. In between there are devices such as laptops or devices with less resources such as mobile phones or tablets.

 Mobility: Another important axis is the degree of mobility. Here, we can distinguish stationary devices and mobile devices. In contrast to stationary devices, mobile devices are usually equipped with batteries and thus, their energy is a limited resource that needs to be

managed appropriately. This is especially true, when using mobile devices for long-running tasks such as the continuous monitoring of the environment.

 Interaction: Last but not least, the devices can also be classified based on their capability of supporting immediate interaction with a user. Here, we can distinguish devices that support user inputs, e.g. by means of graphical interfaces, and devices that are invisibly integrated

other objects. This axis is particularly relevant since only devices that support the interaction other objects. This axis is particularly relevant since only devices that support the interaction

2.1.1.2 Communication

Existing communication technologies can be broadly classified into wired and wireless. Due to the success of mobile devices, the latter ones have become main stream over the last couple of years. At the present time, there are several technologies that are widely available and frequently integrated into mobile devices. They cover the complete spectrum from low to high speeds and low to high range. At the same time, they exhibit vastly different energy profiles.

 Near field communication is a set of standards to enable radio communication between devices by bringing them in close proximity. NFC is based on existing standards on radio frequency identification (RFID). In contrast to other technologies in that family, it enables bi-

directional communication between two devices. However, it offers only low transmission speeds and it is only applicable to very close range communication (i.e. few centimeters). At the present time, it is mostly used for mobile payment systems or in order to bootstrap connections with other communication technologies.

 ZigBee is a relatively new standard for short ranges communication. ZigBee is specifically designed for low power devices with low data rate and short range communication capabilities. The IEEE standard 802.15.4 defines the physical and the MAC layer for ZigBee. The devices in a ZigBee setup can be categorized into ZigBee coordinators, ZigBee routers

and ZigBee devices. The ZigBee coordinator is the central entity that keeps record of the devices in the network as well of the other ZigBee coordinators. The ZigBee router is responsible for routing messages and associating devices with each other. Devices that are not ZigBee coordinators or ZigBee routers are classified as ZigBee devices.

 Bluetooth is another popular short range communication standard. Bluetooth modules are commonly available for standard computers and various peripherals. These modules support low bandwidth and short range communication. Depending on the communication range and energy consumption, Bluetooth devices are divided into three classes. Class 1 Bluetooth

devices consume around 100 mW and support approximately 100m. Class 2 Bluetooth devices consumes up to 2.5 mW and support communication range of approximately 10 meters. Class 3 consumes the minimal power (1 mW) but also provide the shortest communication range (approximately 1 meter).

 Wi-Fi is probably the most popular communication standard for connecting various devices such as laptops or mobile phones wirelessly. Wi-Fi certification is given to the devices with wireless capabilities that implement 802.11 standards. There exist several 802.11 standards

that include 802.11a, 802.11b, 802.11g, and 802.11n. Wi-Fi supported routers cover approximately 100 meters in outdoors. Since the clients in the Wi-Fi network do not require wire, the network can be easily extended. Wi-Fi enabled devices can easily move in a limited area but they have relatively short range. A possible shortcoming of Wi-Fi certified devices is that they have comparatively higher energy requirements.

 UMTS (Universal Mobile Telecommunications System) is the successor to GSM and designed to support third generation telephone technology. UMTS is specifically designed to support advanced services. It is developed to support 14 Mbps data transfer rate and UMTS support

is now commonly available in most smart phones. Compared to its predecessor (GSM), it is now commonly available in most smart phones. Compared to its predecessor (GSM), it

For stationary devices, wired communication technologies are still an important alternative to wireless technology. Many stationary general purpose devices such as servers are usually connected with Ethernet.

 Ethernet is based on IEEE 802.3 specification and is a very popular LAN technology. The specification defines standard for physical layer as well as data link layer of the OSI model.

Starting with 10Mbps, it has evolved to support 100Mbps (fast Ethernet) and later 1000Mbps (Gigabit Ethernet) speed. Currently the fastest speed standard supported by Ethernet is 10 Gbps although we can assume that there will be further progress on connection speeds.

2.1.1.3 Sensing

Besides device and communication technologies, the third hardware pillar of GAMBAS is sensing technology. Over the last couple of years, device manufacturer have started to integrate various sensors into different types of devices. At the present time, current mobile devices such as smart phones and tablets exhibit the following combination of sensors:

 Accelerometer: Accelerometers are used to measure the acceleration that a device experiences. In most cases they are able to differentiate acceleration along three axes.

Usually, they are used to adapt the screen orientation of the device according to the way the user is holding it. However, researchers have also used accelerometers for various other tasks such as classifying the mode of locomotion or detecting potholes.

 Gyroscope: More recently, device manufacturers started to add gyroscopes to the set of standard sensors that are available on mobile phones. Gyroscopes are used to measure the

orientation of a device. Advanced applications include inertial navigation systems, for example. However, at the present time, they are mostly used to support gaming.

 Microphone: As a natural consequence of their function, all mobile phones are equipped with microphones that allow them to record and transmit voice during a call. However, in addition to that, most devices nowadays exhibit multiple microphones (e.g. to enable

automatic noise reduction) that can also be used to capture and analyze ambient sound.  Proximity: In order to activate and deactivate the screen automatically during a call, many mobile phones are equipped with proximity sensors that can measure the distance between

the phone and another object (typically in front of the screen) in a course-grained scale (e.g. far or close).

 GPS: To support location-based services and to support user navigation, many mobile devices are equipped with GPS receivers. Although they cannot be used reliably in indoor

environments, outdoors they provide reliable localization with 5 to 10 meter accuracy.  Camera: Similar to microphones, nowadays, most mobile phones and tablets are equipped with cameras which can be used to record videos as well as still images. Besides from simply taking pictures or recording videos, they can also be used to recognize visual tags (e.g. QR-

Tags) and they can be used for different types of context recognition applications (e.g. to automatically detect gas station prices).

 RF: Although they are mostly intended for communication, RF-based communication technologies such as Wi-Fi or GSM can also be used to extend the capabilities of other sensors such as GPS, for example. The use of these technologies as sensors usually requires  RF: Although they are mostly intended for communication, RF-based communication technologies such as Wi-Fi or GSM can also be used to extend the capabilities of other sensors such as GPS, for example. The use of these technologies as sensors usually requires

Besides mobile devices, researchers have also developed a number of sensing platforms such as Berkeley Mica2 or UCLA iBadge, etc. – mostly in the area of wireless sensor networks. Typically, these platforms can be extended with different types of sensors but most of them contain at least the following combination of sensors.

 Light: Light sensors typically measure the light level received at a particular point of the device. In many cases light sensors are directly built into the sensor node or they can be added by attaching a sensor board.

 Temperature: Temperature sensors typically measure the ambient temperature of the sensor node. In many cases the sensors are not calibrated and the raw values need to be

converted programmatically to the usual Celsius or Fahrenheit scale.  Pressure: Pressure sensors typically measure the barometric pressure and thus, they can be used to compute the altitude.  Humidity: Humidity sensors typically measure the humidity using capacitive measurements. In many cases they are bundled with temperature sensors.

In addition to mobile devices and sensor nodes, there are numerous application specific sensors. Due to their great variety, it is not possible to provide a comprehensive list here. To name some examples that may be relevant in the context of GAMBAS, using the OBD unit of a modern car, it is possible to capture various engine related values. These include, for example, the current fuel consumption or the current state of the catalytic converter.

2.1.1.4 Classes

Based on the previous discussion of device, communication and sensing technologies, we can identify four broad classes of devices that are forming the hardware platform for services developed with the GAMBAS middleware. Intuitively, based on the capabilities of the device the support provided by the middleware will differ.

 Back-end computer system (BCS): Back-end systems usually consist of one (or more) general purpose computer that is connected to the Internet via a wired and often high-speed

connection. Usually, they exhibit high storage and processing capacities and they are shared by multiple users remotely – i.e. through the Internet. Consequently, to most of their users, they do not expose a physical interface that would enable interaction. Instead, they are accessed through web-browsers or via custom applications that are performing some form of remote call (e.g. RPC, RMI, etc.). In GAMBAS such systems will be used to perform data storage, aggregation and processing.

 Traditional computer system (TCS): Traditional computer systems encompass workstations, desktops and laptops. If they are stationary, they are typically connected via wired

connections. If they are mobile, like laptops, the predominant communication technology is Wi-Fi. In some cases, they are equipped with a few sensors (e.g. microphones, cameras, accelerometers for hard disk protection). Usually, they are accessed and used by a single user (e.g. personal desktop/laptop) or a small group (e.g. shared workstation). Although, they have fewer resources than most back-end computer systems, when considering that they are not shared between many users, the ratio of resources to number of users may be equally connections. If they are mobile, like laptops, the predominant communication technology is Wi-Fi. In some cases, they are equipped with a few sensors (e.g. microphones, cameras, accelerometers for hard disk protection). Usually, they are accessed and used by a single user (e.g. personal desktop/laptop) or a small group (e.g. shared workstation). Although, they have fewer resources than most back-end computer systems, when considering that they are not shared between many users, the ratio of resources to number of users may be equally

 Constrained computer system (CCS): Constrained computer systems include mobile devices such as smart phones and tablets. Furthermore, they include stationary devices such as set top boxes or industrial PCs. When compared with traditional computer systems, they exhibit

a significantly lower amount of computing resources with less capable processor architectures (e.g. ARM instead of X64) and less amount of memory (e.g. MB instead of GB). In many cases, they are equipped with a multitude of build-in sensors (e.g. mobile phone) or they can be attached to application specific sensors (e.g. industrial PC). Consequently, they provide the primary basis for data acquisition in GAMBAS and they will also be an important data storage that can be accessed remotely.

 Embedded computer system (ECS): Embedded computer systems include highly specialized micro-controllers or ASICs that are built into existing products such as a dishwasher or a car.

Furthermore, they include less specialized sensor platforms that may be programmable such as a SunSPOT or a Mica2 node. Usually, these systems are not directly connected to the Internet. Instead, they can be connected through some gateway device that mediates the interaction. Although, such embedded devices outnumber the other classes at the moment, the GAMBAS project does not focus on the use of these devices as a primary processing platform. The reason for this is that usually, these devices cannot provide their function without additional computing infrastructure. Furthermore, in many cases they are not equipped with easily accessible interfaces or they do not provide sufficient computing resources to implement additional services. However, due to their ubiquity, the GAMBAS middleware will enable their use as data sources when combined with a more capable device such as a constrained computer system or a traditional computer system.

2.1.2 Communication Middleware

Regarding device interaction, researchers and practitioners have developed a number of communication middleware systems to enable the seamless and trustworthy cooperation of a heterogeneous set of possibly resource-poor connected objects. Examples for past and present research projects in this area are the 3PC [3PC11], GAIA [ROMA02] and AURA [GARL02] projects or the PECES FP7 [PECE11] project, to name a few. Traditionally, the resulting systems either focused on enabling the interaction of devices at a specific geographic location (i.e. the so-called smart spaces) or they focused on enabling the interaction of devices that are in close proximity (i.e. the so-called smart peer groups). More recently, systems such as the PECES middleware integrate and extend these two concepts by enabling the interaction within a smart space that is formed by devices in close proximity and beyond smart spaces by enabling device interaction across the internet in a peer- to-peer fashion. Since the resulting concepts provide a higher degree of flexibility, the GAMBAS middleware will use PECES as its underlying communication middleware.