BETaaS - D1.4.2-TaaS Reference Model v1 - D1.4.2 - TaaS Reference... · such a model stemming from a careful analysis of the current state of ... we propose a higher level of abstraction

BETaaS

Building the Environment for the Things as a Service

Grant Agreement no.: 317674 Call identifier: FP7-ICT-2011-8

D1.4.2 - TaaS Reference Model

Deliverable: D1.4.2

Title: TaaS Reference Model

Due date: 30 September 2013

Actual submission date: 10 October 2013

Lead contractor for this deliverable: University of Pisa

Dissemination Level: PU

Version: 1

Abstract

This deliverable describes the final specification of the reference model for the ‘Things as a Service’ (TaaS), on top of which the BETaaS platform is based.

BETaaS D1.4.2 TaaS Reference Model

Version 1 Page: 2 of 49

Document History

Version Issue Date Total pages

Modified pages Modifications implemented Author Organization

0.1 27/08/2013 36 - Proposed ToC for version 2.0 Carlo Vallati, Enzo Mingozzi UPI

0.2 17/09/2013 - - Added information handling Carlo Vallati, Enzo Mingozzi UPI

0.3 20/09/2013 - - Changes in Sections 4, 5.1.2 and 5.2.3.

Belen Martinez TECN

0.4 20/09/2013 - - Changes in Section 5.2.3. Added Section 6.2.1 Luca Cucchi INCS

0.5 25/09/2013 - - Added Section 5.2.4 Carlo Vallati, Giacomo Tanganelli UPI

0.6 25/09/2013 - - Updated Sections 5.2.3 and 4.5 Davide Sommacampagna HP

0.7 30/09/2013 - - Added Section 6.3.1, updated Section 5.2

Giacomo Tanganelli, Carlo Vallati, Enzo Mingozzi

UPI

0.8 30/09/2013 - - Updated Sections 5.1.4 and 5.2.3 Francisco Javier Nieto De-Santos ATOS

0.9 06/10/2013 - - Updated Sections 5.2.2 and 6.5 Nikolaos Zonidis, George Labropoulos CONV

1.0 07/10/2013 49 - Final harmonization Enzo Mingozzi UPI



Executive Summary

The BETaaS platform builds upon a baseline architectural reference model, which we call Things as a Service (TaaS), providing an abstract and clear description of the underlying ‘physical’ layer, which consists of smart things connected to a global network infrastructure and providing basic services either directly or through intermediate gateways.

Task 1.4 (Reference model for the Things as a Service) has started on M4 with the goal of specifying such a model stemming from a careful analysis of the current state of art of existing models for IoT developed by EU projects (e.g., IoT-A) and ongoing standardization activities (e.g., ETSI M2M), as well as other solutions available in the market. Since creation and maintaining of a physical layer of smart things is outside the scope of BETaaS, the definition of a TaaS model is key to the design and development of the platform carried out in WPs 3 and 4.

Based on the input from D1.1 (State of the Art Review) [8] and D1.2.1 (User and System Requirements) [1], and also from the work started in parallel within WP2 – in particular Task 2.1 (Definition of the basic platform capabilities) and 2.2 (Analysis of content definition and use for M2M) – a high-level level reference architecture for TaaS was specified in D1.4.1 (TaaS Reference Model) [2], as a result of task T1.4 efforts in M4-M6. This specification has provided input to the WPs related to the M2M services, platform definition and platform implementation.

The reference architecture has been refined and extended during M7-M12 within task T1.4, also based on the feedback obtained from the technical activities in the other WPs. The considered set of user and system requirements of the BETaaS platform has been updated as established in D1.2.2 [3] (Section 4). The Reference model (Section 5.1) has been revised and updated based on the feedback from work package WP3. Moreover, a mapping of the reference architecture to the user and system requirements has been provided (Section 5.2.4), as well as an illustration of the basic relationship and interactions between the different functional blocks of the architecture (Section 5.3). Finally, details are provided (Section 6) about how a subset of existing model/architectures relevant to BETaaS could be exploited by BETaaS through respective adaptation layers, including major gaps that need to be filled in the latters, as well as guidelines for their implementation.

The result is the final high-level level reference architecture for TaaS described in this document.



Table of Contents

Executive Summary ...................................................................................................................... 3

1. Introduction ........................................................................................................................... 6

2. Table of acronyms................................................................................................................. 8

3. Existing IoT/M2M models and systems ............................................................................... 9

3.1. IoT-A ................................................................................................................................................. 9

3.1.1. Domain model .......................................................................................................................... 9

3.1.2. Information model .................................................................................................................. 10

3.1.3. Communication model ........................................................................................................... 11

3.1.4. Security model ....................................................................................................................... 12

3.2. ETSI M2M ...................................................................................................................................... 12

3.2.1. Domain Model ........................................................................................................................ 12

3.2.2. Information Model .................................................................................................................. 13

3.2.3. Communication Model ........................................................................................................... 14

3.2.4. Security Model ....................................................................................................................... 14

3.3. IETF Constrained RESTful Environments (CoRE) ........................................................................ 15

3.3.1. Domain Model ........................................................................................................................ 15



3.3.4. Security Model ....................................................................................................................... 17

3.4. ITU – FG M2M ................................................................................................................................ 17

3.5. Ecosystem ...................................................................................................................................... 17

3.5.1. Domain Model ........................................................................................................................ 18



3.5.4. Security .................................................................................................................................. 19

4. Requirements ...................................................................................................................... 20

5. TaaS reference model and architecture ............................................................................. 22

5.1. Reference Model ............................................................................................................................ 22

5.1.1. Domain Model ........................................................................................................................ 22



5.1.4. Security Model ....................................................................................................................... 24

5.1.5. Functional Model ................................................................................................................... 24

5.1.6. Relation of Communication model to Functional model ........................................................ 26

5.2. Reference Architecture (functional view) ....................................................................................... 27

5.2.1. Physical ................................................................................................................................. 27

5.2.2. Adaptation .............................................................................................................................. 28

5.2.3. TaaS ...................................................................................................................................... 28

5.2.4. Platform requirements – functional blocks mapping .............................................................. 29

5.3. Information handling by functional components ............................................................................. 32

5.3.1. Service Negotiation ............................................................................................................... 32

5.3.2. Data Retrieval ........................................................................................................................ 34

5.3.3. Thing Connection/Disconnection ........................................................................................... 35

6. Mapping to existing models/architectures ........................................................................ 38

6.1. IoT-A ............................................................................................................................................... 38

6.2. ETSI M2M ...................................................................................................................................... 38



6.2.1. Adaptation Layer.................................................................................................................... 40

6.3. IETF Constrained RESTful Environments (CoRE) ........................................................................ 43

6.3.1. Adaptation Layer.................................................................................................................... 43

6.4. ITU – FG M2M ................................................................................................................................ 45

6.5. Ecosystem ...................................................................................................................................... 46

7. Conclusions......................................................................................................................... 48

8. References ........................................................................................................................... 49



1. Introduction

The BETaaS platform aims at providing a runtime environment relying on a local cloud of gateways to support the deployment and execution of content-centric M2M applications. The proposed platform will seamlessly integrate existing heterogeneous M2M systems. The latter constitute the so-called underlying ‘physical’ layer, consisting of smart things connected to a global network infrastructure and providing basic services either directly or through intermediate gateways.

Research and development efforts are needed to create and maintain a physical layer of smart things. However, these are considered outside the scope of BETaaS. In order to account for heterogeneity, the BETaaS platform builds instead upon a baseline reference model and architecture, which we call Things-as-a-Service (TaaS), providing an abstract and uniform description of the underlying physical layer [3]. Figure 1 shows a use case instance from [3] where the role of the TaaS in the BETaaS platform is highlighted.

Figure 1. Use case instance of the BETaaS platform.

While there are no conclusive solutions to IoT modeling, several attempts have been done so far, and are currently ongoing, to produce IoT reference models and architectures. A survey of such efforts has been performed by the IoT-I project and can be found in [3]. In fact, it is not an objective of BETaaS to produce an additional reference model, which would have to compete in an already crowded arena. Rather, we propose a higher level of abstraction based on the abstraction of Things-as-a-Service and also including a few novel concepts, such as resource-awareness, which is crucial to the dynamic deployment and execution of the services within a BETaaS instance.

The goal of this document is to specify a reference model for the Things-as-a-Service stemming from a careful analysis of the current state of art of existing models for IoT developed by EU projects (e.g., IoT-A) and ongoing standardization activities (e.g., ETSI M2M). The analysis aims at identifying and combining the best available models which fit the requirements of the BETaaS platform, and to possibly extend such models with additional features needed to support the BETaaS platform’s basic and extended capabilities.



The rest of the document is organized as follows. In Section 2 a Table fo Acronyms is reported. In Section 3 an overview of existing reference models and architectures for IoT is provided. Section 4 summarizes the requirements for the TaaS reference model. Section 5 provides the specification of the proposed TaaS reference model and architecture, while Section 6 includes the analysis of the models considered in Section 2 with respect to the one proposed for TaaS. Finally, Section 7 draws the conclusions. References are reported in Section 8.



2. Table of acronyms

Acronym Expanded form

3GPP The 3rd Generation Partnership Project 3GPP2 The 3rd Generation Partnership Project 2

API Application Programming Interface A-SL ITU Network application interface BD Big Data

BETaaS Build the Environment for the Things as a Service

CoAP Constrained Application Protocol CON CoAP Confirmable Message CoRE Constrained RESTful Environments

D/G/NCS ETSI Device/Gateway/Network Communication Selection D/G/NTM ETSI Device/Gateway/Network Transaction Management

DA ETSI Device Application dIa ETSI Device application interface

DSCL Device Service Capability Layer D-SL ITU Device application interface DTLS Datagram Transport Layer Security ETSI European Telecommunications Standards Institute

G/NAE ETSI Gateway/Network Application Enablement GA ETSI Gateway Application

GSCL ETSI Gateway Service Capability Layer G-SL ITU Gateway application interface GW Gateway

HTTP Hypertext Transfer Protocol IETF Internet Engineering Task Force IoT Internet of Things

IoT-A Internet of Things – Architecture

IoT-GSI Internet of Things Global Standards Initiative IoT-i The Internet of Things Initiative

ISO/OSI International Organization for Standardization - Open Systems Interconnection

ITU International Telecommunication Union ITU-T ITU Telecommunication Standardization Sector

JCA-IoT Joint Coordination Activity on Internet of Things M2M Machine to Machine mIa ETSI M2M application interface mId ETSI M2M to device interface NA ETSI Network Application

NGC ETSI Network Generic Communication NON CoAP Non-Confirmable Message

NREM ETSI Network Remote Entity Management NSCL ETSI Network Service Capability Layer QoS Quality of Service SCL ETSI Service Capability Layer SLA Service Level Agreement

SL-SL ITU Service layer to sevice layer interface TaaS Things as a Service

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking

TLS Transport Layer Security VE IoT-A Virtual Entity

VE-ID IoT-A Virtual Entity Identification xGC ETSI Generic Communication

xSEC ETSI SECure



3. Existing IoT/M2M models and systems

In this section an overview of existing reference models and architectures for IoT is provided. The architectural reference model for the interoperability of IoT systems defined by the IoT-A EU project is considered first. Though there are other EU projects that have faced the same problem and provided alternative solutions, IoT-A is considered as the most representative one, because it is closely related to BETaaS and because it is an FP7 flagship project. The role of standardization for interoperability is very much relevant. Therefore, reference models from three different standardization bodies are then considered, i.e., ETSI M2M, IETF CoRE, and ITU FG-M2M, respectively. Finally, a proprietary M2M system from one of the BETaaS partners is included, to lay the foundations for demonstrating the ability of the TaaS reference architecture to seamlessly integrate non-standard proprietary systems.

3.1. IoT-A

The IoT-A project aims at developing a unified reference model for the Internet of Things. The reference model consists of different models, each one regarding a particular aspect. The major models are the following: Domain model, Information model, Security model and Communication model. The models jointly provide a high level description of the architecture. In the following sections a brief overview of the models as defined by IoT-A is provided, the complete description can be found in [4].

3.1.1. Domain model

The domain model defines the entities that compose the IoT system with the relations among them. Figure 2 shows the domain model defined by IoT-A.

Figure 2: IoT-A Domain Model



• Physical Entity: is an object of the real world.

• Virtual Entity: is a representation of a Physical Entity in the digital world. Ideally a Virtual Entity is a synchronized representation of the Physical Entity which is associated to.

• Augmented Entity: is the combination of a Physical Entity and the corresponding Virtual Entity.

• User: is the main actor of the domain model. It can be a human, an application or a service. The User is interested in interacting with the Physical Entity.

• Device: is an artifact (hardware) used for bridging a Physical Entity to a Virtual Entity, e.g., a sensor, a tag, an actuator or a combination thereof.

• Resource: is a software component, with native interface, that provides information about or enable the actuation on a Physical Entity. Resources can be on-device resources or network resources depending on where they are deployed.

• Service: exposes the functionalities of a device to the User. A service provides a well-defined and standardized interface to interact with a Physical Entity. A Virtual Entity is associated to one or more services that are related to the resources hosted on a device.

Summarizing, a user interacts with a Physical Entity through a Virtual Entity. First the user discovers a Virtual Entity and the associated service(s), then the service is invoked. In turn, the service uses a resource to access the device connected to the Physical Entity.

3.1.2. Information model

The information model defines the structure of all the information and in general describes how to communicate with virtual entities.

Figure 3: IoT-A Information Model

Figure 3 illustrates the IoT-A information model. The main aspects are the following: Virtual Entity, Service Description and Association. A Virtual Entity is a model for a Physical Entity, a Service Description is a bridge between the digital world and the real world, the Association is a connection between an Attribute of a Virtual Entity and a Service Description. A Virtual Entity has an unique identifier and a type (Entity Type), examples are a human, a car or a sensor. Each Virtual Entity has a number of different attributes (Attribute) which can vary from 0 to n, each attribute has a name (Attribute



Name) and a type (Attribute Type). Each attribute has from 1 to n links with values (Value Container) in order to allow attributes with multiple values. Each Value Container groups one Value and from 0 to n metadata (Meta Data) belonging to the Value.

A Service Description provides a description of the Service features and interfaces. A Service interacts with a Physical Entity through a Resource, thus a Service description may contain Resource Descriptions, which may include information on the Device where the Resource is hosted.

An Association provides information on a Service by associating a Service to the attributes of a Virtual Entity, e.g. location and context.

3.1.3. Communication model

The communication model defines a communication stack, similar to the ISO/OSI 7-layer network stack, taking into account the requirements and characteristics of an IoT system. The Communication Model is used for connecting the entities defined in the domain model.

Figure 4: IoT-A Communication Model

Figure 4 illustrates the stack defined in the model. The layers have been developed for taking care of interoperability in heterogeneous networks. The following are the functionalities of each layer:

• Physical layer: has the same functionalities described in the OSI stack.

• Link layer: handles diversity of heterogeneous networks and customized communication schemes. This layer is responsible for providing a unified interface to the upper layers. Some functionalities are the following: unicast and broadcast communication, collision detection and/or collision avoidance, network access control.

• Network layer: has the same functionalities described in the OSI stack.

• ID layer: provides a Virtual-Entity IDentifier (VE-ID) which is independent from the locator and allows a common addressing schema. This layer can be used to form an overlay network.

• End-to-End layer: is responsible for managing connections, ensuring reliable communication and providing translation functionalities, e.g., proxies/gateways support.

• Data layer: is responsible for monitoring data produced with the structure defined in the Information Model. Since the Information Model is VE centric, the Data layer must verify that raw data, pushed from applications, can be mapped to a specified Virtual Entity.

It is worth to underline that the communication model provides a communication scheme that can be applied to different types of IoT networks, i.e. both constrained network to full capable network and constrained network to constrained network, Figure 5.

Figure 5: Constrained Network to Constrained Networ k



3.1.4. Security model

The security model consists of three main concepts: Trust, Privacy and Security. Those functional blocks are horizontal and also tightly related among themselves. Trust in an IoT environment can be split into two layers: networking and application. Networking trust is related to the integrity of the routing process while application trust is more related to information quality, such as endpoint authentication and non-repudiation; confidentiality; privacy policy. Privacy is associated with the capability of a person to protect their information, moreover by a legal perspective laws can put restrictions and obligations on the way information concerning users is stored and used. Security is a general concept that incorporates also Trust and Privacy [5].

To accomplish those concepts the information model should include descriptions of access policies, certificates and trusted identities. Moreover the functional architecture should include components responsible for the management of trust, security and privacy.

The security model is split in two layers: Service Security and Communication Security (see Figure 6).

Figure 6: Security model

As far as communication security is concerned, which is more relevant to TaaS, the model distinguishes between constrained and unconstrained networks from the communication model. In fact, the heterogenity of devices represents a problem in designing a security model. To overcome this issue the security model has a high level of abstraction. Gateways, being at the edge between networks of the different network types, are identified as central components for mediating between different security components of different networks. This includes tunnelling, filtering, and, most importantly, scaling down security (and other) functionalities from unconstrained networks in order to meet the limitations imposed by the constrained networks.

3.2. ETSI M2M

ETSI has created a dedicated Technical Committee with the mission to develop standards for Machine to Machine Communications [6] [7]. The high-level architecture and functional architecture of ETSI M2M have been discussed in [8]. In this section, a description of the ETSI M2M model is provided.

3.2.1. Domain Model

Actors involved in an ETSI M2M network are:

• M2M Application : In ETSI M2M everything above the Service Capabilities Layer is considered an application. An application can be a Device Application (DA), a Gateway Application (GA) or a Network Application (NA) depending if it is running on a device, a gateway or on a network domain host.



• M2M Service Capabilities Layer : In ETSI M2M functional architecture is defined a Service Ca-pability Layer (SCL) which is used as a middleware between applications in the Internet and de-vices or gateways residing in local area networks. It provides M2M functions that are shared by different Applications through open interfaces and uses Core Network functionalities. The SCLs can be DSCLs, GSCLs or NSCLs depending on the provider: Device, Gateway or Network re-spectively.

• Resource : A resource in ETSI M2M consists of the RESTful interface exposed by the Service Capability Layer.

• Gateway : Provides SCLs to GA and D’ device applications enabling them to communicate with the Network SCLs.

• Device : Devices in ETSI M2M can be of three types:

o Fully capable Devices (D) with their own SCLs, such devices are directly connected to the core network via an access network.

o Devices(D’) with no own SCLs, they use the gateway SCLs to access the core network.

o ETSI M2M also supports non-ETSI M2M compliant device (d) that can be connected to the SCLs of a D device or of a gateway or can be directly connected to the Network SCLs.

3.2.2. Information Model

In ETSI M2M information model is based on Resources. A resource is a uniquely addressable entity in the RESTful architecture and has a representation that shall be transferred and manipulated with REST verbs. A resource is addressed using a Universal Resource Identifier (URI) and can hold application specific data. In ETSI M2M resources are like buckets that reside in the local SCLs but could be announced to multiple remote SCLs. Resources can contain sub-resources which lifetime is linked to the parent’s resource lifetime, they also have attributes that contain meta-data providing properties associated to a resource representation. Attributes can be of different types, depending if they are read-only, readable and writable or write-once.

M2M Applications monitoring subscribed resources are notified when the resource is created or updated. Only M2M Applications or SCLs can issue a request for an action on a resource and only M2M Applications or SCLs are able to receive that request.

ETSI M2M defines the types of resource to be used in a SCL and a hierarchical structure is provided to relate different resources (e.g. child-parent linking). Resource types defined by the standard are:

• SclBase Resource

• SCL Resource

• Application Resource

• AccessRight Resource

• Container Resource

• LocationContainer Resource

• Group Resource

• Subscription Resource

• M2MPoC Resource

• MgmtObj Resource

• MgmtCmd Resource

• AttachedDevices Resource

• AttachedDevice Resource



• Announced Resource

• NotificationChannel Resource

• Discovery Resource

• Collection Resource

3.2.3. Communication Model

In ETSI M2M the Service Capabilities Layer is in charge to provide secure and reliable end-to-end communication among M2M networks while M2M Applications are responsible for data management and control. ISO/OSI Application level is used to a issue RESTful requests using HTTP or CoAP. Underlying layers are the same of the ISO/OSI stack. In M2M devices with no own SCL (D’ devices) the M2M Applications directly use the HTTP/CoAP layer to contact a gateway SCL.

Figure 7: ETSI M2M communication model

3.2.4. Security Model

In ETSI M2M the Service Capability Layer is responsible to take care of all security requirements of M2M communication. The standard defines a key hierarchy of three levels. The ETSI M2M Root Key is used for mutual authentication between D or G nodes and the M2M Service Provider. It is also used by the next layer of the key hierarchy, the ETSI M2M Connection Key, to derive and agree a key which is used for every service connection procedure. Finally, the ETSI M2M Application Key is used for securing sessions between specific applications.



Figure 8: ETSI M2M communication model

The Secured Environment Domain protecting M2M Root Key may be part of a secured environment integrated with the M2M Device/Gateway or it may be hosted on an Independent Security Element. Secured Environment Domains refer to logical entities that are securely isolated from each other, whether they are separate Secured Environments or are inside a single Secured Environment. The M2M Service Provider owning a M2M Node on a M2M Device/Gateway controls its own Secured Environment Domain while providers of M2M applications may control an independent Secured Environment Domain on an M2M Device/Gateway. Strong security recommends that all secured environment domains that need to exchange information in the M2M Device/Gateway are hosted on a single secured environment.

3.3. IETF Constrained RESTful Environments (CoRE)

The IETF Constrained RESTful Environments Working Group provides a framework for resource-oriented applications intended to run on constrained IP networks. As part of the framework the CoRE WG defines the Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP is an application protocol developed for devices with constrained resources operating inside constrained networks [9]. CoAP takes strong inspiration from HTTP, from which it inherits a subset of functions and most of its terminology. However, CoAP has a reduced overhead and is especially optimized for Machine-to-Machine (M2M) communications.

Moreover, the WG also defines the Constrained RESTful Environments (CoRE) Link Format [10]. The CoRE Link Format is an extension of the HTTP Web Linking [11] and defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Each resource is represented by a Web Link with the attributes needed by the client to identify the functionalities provided by the resource.

The IETF CoRE WG does not explicitly define a Reference Model, however the needed models can be derived from the description of the WG and from the WG's drafts. This is done in the following also based on the work in [12].

3.3.1. Domain Model

The CoRE WG defines entities involved in the general architecture:

• Device: is a generic node on the constrained network. A Device is an hardware component that hosts Resources.

• Resource: is an abstraction that may represent sensors, actuators, combinations of values or other information.

• Proxy: is a particular kind of Device usually without sensing capabilities. In fact, a Proxy is a network element with communication means. Nevertheless, a Proxy can implement a cache to host, temporarily, Resources of sleeping Devices.

• CoAP end-point: is hosted on a Device and provides a REST interface to interact with Re-sources hosted on the same Device.




The information model is focused on Resources. A Resource is a representation of the information about a sensor, an actuator or a combination of values. The Device that hosts a Resource implements the connection between the real world and the digital world. A Resource is exposed through a CoAP end-point, hosted on the Device, which can be seen as a service abstraction. Moreover, a Resource has a unique URI and can have some metadata associated to itself. Those metadata form the Resource description and are specified using the CoRE Link Format.

Figure 9: CoRE Information Model


The CoRE WG is primarily focused on constrained IP network. However, protocols like CoAP work over traditional IP networks as well. In fact, the CoRE WG also considers the ROLL and 6LOWPAN WGs, which define additional constraints that are specifically targeted to M2M scenarios. Physical, Data Link and Network layer have the same functionalities described in the ISO/OSI stack.

It is worth noting that M2M environments are usually characterized by constrained networks and constrained devices, for this reason the CoRE WG defines UDP as the default transport protocol. Resources are identified by URIs. At the top of the stack the CoAP end-point layer provides the point of access to Resources.

Figure 10: CoRE Communication Model

Physical

Data Link

Network

Transport

URI

CoAP end-point




The CoRE WG does not define a security model, however the WG investigates security in terms of session security. CoAP uses DTLS to provides security at application level, however the CoRE WG also considers the 6LOWPAN WG which aims at developing security on lower levels.

3.4. ITU – FG M2M

The ITU Focus Group on the M2M service layer (FG M2M) studies activities currently undertaken by various standards developing organizations in the field of M2M service layer specifications to identify key requirements for a common M2M service layer.

FG M2M identifies a minimum set of common requirements of vertical markets, focusing initially on the health-care market and application programming interfaces (APIs) and protocols supporting e-health applications and services, and draft technical reports in these areas.

FG M2M works in close collaboration with all ITU-T Study Groups, especially SG11, SG13 and SG16 (in particular with JCA-IoT and IoT-GSI) through collocated meetings, for instance on the coordination of respective work programmes and on the coordination of seminars and workshops.

From the ITU-T perspective [14], machine to machine (M2M) technology is a key enabler of Internet of Things (IoT). M2M service layer in ITU-T scope is set of common functions for the different applications to provide M2M services. It includes management functions and security functions as well as service support and application support functions as Figure 11. Required capability of M2M service layer is a subset of capabilities of IoT.

Figure 11 – M2M service layer [14]

M2M service layer needs to be separated with other layers to reduce implementation complexity while provide global interoperability between various M2M applications. For example, cross layer approaches can show more high performance but it increase implementation complexity.

3.5. Ecosystem

Ecosystem is Converge’s Environmental Management Product. A complete automation and monitoring solution, allowing extremely broad control over every aspect of a home or business environment. It is fault tolerant, friendly, safe, very scalable, and very flexible.

Ecosystem can be configured to integrate the functionality of electrically controlled devices: sensors, lights, motors, ventilation, and so forth. The platform is Java-based and is also accessible from the Web,



based on its AJAX (Restful services) module. Many commercial protocols are integrated in its current implementation such as KNX, Instabus, ECHELON, Z-Wave, enocean, PLCs and several other protocols for wiring and communication according to the solution selected for each project.

Considering Ecosystem's basic concepts and functionality, it can be used for demonstrating the TaaS reference model and can provide immediate examples of several versions of TaaS implementing GW.

Like a natural ecosystem, Ecosystem interacts with and adapts to its environment naturally and unobtrusively facilitating thus a holistic, interactive environment by bringing together all the controlled devices in one managed super-environment, through which they can co-operate in ways that they never could on their own.

3.5.1. Domain Model

Ecosystem can be defined in its own architecture model which encapsulates the basic features and building blocks of its implementation.

Figure 12. Ecosystem Domain Model

Ecosystem is described and consists of the following basic entities:

• Ports . These are the actual hardware units that represent the physical devices existing in the environment, which can be detected by the system as carriers of input signals or actua-tors/switches that can accept orders. They stand at the bottom of the layered architecture.

• Devices . Ports can be combined together to form a virtual device that has a particular meaning to the end user and a very specific functionality to execute.

• Services . Devices are then used by Services in order to execute particular scenarios that com-bine many devices cooperating within the same environment. Services are the top layer of Eco-system's architecture.

• Commands . These entities are instructions described and attached to a Device residing inside the Ecosystem. They can though be executed by other Services thus providing the path for more complex scenarios.

The following entities can also be described as Services because they are implemented as autonomous modules.

• Port Delegator Service . A dedicated service responsible for discovery and management of the ports as physical devices. Each type of port(s), depending on the protocol used (i.e. Echelon, Z-wave etc.) is managed by its own Delegator.



• Space Management . A Service responsible for the space architecture and the logical attach-ment of devices on a map of the room, flat, etc. that provides a reasonable interpretation of the configured Ecosystem actual environment.

• Communication Management. The Service required for providing the means for communi-cating and issuing of Alerts and/or messages via email or SMS routes.


Ecosystems information model is quite simplistic and is represented essentially by the automation layer of the diagram 10 from the Domain Model. Practically Commands are organized by any of the three entities that can manipulate them, such as the BPM Module, the Event Scheduler and the Pattern Matching Based Module. In essence each Device is accessed via the Commands that it implements and many commands are orchestrated together to fulfill particular scenarios.


Ecosystem is using the physical devices’ protocols in order to provide the means for communication between the virtual Devices and Services with the actual physical entries inside the environment. Different devices are using a wide spectrum of protocols ranging from Zwave to Bluetooth. These are on the very basic level of the Ecosystems Domain Model architecture and are therefore protected by the upper layers Services and the top Layer of Ajax UI which supports Restfull services communication even TCP/IP.

3.5.4. Security

Authentication and authorization is supported through the Service which provides the means for HTTP requests. On top of that Ecosystem’s Ajax interface (i.e. the aforementioned HTTP requests and responses) is provided strictly through web based SSH communication.



4. Requirements

The TaaS reference model and architecture are specified based on a set of requirements determined by the BETaaS platform. Based on the user and system requirements established in Deliverable D1.2.2 [3], and the basic capabilities at the core of the platform specified in D2.1.2 [13], the following set of requirements has been considered for the final specification of the TaaS model:

1. End-to-end connectivity

1.1. TaaS layer must support end-to-end connectivity among gateways.

2. Instance management

2.1. TaaS layer must support setup/shutdown of an instance.

2.1.1. During the setup of an instance, TaaS layer must initialize the end-to-end network of gateways.

2.1.2. During the shutdown of an instance, TaaS layer must finalize the end-to-end network of gateways.

2.1.3. Setup and shutdown of an instance are safe and reliable procedures.

2.2. TaaS layer must support join/disjoin of a gateway within an instance.

2.2.1. The local component of a gateway joining an instance will publish the locally connected things to the other local components.

2.2.2. Local things that are already connected at the join time will be published immediately.

2.2.3. Local things that will connect after the join will be published simultaneously to their con-nection.

2.2.4. The gateway joining an instance must be able to discover the things exposed by other local components within the instance.

2.2.5. The local components within an instance must stay up to date when a local component leaves an instance (i.e. disjoin).

2.2.6. Join and disjoin of a gateway are safe and reliable procedures.

2.3. The discovery operation must support dynamic changes of the instance composition.

3. Things identification

3.1. Things must be univocally identifiable.

3.1.1. A thing can be accessed within the instance by means of their unique identifier.

3.1.2. The thing identifier also identifies the context of the related thing.

3.1.2.1. The context is composed by information related to:

3.1.2.1.1. Location of the thing;

3.1.2.1.2. Functionality of the thing;

3.1.2.1.3. Thing service related to the thing.

3.1.2.2. The context of a thing is exploited to discover and locate the thing within the in-stance.

3.1.2.3. Context information are gathered from lower layers or created internally by the local component.

3.1.2.3.1. If the physical layer does not provide support for context information, these information may be provided by the user installing the thing by means of an UI.

3.1.2.4. Local components may be able to manipulate the context of the things. Exam-ples:



• The context of a light sensor can be modified reducing the power of the lamps and/or closing the windows.

• It will not be possible to change the context of a thing if no actuator or group of actuators able to do that are accessible.

4. Security

4.1. The TaaS layer must provide security capabilities.

5. Quality of Service

5.1. The TaaS layer must provide QoS capabilities.

5.1.1. The TaaS layer must provide support for negotiating the QoS through a standard proto-col.

5.1.2. The TaaS layer must handle and exploit the dynamicity of resource availability adopting a two-step procedure which entails resource reservation first (at the service negotiation time), and then resource allocation (at service invocation time).

5.1.3. The TaaS layer must implement monitoring capabilities to monitor the status of re-sources and to check that QoS provided is strictly within the boundaries agreed during negotiation.

6. Big Data

6.1. Setup a TaaS level database and its data definition

6.1.1. The database contains information related to:

6.1.1.1. Things data that need to be sent to a service BD component;

6.1.1.2. Data necessary to other TaaS component.

6.1.1.2.1. Data is independent from the underlying SQL database system



5. TaaS reference model and architecture

Following the same approach as in IoT-A and IoT-I, we first clarify the semantics associated to the terms ‘reference model’ and ‘reference architecture’, which are often used in the context of IoT interchangeably.

According to OASIS, “a reference model is an abstract framework for understanding significant relationships among the entities of some environment. It enables the development of specific reference or concrete architectures using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of underlying concepts, axioms and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or the concrete details” [14].

On the other hand, “a reference architecture is an architectural design pattern that indicates how an abstract set of mechanisms and relationships realizes a predetermined set of requirements. It captures the essence of the architecture of a collection of systems. The main purpose of a reference architecture is to provide guidance for the development of architectures. One or more reference architectures may be derived from a common reference model, to address different purposes/usages to which the reference model may be targeted” [4].

The two concepts are therefore different, and in particular many reference architectures may stem from the same reference model. In general, the reference model is composed by a domain model, an information model, a communication model, a security model, and a functional model identifying the main groups of functionalities. The reference architecture, instead, is essentially a functional view based on the reference model with all the functional blocks that are required by the final architecture.

As already mentioned, many research efforts have been done so far to define a comprehensive reference model for the IoT. Within the IoT-I project, many models have been analyzed directly, or inferred from existing systems (including some of those surveyed in Section 2), and compared with the one defined by the IoT-A project through a reverse-mapping of the models.

The outcome of this analysis is that the Reference Model as defined by IoT-A is expressive enough to allow a modeling of all the other existing IoT reference models using the IoT-A one [3]. We therefore considered the IoT-A reference model as a basis, though with some modifications/extensions to reflect a few specific aspects of BETaaS, in particular with respect to the information and functional models. We then specified a reference architecture for the TaaS (and the underlying layers) stemming from the proposed reference model. Both models are detailed in the following sub-sections.

5.1. Reference Model

5.1.1. Domain Model

BETaaS adopts the IoT-A domain model, which has been designed to cover a very broad range of possible IoT scenarios, including those envisaged by the BETaaS project for the deployment of the BETaaS platform. The abstraction provided by the IoT-A domain model allows in particular to describe objects independently of the technologies and the use-cases.

In particular, BETaaS will use the IoT-A Domain Model as an Upper Ontology of the network of ontologies that the project will implement. An Upper Ontology is an ontology which describes very general concepts that are the same across all knowledge domains. BETaaS will specialize this Upper Ontology in the two domains that will be addressed by the project: the smart city domain and the home automation domain. This task is developed in WP2; further details can be found in Deliverable D2.1.2, Section 4 [13].

Things in BETaaS correspond to Resources as defined by the IoT-A model. We use the two terms interchangeably in the rest of the document.


The IoT-A information model is generic and flexible, i.e., the structure of the data is defined on a conceptual level without discussing their representation. The latter allows the use of the information model independently from one specific technology. The use of semantic modeling in the IoT domain



provides a basis for interoperating among different systems and applications by providing machine understandable and processible annotations.

BETaaS models the data that the platform exchanges in a way that it’s aligned with the Information Model of IoT-A. BETaaS developes a set of two ontologies to describe things, called BETaaS things ontology (betaas_things#), and BETaaS context ontology (betaas_context#). These ontologies provide a high-level schema to describe sensors and actuators, along with their measurements, allowed operations, attributes and related context.

The BETaaS ontologies identify entities, resources and IoT services as key concepts within the IoT domain. The major considerations that BETaaS takes into account to design the semantic description framework, are summarized as follows:

• BETaaS creates a semantic description model based on the existing efforts that use semantic technologies to describe various resources and services in the IoT;

• BETaaS develops a comprehensive semantic model for the IoT services, maximizing compati-bility and reuse;

• BETaaS provides services that are independent of any particular service technologies.

The information model defined in BETaaS is an extension of the Device-Resource-Service model developed in the IoT-A project. In the IoT-A information model, a Device is part of the environment of an Entity. In the BETaaS things ontology, sensors and actuators are represented by a Thing (betaas_things#Thing), and users and software agents interact with a Thing through a Device (betaas_things#Device). In the IoT-A information model, the software component that provides information on an Entity is called a Resource, while in the BETaaS things ontology this concept is modeled by Thing (betaas_things#Thing). Finally, in the IoT-A information model, a Service has standardized interfaces and exposes the functionality of a Device by accessing its hosted Resources, the same as in the BETaaS context ontology (betaas_context#ThingService).

Figure 13: BETaaS ontology model vs IoT-A model

Based on the correlation showed in Figure 13, the identified concepts are modeled in BETaaS according a suite of ontologies that model the Devices, the Resources and the Services. These ontologies serve as a high-level model of the IoT domain that references some already existing vocabularies. The concepts related to other relevant domains, such as measurements and location, have been included from other ontologies.

BETaaS goes beyond the IoT-A information model, and also models the context of the things. The description of the context modeling that BETaaS implements is defined in D2.1 [11].


The IoT-A communication model is compliant with a wide range of IoT scenarios, e.g., constrained network-to-constrained network, constrained network-to-unconstrained network. Moreover, the communication model can be mapped to the ISO/OSI communication stack without modifications [4].




BETaaS adopts the IoT-A security model with some emphasize on the specific natures of BETaaS platform. As defined in the IoT-A, the high level abstraction of this model includes also trust, security, and privacy, three different concepts that are highly correlated to each other. Trust, security, and privacy also interact with the other components in the TaaS Reference Model, e.g. Domain, Information, and Communication Models. For example, combinations of User and Resource in Domain Model will define access permission; contextual information from the Information Model may be used to evaluate the trust; on the other hand the security mechanisms are also required to ensure the confidentiality and integrity of information being communicated which involve Information and Communication Model.

In the case of trust, it will be focused on the application level by evaluating several aspects related to the main concepts mentioned in IoT-A (i.e. data quality, endpoint authentication, confidentiality…) together with other concepts which are relevant for applications and services running on top of BETaaS, such as scalability, QoS fulfillment and dependability. This extension will also facilitate resources management in BETaaS platform, since it provides a more complete view of the resources available.

While there is no single model of trust, security, and privacy that can be applied to all different types of IoT scenarios, i.e. the model is strongly related to the organization’s policy or types of application which will impact in the design and implementation phase, there are several mandatory features needed to be included in the security model as described in the IoT-A. Particularly in the BETaaS platform, the trust, security, and privacy should engage in different levels of BETaaS operation, such as among different BETaaS instances, among BETaaS gateways within the same BETaaS instances, and with the external applications that consume the services provided by a BETaaS instance. For example, Identity Management is one of the most important features to provide privacy. In BETaaS case, the Identity Management should manage how the identities of sensors or gateways to be presented in their interactions within the same BETaaS instance, with other BETaaS instance, or with external application.

5.1.5. Functional Model

BETaaS main concepts have been introduced in Deliverable D1.2.2 [3]. In particular, a layered architecture is conceived including three main layers: the Service layer, the Logical layer, and the Physical layer, respectively. The logical layer is further subdivided into two sub-layers, i.e., the Things-as-a-Service layer and the Adaptation layer. This layered approach is reflected into the functional model depicted in Figure 14. Each BETaaS layer/sub-layer corresponds to a functionality group in the BETaaS functional model, which also highlights their relationship with each other.

Figure 14: Functional Model

In order to emphasize the distributed nature of the BETaaS architecture, Figure 15 and Figure 16 highlight the relationship between the functional groups, BETaaS gateways (i.e., the main components of the BETaaS platform), and existing IoT/M2M systems which are integrated into the BETaaS platform.

Service

TaaS

Adaptation

Physical



Figure 15: BETaaS functional model instance – BETaaS-u naware M2M systems.

Figure 16: BETaaS functional model instance – mixed B ETaaS-enabled and BETaaS-unaware M2M systems

A distinction is made between BETaaS-enabled and BETaaS-unaware IoT/M2M systems, respectively. The latter are fully unaware of the BETaaS platform and its functionalities (though could well implement inside some of these functionalities, though not interoperable with BETaaS), and therefore need a dedicated adaptation layer to be seamlessly integrated. This option allows for integrating any system into BETaaS, though at the cost of the possible replication of some functionalities.

On the other hand, the former type of systems, i.e., BETaaS-enabled, are assumed to also implement some or all of the BETaaS functionalities in a fully interoperable manner, i.e., compliant with the BETaaS interfaces. In this manner, interoperability is ensured by definition while a highest level of implementation efficiency can be achieved. Not all BETaaS functionalities at any layer need to be implemented by the IoT/M2M systems (see Figure 16). In this case, a companion BETaaS gateway is needed to provide the missing functionalities.

Finally, as can be seen, one or more adaptation functionalities can be deployed per BETaaS gateway, depending on the number of heterogeneous M2M systems connected to the gateway. On the other hand, one single distributed instance of the TaaS functionalities is deployed per BETaaS instance.

The functionality groups identified by the functional model are discussed in the following.



5.1.5.1. Physical

BETaaS supports different existing IoT/M2M systems which can be plugged into the BETaaS platform. A physical IoT/M2M system can be integrated into BETaaS if it satisfies a set of minimum requirements, i.e., each system must implement and expose a predefined minimum set of functionalities. In case this is not true, the system cannot be integrated. The minimum physical layer requirements are captured by the functional view of the physical layer defined in Section 5.2.1. The logical layer is responsible for guaranteeing that different models can coexist and interoperate inside the same instance or attached to the same gateway.

5.1.5.2. Adaptation

The Adaptation Layer aims at providing a common interface to the TaaS layer regardless of the underlying IoT/M2M system. Through this common set of APIs, the TaaS can access the functionalities offered by any IoT/M2M system in a uniform manner. The Adaptation Layer relies on a set of basic functionalities which are assumed to be provided by the Physical Layer.

For each IoT/M2M system which is integrated in BETaaS, a specific implementation of the Adaptation Layer has to be provided. Nevertheless, the Adaptation Layer exposes a uniform set of functionalities to the TaaS layer. A BETaaS gateway can run different instances of the Adaptation Layers concurrently to interconnect to different local IoT/M2M systems.

5.1.5.3. TaaS

TaaS enables the service layer to access things1 as a service. TaaS is implemented in a distributed manner: each gateway implements a TaaS local component which connects to the others to provide access to the things transparently regardless of their location in the network. A service requiring access to one thing, interacts with its TaaS local component, the unique interface towards the things. The local component is then responsible for accessing the thing through its own Adaptation Layer, if the thing is connected to the local network, or for requesting the service to the TaaS local component of the gateway where the thing is connected. The interconnection of all the TaaS local components forms an overlay which allows services to access the things regardless of their physical location through its local component which is a single point of access.

5.1.5.4. Service

The Service Layer is built on top of TaaS: it provides services to applications leveraging on the things accessed through the TaaS. The Service layer implements the basic and extended capabilities of the BETaaS platform. The abstraction provided by TaaS allows services to access the things as they were connected the local gateway without have knowledge of their physical location. The functional view of the Service Layer is described in [13].

5.1.6. Relation of Communication model to Functiona l model

Figure 17: Communication model vs. Functional model .

The communication model can be easily mapped to the functional model as shown in Figure 17. The Physical, Link and Network layers are assumed to be implemented by the underlying M2M systems, i.e., 1 We recall that a ‘thing’ in BETaaS corresponds to a ‘resource’ as defined by the IoT-A model.



the BETaaS platform is agnostic with respect to the specific networking technology adopted to interconnect the things. The ID layer is split between the Adaptation (as far as local addressing is concerned) and TaaS (for global naming). Finally, end-to-end communication is ensured by the TaaS. The Data layer, which involves context-awareness and semantic description of things is partially covered by TaaS, and fully exploited at Service Layer.

5.2. Reference Architecture (functional view)

The goal of the TaaS layer is to provide access to things through a standard service-oriented interface regardless of the underlying concrete M2M system implementations.

The proposed functional view of the TaaS layer is represented in Figure 18. TaaS functional components build upon the functionalities of the adaptation and physical layers. A functional view of the latter is therefore also reported, in order to clarify these dependencies. In particular, the functional components of the physical layer identify a minimum set of functionalities which are expected by any M2M system in order to be eligible for integration into BETaaS. On the other hand, the functional components of the adaptation layer define a set of functionalities which are provided to the TaaS layer in a uniform manner, either leveraging the same functionalities already implemented by the M2M system, or realizing them within the adaptation layer when not supported by the physical layer.

Figure 18. TaaS functional view.

Figure 18 illustrates the overall reference architecture and the functional blocks composing each layer. Blocks with a dashed border are optional. The functional components are explained in detail in the following.

5.2.1. Physical

• Routing: network management functionalities and routing must be provided by the IoT/M2M system.

• Connectivity: basic network connectivity to/from the things must be provided by the IoT/M2M system.

• Security: Security support at this layer is optional, however the IoT/M2M system could provide low level security support that can be exploited by the Adaptation Layer.

• QoS: basic functionality for supporting Quality of Service. QoS support at Physical Layer is op-tional. If the IoT/M2M system provides QoS support, QoS capabilities should be exploited by the Adaptation Layer.



• Context: provides semantic information that describes a thing. Context at Physical Layer is op-tional. If the IoT/M2M system provides this functionality, the Adaptation Layer should exploit this functionality.

• Reliable Transmission: implements basic functionalities to ensure reliable transmission. Reliable transmission at Physical Layer is optional; if it is provided by the IoT/M2M system, it should be exploited in the Adaptation Layer.

• Discovery: provides functionalities to discover things connected to the instance of the IoT/M2M system. The Discovery at Physical Layer is optional. The model may or may not implement dis-covery of its things.

5.2.2. Adaptation

• Local Discovery: is used to discover things directly connected to the physical layer depending on the protocol(s) for communication implemented (IoT/M2M). If the physical layer protocol does not provide any discovery functionality, information about the things must be statically con-figured at the Adaptation Layer with help from user entered data.

• Security adaptation: remaps the functionalities of the Physical Layer to the TaaS layer accord-ing to the predefined set of functionalities exposed by a standard API. In case the functionalities provided by the IoT/M2M system do not fulfil the basic set of functionalities, the missing func-tionalities are implemented.

• QoS adaptation: is responsible for exposing a uniform interface to the TaaS layer for the QoS functionalities provided by the physical layer. In case some QoS support from the Physical Lay-er is provided, QoS adaptation develops an uniform interface that is exploited by the TaaS QoS.

• Addressing: is used to address things exposed by the IoT/M2M system. Since different models can have different addressing schemas, this block is responsible to uniform them into a stand-ard addressing schema exposed to the TaaS layer. In case identification is not present in the list of Things, Things Adaptor is responsible for providing unique identification.

• Context adaptation: provides a semantic description of the things. Some IoT/M2M systems ex-pose enhanced metadata associated with each thing in order to describe its minimal features. The CoRE Link Format, for example, provides a description of the type of the thing. IoT/M2M systems do not always provide the semantic description, in case no semantic support is provid-ed, the Adaptation Layer is responsible for providing a description based on a static configura-tion provided at the time of system configuration.

• Reliable Transmission: guarantees reliable communication to the things of the IoT/M2M system. Even though reliable communication is not mandatory, IoT/M2M systems often provide reliable communication; in this case this block does not implement any functionality.

5.2.3. TaaS

• Thing Services: is used to expose the things as services. The Service Layer interacts with the things through this functional block. TaaS exposes basic services which can be mapped directly to the things. Each thing exposes its information or is accessible by means of a unique thing service.

• Context: manages a semantic description of the things as a service. It has a strict correlation to the context provided by the Adaptation Layer. By means of the thing service semantic descrip-tion each thing can be described using a set of enhanced attributes to include additional infor-mation such as location-awareness.

• ID: each thing must be global addressable within one BETaaS instance. The ID block provides addressing functionality regardless of the location of the thing and the addressing adopted by the IoT/M2M system. Rather than the addressing provided by the Adaptation Layer which has a local scope, the addressing provided by this block is valid and unique all over one BETaaS in-stance.

• Look-up: is used to search and resolve thing services based on context information. The look-up functionality provides the set of available things (through their IDs) exposing the requested services.



• Global Discovery: is used to discover things inside the same BETaaS instance.

• QoS: provides functionalities used by the Service Layer to request a certain QoS for accessing a Thing Service. In order to fulfill the application needs, the QoS is negotiated in order to stipu-late a SLA. For this reason, a negotiation procedure is implemented by this functionality. Jointly with Resource Management, QoS is also responsible for managing the resources, efficient management of things is performed exploiting Equivalent Thing Services by means of a number of parameters, e.g., in terms of energy efficiency. In order to handle and exploit the dynamicity of thing status and their varying availability, QoS implements the management as a two-step procedure which entails resource reservation at the time of the service negotiation and resource allocation at the time of the Thing Service invocation. QoS functionality has to implement moni-toring functionalities to monitor the status of the resources and the quality of the exposed Thing Services. Resource monitoring is necessary to detect malfunctions/failures and to collect infor-mation regarding the status of the Things. SLA monitoring, instead, monitors the QoS level ob-tained by each Thing Service to check that the negotiated SLAs are fulfilled. In case a SLA is violated this functionality will report to the Resource Management functionality which will invoke predefined actions.

• Resource Management: is responsible for monitoring, managing and controlling things and oth-er resources. In detail, this block collects information on resources available and the needs coming from services and applications, mapping needs and thing services. It requires the sup-port of Security and QoS blocks in order to accept or reject the request for a new service and al-locate the adequate resources based on the output of these functional blocks. This block is also responsible for checking monitoring information to detect failures and providing dynamic solu-tions (i.e. re-allocating thing services).

• TaaS connectivity: manages the communication between different TaaS local components in-side the same BETaaS instance.

• Security: manages the security, trust, dependability and privacy within a BETaaS instance. In particular, key management feature is of the importance and thus mandatory. It is important in the gateways authentication process (to become part of BETaaS instance), establishing trust among gateways in a BETaaS instance, e.g. by means of certificate, and providing secure communication within an instance. Other security related functionality that can be included are trust and reputation evaluation of thing services based on their interaction within an instance, protection against malicious nodes (a node could be any device, e.g. gateway or sensor, within and outside of the instance) by means of several aspects (identity management, access control, data provided, expected availability…).

• Big data: manages the collection, storage and maintenance of data for the BETaaS TaaS com-ponents. Moreover, it is also responsible for defining the storage configuration so that data is available for components that need to access it. The TaaS BD allows other TaaS components to access data by retrieving connections from its internal database connection pool or by defin-ing an interface that maps an underlying table. In this way is avoided the proliferation of different database system and data management is centralized by only one component reducing the management efforts. The BD at TaaS level offers also a set of functionalities to process Things’s data and sent it to the Service level BD component. In this way each TaaS BD inside a BETaaS instance, contribute to the service layer BD component data by providing its relevant information collected.

• Virtualization: It provides the capability of managing Virtual Machines in the local environment. Those VMs may be created in certain physical resources in order to obtain storage and compu-tation resources, which may be useful for enabling Big Data capabilities and for deploying cer-tain services in isolated environments, increasing the secure operation of BETaaS instances. It can also communicate with external clouds for requesting more resources when local resources are not enough.

5.2.4. Platform requirements – functional blocks ma pping

In this section we map the different User and System requirements defined in [3] to the functional blocks defined in Section 5.1.5. Each requirement is linked to the functional blocks which allow the platform to meet its needs and conditions. Since this document focuses only on TaaS and Adaptation layers, we consider the requirements related to them.



5.2.4.1. User Requirements

Requirement Id

Requirement Description Layer Functional Blocks

USR-R2 The system shall provide event-based and periodic communications as a consequence of the user requests.

TaaS Thing Services

USR-R3 The system shall support storage of data allowing extraction of real time information and the processing of large amount of data to user.

TaaS Big Data

USR-R4 Services indicate what information can be found by performing a Discovery of or Look-up for available information.

TaaS Context Look-Up

USR-R5 Services shall provide semantic information where possible.

TaaS Context

USR-R6 The system shall support devices to activate themselves.

Adaptation Local Discovery

USR-R7 The system shall allow the semantic description of physical entities and services by a user.

TaaS Adaptation

Context Context adaptation

USR-R8 The system shall provide different access permissions to information.

TaaS Adaptation

Security Security adaptation

USR-R9 Device communication and or assimilation of their data shall be performed seemingly to the user.

Adaptation Reliable Transmission

USR-R10 The system shall provide reliable services. TaaS Adaptation

QoS QoS adaptation

Security

USR-R15 BETaaS instance can be scalable, users should provide as little input as possible for introducing new BETaaS GW into their local BETaaS instance.

TaaS TaaS Connectivity

USR-R18 Things can use the physical layer (i.e. other Things) of the hardware component running the BETaaS gateway in a transparent way.

Adaptation All functionalities at the adaptation

USR-R20 A service provided by a Thing can become available to the local Instance by joining the BETaaS gateway in the BETaaS instance.

TaaS Thing Services Resource

Management

USR-R21 Services shall use the context that surrounds the things, to infer knowledge from raw data.

TaaS Context

5.2.4.2. System Requirements

Requirement Id


SYS-R1 Encryption algorithm for transmission of vulnerable data.

TaaS Adaptation

Security Security adaptation

SYS-R2 Protection mechanisms should be lightweight, TaaS Security



Requirement Id


not requiring too much resources but, at the same time, providing enough temporary protection.

Adaptation Security adaptation

SYS-R4 Include Quality of Service (QoS) support to guarantee that services are provided with the quality required by applications.

TaaS QoS

SYS-R6 Provide support for negotiating the QoS required by applications. Provide support to re-negotiate QoS to handle internal/external changes.

TaaS QoS

SYS-R7 Monitor resources to detect failures and to allocate resources to accomplish negotiated SLAs.

TaaS Adaptation

QoS QoS adaptation

SYS-R8 Collecting Data from heterogeneous sources. Adaptation Context adaptation

SYS-R9 Support real-time class of service. TaaS QoS

SYS-R10 Distribution of data so that a failure in one point should not compromise the availability of the overall information generated and increase its overall availability.

TaaS Big Data

SYS-R11 Define a mechanism to aggregate information to support an efficient processing with Big Data systems.

TaaS Big Data

SYS-R13 Extract information in real time. TaaS QoS

SYS-R15 Collection of data from different domains BETaaS GW in the same local BETaaS instance is similar to Collecting data from the same BETaaS GW and even though unique in their nature will be assimilated as if they are gathered from a single BETaaS GW.

TaaS Global Discovery TaaS Connectivity

SYS-R15 BETaaS shall be a service platform for the IoT and the M2M operating over a local cloud of gateways.

TaaS TaaS Connectivity

SYS-R16 The BETaaS instance shall be able to operate and interoperate with different M2M frameworks at its Physical Layer.

TaaS Global Discovery TaaS Connectivity

SYS-R17 Different M2M frameworks at the physical layer are supported by means of adaptation layers. New adaptation layers can be developed to support new M2M frameworks.

Adaptation All the functionalities at the Adaptation

SYS-R18 The BETaaS instance shall be a local cloud of BETaaS gateways. Each BETaaS gateway can provide a certain set of services.

TaaS All the functionalities at

the TaaS

SYS-R22 The BETaaS instance handles the different TaaS Thing Services



Requirement Id


service queries that the BETaaS applications send, by relaying them to the BETaaS gateway that can support that particular request. All these communications happens internally to the local cloud and transparently to the application.

SYS-R31 The BETaaS services shall relay on a common reference model (TaaS– Things as A Service).

TaaS All functionalities at the TaaS

SYS-R35 QoS should monitor resources to detect SLA violations.

TaaS QoS

SYS-R36 Independence of QoS guarantees among different service and different instances.

TaaS QoS

5.3. Information handling by functional components

In this section we provide an overview of how information is handled and exposed by the functional components of the platform. Particular attention is given to the information flows between the functional components at the TaaS and Adaptation layers during the major operations described in [17]: service negotiation, data retrieval, thing connection and thing disconnection.

5.3.1. Service Negotiation

When an application is installed into the platform, the set of required services are negotiated with the platform. This operation involves at the Service Layer the negotiation of the Thing Services exposed by the TaaS.



Figure 19. TaaS service negotiation information flow .

Figure 19 illustrates the information flow of the service negotiation procedure. As can be seen, the negotiation is a two-step procedure: first, the availability of the required Thing Service is verified, then, if the Thing Service is available and specific QoS requirements are needed, a negotiation between the Service layer and the TaaS layer is performed to sign a SLA.

A Thing Service request from the Service Layer is first handled by the Thing Services functionality (1) which is responsible for querying the Look-up and Context functionalities to retrieve the list of the Thing Services that suit the context (2) (3). During this process the Context functionality also retrieves the IDs associated with each Thing Service (4). As the list of the Thing Services is obtained (5), the Thing Services functionality check the security level of each element with the Security functionality in order to remove Thing Services that do not satisfy the required level of security (6). If the list is not empty, a positive response is sent back to the Service layer (7). During this process a Transaction ID is generated to identify this particular service negotiation transaction. If the Service layer has QoS needs, the QoS Thing Service negotiation is executed: the Service Layer initiates the procedure sending an SLA offer to the QoS functionality (8), specifying the service level required for the Thing Service and the Transaction ID generated during the first phase. The QoS functionality retrieves the Thing Service list from the Thing Services functionality (9), then checks the status of the Things to evaluate if the requested QoS can be met. If the current status allows the Thing Service to be provided with the required QoS, an Agreement EPR message is sent back to the Service Layer (10) as acceptance.



Figure 20. Look-up functionality instance.

Figure 21. QoS functionality instance.

In order to emphasize the distributed nature of the platform, Figure 20 and Figure 21 highlight the relationship between, respectively, the Look-up and QoS functionalities and the BETaaS gateways. As can be seen, both Look-up and QoS are implemented in a distributed fashion: the instances implemented in the TaaS local component of each gateway cooperate among themselves by means of the functionalities offered by TaaS Connectivity and Global Discovery. The interaction is performed by the Look-up and QoS functionalities to retrieve the information regarding the list of the Thing Services available in the BETaaS instance and to manage the QoS of Thing Services not locally connected, respectively.

5.3.2. Data Retrieval

When a service invokes one specific Thing Service to retrieve real-time data from the sensor, several cross-layer operations are triggered to read from the sensor a fresh real-time value.



Figure 22. Data Retrieval information flow.

Figure 22 illustrates the information flow during this operation. The Thing Service functionality receives the request (1) from the service layer and then checks the fulfilment of the security requirements (2). Before forwarding the request to the Context (4), the QoS (3) selects one specific Thing Service among the list of Equivalent Thing Services according to the QoS requirements. The Context functionality forwards the request to the Adaptation Layer for information retrieval. Before being forwarded to the Physical Layer through Addressing and Reliable Transmission functionalities (8) (9), the request passes through the Context, Security and QoS adaptation functionalities which adapt the request to the format required by the specific physical system. If needed, some basic functionalities not provided by the physical system but required by the platform can be implemented in these functionalities, (6) (7) (8). As soon as the physical system returns the data, the latter is sent to the Context adaptation (10) in order to enrich data with context information in the uniform format expected by the TaaS layer. Data with context information are then sent back to TaaS (11) and then forwarded to the Service layer (12) (13).

5.3.3. Thing Connection/Disconnection

The connection of a new thing triggers a set of operations in the platform to create a new Thing Service which can be accessed globally by applications running all over the BETaaS instance. Similar operations are performed by the platform when one Thing is disconnected causing the associated Thing Service to be removed.



Figure 23. New thing connection information flow.

Figure 23 illustrates the information flow among different functionalities when a new Thing is connected to the system. Rather than the events considered so far, the information flow originates from the Physical Layer which triggers the Local Discovery functionality of the adaptation layer. As a new thing is detected, the Local Discover forwards the information on the new Thing to the Context adaptation, (1). The latter is responsible for adapting the context information provided by the thing to the common format required by the platform before triggering the TaaS. In case no context information are provided by the physical system, the Context adaptation adds context information that must be provided by manually at the time of system configuration. The TaaS is notified through the Context functionality (2). The latter, in turn, notifies the event to the Big Data functionality (3) and to the Thing Services (4). The Thing Services is responsible for registering the new Thing with the Resource Management and Global Discovery (5) (6). Eventually, the Thing Services functionality generates the new Thing Service associated with the new Thing exposing it to the Service Layer (7).



Figure 24. Thing disconnection information flow.

Figure 24 illustrates the information flows triggered by the disconnection of a Thing from the platform. The information flow is specular to the one triggered by the discovery of a new thing as illustrated in Figure 23.



6. Mapping to existing models/architectures

This Section will include an analysis of the models described in Section 2 with respect to the TaaS reference architecture and the requirements of the physical layer, thus identifying the major gaps to be filled by the respective adaptation layers and providing guidelines for their implementation.

6.1. IoT-A

The TaaS reference architecture has been derived from the IoT-A reference model, for this reason the mapping between the TaaS and the IoT-A functionalities is quite straightforward. IoT-A proposes a layered structure where the lower layer is the communication layer. The latter controls and manages network in terms of: routing, connectivity and reliable transmissions. QoS support is provided only at communication layer while security is implemented following a cross-layer approach. Finally, context functionality is split in different layers each one with different abstraction level and regarding different aspects. In fact, there are two main layers where context is used inside the IoT-A model: IoT service layer and Virtual Entity layer.

In the first layer there are three main functions: Discovery, Look-Up and Resolution. While Look-Up and Resolution are used only in conjunction with an already known Service ID the Discovery process is used to find an IoT service based on a query composed by a server specification. For this reason the discovery functionality uses context information specified by the user and also context information derived by the services available in the system.

In the Virtual Entity layer there are instead two main functions: Discovery and Look-Up. The Look-Up process is used in conjunction with a VE-ID and a VE Service Specification. The latter is used to specify the kind of the service requested on a specific Virtual Entity. The result is a Service ID that can be used to resolve the service using the functionalities provided by the IoT service layer. The Discovery process, instead, is based on a VE Service Specification and also on a VE Specification. The VE Specification is used to define the Virtual Entity without any prior knowledge about the VE-ID. The context information, in this layer regards both process, VE Service Specification and VE Specification in fact, are based on context information. An example of Discovery derived from [16] is the following, where the first field is the VE Specification while the second is the VE Service Specification:

discoverAssociations( {“type”: “parking space”, “scope”: <geographic scope>}, {“available”: “true” } );

6.2. ETSI M2M

With respect of TaaS Reference architecture we can map BETaaS Service Layer, BETaaS TaaS Layer and BETaaS Adaptation Layer on the ETSI M2M Application (e.g. GA, DA or NA). Therefore the physical layer exposed in section 5.2.1 is mapped on the Service Capabilities Layer (SCL) and its underlying layers. ETSI M2M SCL can use Core Network functionalities through a set of exposed interfaces (e.g. existing interfaces specified by 3GPP,3GPP2, ETSI TISPAN, etc.), additionally, M2M service capabilities can interface to one or several Core Networks.



Figure 25: ETSI M2M and BETaaS mapping

With reference to TaaS reference architecture, ETSI M2M (i.e. BETaaS physical layer) may provide:

• Routing. ETSI M2M will provide routing and network management to allow things to be ac-cessed through the Network layer of its communication model and by the ETSI M2M Service capabilities Layer.

• Connectivity. As shown in 3.2.3 the ETSI standard is able to provide connectivity between the actors of the M2M network and to provide resources gathering.

• Context. ETSI M2M can provide support to define the context of a thing by means of M2M Re-source’s Attributes which provide a method to add meta-data to resources.

• Discovery. Discovery of resources is possible in ETSI M2M by using a specific resource. The “Discovery Resource” allows discovery of resources matching a specified filter criteria. The re-sult is a list of URIs matching the filter criteria which is sent back to the issuer.

• Reliable Transmission. In ETSI M2M reliable transmission is provided by lower layers of the communication model.

• Security. ETSI M2M provides security support to access things in a reliable way as explained in section 3.2.4. ETSI M2M security capabilities could be used and extended by the Adaptation Layer to provide security in the BETaaS framework. Security in M2M ETSI is managed by the xSEC (SECure) and xGC (Generic Communication) capabilities.

• QoS. ETSI M2M can provide support to QoS through some M2M Service Capabilities. Specifi-cally the following service capabilities may be used as a support for QoS:

o G/NAE (Gateway/Network Application Enablement) is able to generate charging rec-ords pertaining to the use of capabilities in a ETSI M2M network.

o NGC (Network Generic Communication) is optionally able to inspect traffic generated by a particular M2M Device or M2M Gateway and verify it is matching a given traffic pattern (e.g. number of connections per day, traffic volume per day, more than 20% of the monthly average traffic is generated in one day, etc.)

o D/G/NCS (Device/Gateway/Network Communication Selection) provides network selec-tion, based on policies, when the M2M Device or M2M Gateway can be reached through several networks or can provide alternative networks after a communication failure over a network.

o NREM (Network Remote Entity Management) collects and stores Performance Man-agement data as well as Fault Management data.

o D/G/NTM(Device/Gateway/Network Transaction Management) is an optional capability. A transaction is an operation that involves several operations (from different entities in



the M2M System) and requires atomicity in its execution. In case one single operation is not completed, the overall transaction is considered as unsuccessful. The xTM capabil-ity provides the following functionalities:

� propagates the individual operation requests;

� aggregates the results of the individual operations and commits the transaction when all individual operations have completed successfully;

� trigger a roll-back if any individual operation fails.

6.2.1. Adaptation Layer

This section aims to describe some key-points of M2M system that the Adaptation Layer has to cope in order to include transparently the “M2M things” within the platform.

The following figure describes different deployment scenarios of M2M components:

Figure 26: M2M scenarios

The most suitable scenario for the BETaaS world is represented in the following figure.



Figure 27: Scenario M2M in BETaaS

In this case, a device Type D’ (smart end device, sensor, etc.), running a DA, is able to exploit the capabilities of the GSCL. In the same way, in the Gateway, a GA is connected with the GSCL. The GSCL are accessible by protocol COAP/HTTP.

The main efforts for BETaaS, in order to include M2M devices in the platform can be summarized in the following points:

• Include the GSCL within BETaaS GW. In this case BETaaS GW is raised also to a M2M GW. The Adaptation Layer should communicate with the GSCL that could be obtain by:

o Developing the GSCL by its own according to the ETSI M2M standards in particular [18],[19].

o Downloading open source implementation of GSCL, as http://cocoon.actility.com/. This project is based on an OSGi framework compliant with version 4.2 named Knopflerfish. It is formed by several bundles which are the unit of deployment on OSGI. These bun-dles are built using the Apache Maven tool. The GSCL are bundles managed by the framework OSGI.

o Exploiting proprietary implementation. That is the case of Interdigital that developed GSCL as simple applications.

• Regardless of where the GSCL are installed, the Adaptation Layer should implement a GA, able to interact with the GSCL. The Adaptation Layer could exploit many ETSI M2M capabilities in order to add more and more capabilities in BETaaS (security, QoS, etc).

A simple example is described; it comprises some primitive APIs to be created both by DA-side and GA (Adaptation Layer)-side in order to allow the GA to perform some basic operations on the sensors by means of GSCL. In the following example the Monitoring Application corresponds to the GA.



Figure 28: basic operation between DA and GA throug h the GSCL

• Application Registration: initialization procedure by which each application needs to register with the local Service Layer (xSCL).

• Creation of Containers in xSCL: the sensor application needs to create a container in order to store its reading and make them available for authorized applications.

• Subscribe to Data Container: the GA needs to create a subscription to the sensor container in order to receive reading notifications when the sensor application reports them.



• Creation of ContentInstance in xSCL: once the sensor container is created, in order to begin re-porting and storing data values in the container, the sensor application needs to send a conten-tInstance create request to the SCL for its associated container. This create request provides in-formation on the type of data as well as the data value itself.

• Notification of Monitoring Application: the xSCL sends the notification message to GA about new data on the DataContainer.

• Retrieve ContentInstance: once the GA receives the notification of a new content instance, it needs to retrieve the values. In order to do this, it needs to issue a retrieve request for the new content instance of the sensor’s data container.

6.3. IETF Constrained RESTful Environments (CoRE)

The mapping described in this section relies on the assumption, without loss of generality, that a CoAP proxy is connected to a BETaaS gateway. The CoAP proxy is used, inside a CoAP environment, to expose any connected CoAP endpoints to the outside world, or in our case, to a BETaaS gateway. On one hand BETaaS must assume a general communication protocol between the CoAP proxy and the things without rely on specific features. On the other hand, CoAP has been defined to work over an IP network with UDP as the default communication protocol. In general, the CoAP proxy can be hosted on a BETaaS gateway in a different process.

The CoRE Group provides those functionalities:

• Routing: is provided by low level protocols and depends on specific implementation. BETaaS must assume this functionality and consider it as a black box.

• Connectivity: is provided by means of URI and CoAP methods. Resources can be addressed, inside any request, by their unique URI, each request carry also a CoAP method to define which operation must be performed on the target resource.

• Security: CoAP supports Datagram Transport Layer Security (DTLS) natively. DTLS is defined in RFC 6347 and is derived from the Transport Layer Security (TLS) protocol. DTLS provides similar security guarantees over datagram protocol.

• QoS: is not supported natively by CoAP. The only exception is during an observing relationship. A client can request, to a CoAP server, a predefined "observing interval" to achieve a minimal and not guaranteed QoS support. In fact, the server may or may not respect the interval sug-gested by the client.

• Context: is provided in terms of metadata associated to each resource by the CoRE Link For-mat. During the resource discovery mechanism, each resource announced by a CoAP server, can be enriched with some metadata. The latter can be used to export information regarding the context.

• Reliable Transmission: is provided by a simple stop-and-wait mechanism. CoAP re-quests/responses are encapsulated inside a CoAP message, CoAP defines four message types, where the two main types are: Non-Confirmable (NON) and Confirmable (CON). While NON messages are totally best-effort, each CON message must be acknowledged by the re-ceiver. In this way, CoAP implements a simple stop-and-wait mechanism with exponential back-off timeouts to achieve reliable transmissions.

• Discovery: CoAP defines the server and resource discovery processes which are used, in order, to discover things and the resources hosted by each thing. The server discovery process is im-plemented by means of multicast communication relying on underlying IP layer. The resource discovery process, instead, is defined as part of the standard and is accomplished through a GET request to a well-known URI. Each CoAP server uses the CoRE Link Format representa-tion to reply to any GET request on the well-known discovery URI. The payload of this response carries the list of resources hosted by the CoAP server eventually enriched by some metadata.

6.3.1. Adaptation Layer

In this section we aim at describing an overall structure of a possible implementation of an Adaptation layer aimed at connecting one or more CoAP systems to a BETaaS Gateway.



Figure 29: CoAP Adaptation Layer.

The implementation of an Adaptation layer is required to rely as much as possible on the functionalities offered by the Physical layer. For this reason, the Adaptation layer is responsible for mapping the functionalities offered by CoAP to the standard interface expected by the BETaaS platform and for implementing the functionalities mandatory for a system to be integrated into BETaaS but not provided by CoAP.

The overall structure of a possible implementation is illustrated in Figure 29. Since the only way to access a CoAP system is through a CoAP client, the Adaptation layer will have to implement all the functionalities to act as a CoAP client towards the CoAP systems locally connected. Since a CoAP client itself does not provide the minimum set of functionalities required by the BETaaS platform, some extra implementation is needed. It is worth to notice that some of the missing functionalities are not completely unknown in CoAP specifications since they are defined as functionalities provided by a reverse-proxy.

The functionalities of the adaptation layer can be divided into two sets. The first group of functionalities (on the left in Figure 29) needs only a simple mapping between the BETaaS system and the CoAP standard. These are the security functionality, which can be mapped to the DTLS protocol, and the context functionality, which can be achieved by means of the CoRE Link Format with a semantic mapping that unifies the CoAP environment with the standard interface exposed to the TaaS. In case the CoRE link format is not adopted by a particular implementation of CoAP, the context information has to be provided manually to the Adaptation layer at the time of configuration in order to enhance the semantic description of the things. The second group of functionalities (on the right in Figure 29), instead, require a full or partial implementation in order to fulfil the minimum requirements. Some of them can be implemented leveraging on some CoAP functionalities, others requires an implementation from scratch. Reliable transmission functionality, for example, can be implemented by means of the CON messages. Resource discovery and the service discovery, as defined by the CoAP standard, can be used to implement the local discovery functionality. A standard addressing schema, instead, has to be implemented from scratch in order to fulfil the requirements regarding end to end connectivity and addressing.



Finally, it is worth noting that since CoAP does not support QoS, the Adaptation layer will not provide, directly, any QoS functionality that are demanded to be provided by the TaaS layer.

6.4. ITU – FG M2M

For mapping ITU approach on M2M we provide the differences with the ETSI M2M service capabilities layer, which is compared to TaaS approach from BETaaS in Section 6.2.

ETSI M2M service capabilities layers (SCLs) provide functions that are to be shared by different applications and it can be explained using IoT reference model in Recommendation ITU-T Y.2060 as Figure 30 [15].

Figure 30 – ETSI M2M SCLs in IoT reference model

In Figure 30, dIa and mIa in ETSI can be considered as interfaces between IoT applications and service support and application support layer including general management and security capabilities. mId in ETSI can be considered as interface between service support and application support layer in different devices.

As shown in Figure 30, ETSI M2M SCLs include only general (or common) functions of service support and application support layer, management capabilities and security capabilities.

Compare to ETSI SCLs, ITU-T M2M service layer includes specific support capabilities in service support and application support layer and specific management capabilities and specific security capabilities as Figure 31.

Also, dIa, mIa and mId should be extended for specific support capabilities in service support and application support layer and specific management capabilities and specific security capabilities.

Figure 31 shows the M2M service layer in ITU-T scope. The specific support capabilities in the service support and application support layer needs to include various application specific support capabilities such as e-health support and telematics support capabilities.



Figure 31 – M2M service layer in ITU-T scope [14]

There are three types of applications on top of M2M service layer: device application (DA), gateway application (GA) and network application (NA). DA, GA and NA reside in device, gateway and server, respectively and use capabilities provided by M2M service layers.

ITU-T M2M service layer needs to have 4 different reference points: D-SL, G-SL, A-SL and SL-SL. The reference points between device application and service layer is D-SL, between gateway application and service layer is G-SL, between application and service layer is A-SL, and between service layer and other service layer is SL-SL.

6.5. Ecosystem

According to its current implementation and ongoing process of enriching several of its functionalities, Ecosystem can prove to be respecting several aspects of the TaaS architecture by implementing some of its characteristics. The lower levels of the BETaaS architecture are handled uniquely in Ecosystem as it is nevertheless independent propriety software. Most important though is the ability of the Ecosystem to consume and use Services provided by the BETaaS instance to which it can be attached.

Therefore, there are two cases under which Ecosystem can operate within a BETaaS Instance.

1. Control Application Development Platform. In this case Ecosystem is merely a consumer of Services provided by the BETaaS instance. These services are then passed through an appro-priate interface to the User who can use them as ready-to-use processes/actions/inputs in the development of a control application for a particular environment.

2. BETaaS-enabled GW. For this case, Ecosystem should implement some characteristics of the TaaS layer which will enable it not only to consume, but also publish Services in order to be a usable BETaaS-enabled GW.

Concerning the basic concepts of the Physical layer that must be implemented, Ecosystem provides the connectivity and routing since it is responsible for discovering and managing of the physical actuators, switches and inputs in the form of ports.

Adaptation layer’s principles are also covered by Ecosystem since the Port Delegator and Device creation Service provide the means for managing securely and effectively the information from the physical layer onto a rigid functionality that can be exploited from TaaS layer.



Given Ecosystem’s Services exposure and Command execution all the later can be exposed to the existing environment (as extra Services) or to another BETaaS instance providing functionality as part of the TaaS principles as described below:

• Context: Space management in combination with the Devices arranged within it, provide the context under which specific Services have a particular meaning to the end user.

• ID: Port Delegators make sure that all physical layer’s Devices have a specific ID. Upper layer’s Services are also uniquely identified.

• Look-up and Global Discovery: Devices and Services can be looked up based on their unique ID.

• QoS: Devices are constrained by the physical ports they represent in order to provide minimum quality to the Services which utilize them.

• Resource Management: Simple and uniquely identified Devices transmit their state throughout their entire lifecycle within the Ecosystem environment.

• TaaS connectivity: A particular Ecosystem instance can be itself a BETaaS-enabled GW, thus providing services to the nearby BETaaS Instance for utilizing along with their own Services.

Considering the last principle of the TaaS model, the schema in Figure 32 provides the general idea on how Ecosystem abides to the TaaS Reference Model, especially considering the fact that Ecosystem can have its top Service layer withdrawn when it comes to communicating and collaborating with other BETaaS instances therefore handing the orchestration of its available services to other BETaaS instances.

Figure 32. Ecosystem integration with TaaS.



7. Conclusions

This document includes the final specification of the reference architecture of Things-as-a-Service within the BETaaS platform. The IoT-A reference model was adopted as a basis, but several modifications and extensions were needed to reflect the specific aspects of BETaaS (in particular, the functional model has been thoroughly revised to account for the BETaaS layered architecture).

Stemming from the reference model, a reference architecture for TaaS has been defined to detail the different functionalities expected within each functional group, and how these functionalities are expected to be deployed within the different architectural components of a BETaaS instance, namely, the gateways and the IoT/M2M systems which are integrated at the 'physical' layer. Different deployment options are available to account for a full range of alternatives, including the relevant concept of BETaaS awareness within future IoT/M2M developed systems.

The proposed TaaS architecture provides the final reference for the definition of the basic and extended capabilities at the core of the BETaaS platform in WP2, as well as to the design of the BETaaS architecture (WP3) and the specification of the platform (WP4).



8. References

[1] Building the Environment for the Things-as-a-Service (BETaaS) EU FP7 Project, Deliverable D1.2.1 – User and System Requirements.

[2] Building the Environment for the Things-as-a-Service (BETaaS) EU FP7 Project, Deliverable D1.4.1 – TaaS Reference Model.

[3] Building the Environment for the Things-as-a-Service (BETaaS) EU FP7 Project, Deliverable D1.2.2 – User and System Requirements.

[4] Internet of Things – Architecture (IoT-A) EU FP7 Project, Deliverable D1.4 – Converged Architectural Reference Model for the IoT v2.0.

[5] Internet of Things – Architecture (IoT-A) EU FP7 Project, Deliverable D4.2 – Deliverable Concepts and Solutions for Privacy and Security in the Resolution infrastructure.

[6] “Machine-to-Machine communications (M2M); M2M service requirements”, ETSI TS 102 689 V1.1.2.

[7] ETSI TS 102 690, "Machine-to-Machine communications (M2M); Functional Architecture," European Telecommunications Standards Institute (ETSI), 2011.

[8] Building the Environment for the Things-as-a-Service (BETaaS) EU FP7 Project, Deliverable D1.1 – State of the art review.

[9] Z. Shelby, K. Hartke, C. Bormann, and B. Frank. “ Constrained Application Protocol (CoAP)”. Internet draft.

[10] Z. Shelby, “Constrained RESTful Environments (CoRE) Link Format”. RFC 6699.

[11] M. Nottingham, “Web Linking,” RFC 5988.

[12] The Internet of Things Initiative (IoT-i) EU FP7 Project, Deliverable D1.5 – Reference Model.

[13] Building the Environment for the Things-as-a-Service (BETaaS) EU FP7 Project, Deliverable D2.1.2 – Specification of the basic capabilities and content use of the platform.

[14] C. M. MacKenzie, K. Laskey, F. McCabe, P. F. Brown, R. Metz, B. A. Hamilton (Ed’s), “Reference Mod-el for Service Oriented Architecture 1.0”, OASIS, http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf, 2006.

[15] Deliverable D2.1: “M2M service layer: Requirements and architectural framework” (output of FG M2M meeting #5, Santander, 21-24 January 2013).

[16] Internet of Things – Architecture (IoT-A) EU FP7 Project, Deliverable D4.3 - Concepts and Solutions for Entity-based Discovery of IoT Resources and Managing their Dynamic Associations.

[17] Building the Environment for the Things-as-a-Service (BETaaS) EU FP7 Project, Deliverable D3.2.1 – APIs.

[18] ETSI TS 102 690 Machine-to-Machine communications: Functional architecture.

[19] ETSI TS 102 921 Machine-to-Machine communications: mIa, dIa and mId interfaces.

Documents

BETaaS - D1.4.2-TaaS Reference Model v1 - D1.4.2 - TaaS Reference... · such a model stemming from a careful analysis of the current state of ... we propose a higher level of abstraction