IoT6 main achievements

Main Achievements:

  • IPv6 features analysis performed
  • IoT6 service oriented architecture developed, including Digcovery and Digrectory
  • IoT6 stack implemented
  • Multiple integrations:
    - Legacy communication protocols
    - Software as a Service (SaaS)
    - Smart phones
    - Smart Things Information Service (STIS)
  • Smart board completed and smart routing enabled
  • Contributions to standardization processes, including 6TiSCH, oneM2M, ETSI, OASIS
  • Setting up of the IEEE ETC on IoT
  • Support to the IoT Forum
  • SME handbook
  • Several posters, postcards, flyer and communication material
  • Over 40 Publications
  • Over 30 Events co-organized and/or attended

 

1         Achievements by Work Package

 

1.1        Achievements in the WP1

The main objectives of WP1 were the following:

·       Identify relevant use case scenarios and derive requirements in close cooperation with the IIAB.

·       Research, design and define an open IPv6-based service oriented architecture enabling flexible integration interoperability and intelligence distribution among heterogeneous sub-systems of smart things.

The work package was organised in two tasks:

·       T1.1 IoT6 requirements and scenario definition: this task aims at specifying, analyzing and evaluating the IoT6 requirements, from both technical and conceptual points of view.

·       T1.2 IoT6 architecture design: based on T1.1, this task will design and describe the IoT6 IPv6-based service- oriented architecture to be developed in order to enable the integration and interaction among various components of the Internet of Things, and their integration with cloud computing applications (Software as a Service) and business processes management tools. It should tend towards a unifying (or integrating) framework over-coming the current heterogeneity and fragmentation of the Internet of Things. It will serve as a common reference document for the other WP developments, as well as for the dissemination work. This task will take into account the work developed by other research projects from the IERC cluster.

During the first 6 months of the project the focus of the activities was on T1.1, i.e. definition of use cases and derivation of the requirements. The identified use cases, the high level requirements and a high level architecture were discussed with the IIAB and their feedback used to update relevant outputs.

Based on the outputs of T1.1 (identified use cases and the requirements) and taking into account the existing state of the art in terms of IoT architectures, during the second 6 months the focus of the project was on definition of the initial IoT6 architecture. This was done in collaboration with all technical work packages to ensure relevance of the output for all technical items. The work done in Year 1 is documented in deliverables D1.1 and D1.2.

The initial architecture defined at the end of Year 1 was used during the second year to drive and guide research in other work packages. At the same time, using the outputs of other work packages, the initial architecture was further detailed and updated. At that time an early specification of the IoT-A architecture reference model [1] was released. As one of the main premises of the project in regard to architecture design was to build on the work of other projects and reuse the outputs where relevant, the initial comparison and mapping of the IoT6 architecture to IoT ARM was done. This enabled us to align the terminology and the functionality of IoT6 architecture with the one recommended by the IoT ARM. The work done in Year 2 is documented in D1.3.

In the final year of the project the focus of the activities was on finalization of the IoT6 architecture using the IoT ARM as the main reference point. In this period we went through the process described by IoT ARM methodology in order to produce IoT6 architecture as much compliant with the IoT ARM as possible, given the work already done in the project. We selected one use case from WP7 and analyzed it according to the methodology defined by IoT ARM. Based on this analysis we updated IoT6 architecture and aligned it with the IoT ARM thus giving opportunity to other projects to easily identify the additional components introduced by IoT6 project due to specific requirements and focus on IPv6 as well as to reuse it in their projects if applicable. The work done in Year 3 is documented in deliverable D1.4.

1.2        Achievements in the WP2

The achievements of WP2 greatly exceeded the a priori expectations. There was, however, a problem. The DoW was written to explore the potential of IPv6 from the viewpoint of a network stack. The WP was to investigate advanced features and to produce a network IPv6 stack incorporating these features - and to incorporate security, scalability, performance and self-healing. The problem was that some of these features depended not so much on the stack as on the interaction between entities, many were dependent on the operating system used, and some even on the hardware. Moreover many of the protocols were standardised in other bodies; this did not impact our using them, but did impact timing. If the aim was only to provide a stack that could be used by other WPs, it had to be frozen by the end of year 2; the other WPs could not cope with a stack that changed during the integration phase and while preparing the demonstration. In order to resolve this dilemma, we developed a stack as required and froze it at the end of year 2. The stack worked with Linux for gateways and Contiki for small devices, and supported 6LoWPAN, RPL routing and all other IPv6 advanced features – to the level available by the third quarter of the second year. This stack was delivered to WP3 and hence the other WPs on schedule. All this work was discussed in detail in D2.3. During the third year there were detailed experiences recorded on the performance of this stack, and reported in D2.4. In particular, while Contiki was the agreed choice of OS, several advanced IoT6 features that had to do with security (DTLS messages between embedded devices and between devices and gateways) required larger amounts of memory to be implemented.

Another important IoT-specific feature that was developed was GLoWBAL. This was an algorithmic mechanism for assigning IPv6 addresses to devices that might be accessible only through IP-enabled gateways, and had features understood only by a legacy technology. This mechanism was clearly very important as an enabler of large-scale deployment. Its utility was greatly enhanced by features developed in WP3 based on the Digcovery repository. It was included in the stack delivered to the partners.

Another aspect of WP2 was to be an investigation of how to provide security.  While we showed that the popular encryption algorithms could be implemented on small devices, the provision of real security required a complete security infrastructure which was not really part of WP2, and whose provision had not been budgeted. Moreover we had envisaged smart routing to be a feature that would be implemented at the network level. In practice this use of the IP header had been deprecated at that level in the Standards Body (IETF), so we agreed to provide it at a service level under WP3. As a result partly of the Reviewers’ comments, we re-visited the stack to incorporate datagram security DTLS with the latest versions of both the operating system Contiki, a compatible version on Linux, and the latest versions of the transport protocol CoAP adopted in the project. The implementations of the security features were found to be platform-dependent in terms of memory requirements, and could not operate on the specific constrained platforms used by the partners in the main demonstrations, which by nature would utilise more application layer resources – even though all other aspects could be identical. For this reason we decided to validate the implementations only in another set of demonstrations, which simplify the application layer in order to shift available memory towards the secure datagram layer below the application/CoAP layer. It was pursued further with much more advanced features that were incorporated into a complete validation demonstration – but not that of one involving the majority of the partners.

Having fulfilled all the other requirements of the other WPs by the end of year 2, we moved to a very promising set of activities in year 3. We had come to the conclusion that the use of identifiers was a logical, and much more powerful, extension of the ideas demonstrated in GLoWBAL. Moreover, we found the Handle system from CNRI that incorporated all the features of real security we required and could be directly combined with all the requisite features. This system was already deployed for other application domains, incorporated a strong security infrastructure and had proven scalability capability. CNRI ensured by request of IoT6 that their system would both operate with IPv6 features and be IPv6 addressable. Moreover, they were developing a new Release, which would incorporate RESTful programming mechanisms that are central to the IoT6 approach – and promised to give us a pre-release version of their new system before the end of the 3rd year. An important advantage of this approach is the way that IPv6 addresses, Internet services and GLoWBAL interwork. IPv6 addresses are usually stored in the DNS, and this is a key feature of our WP3 approach. Anyone can access the DNS, and hence inspect the IPv6 addresses – which under GLoWBAL may reveal features of the target subsystems. With Handle, such access is restricted to authorised users – with a sophisticated and fine-scale authorisation. Thus by using Handle we have been able to demonstrate it in a Use Case that is a subset of the main one in the project – but with secured, deployable and scalable features.

The main additional problem that this approach raised was managerial, not technical. Going from the network service to a complete validation required activity that should really have fitted at least into WP1, WP3 and WP7. The reporting in WP1 was straightforward; there were substantial contributions to D1.4 which included portions on scalability, governance and security. However, the duration of WP3 was scheduled to end in January 2014, and the Deliverable contents in WP2 and WP7 had been worded slightly differently. We decided, therefore, to describe our approach to the first problem to the Reviewers at the end of year 2 and received their approval. When considering how to report the validation, we determined that the description of the approach would be reported in D2.4, but that D5.4 in WP5 was a much more natural home for the detailed treatment of the Use Case – even though the work was validation. However the validation effort was charged to the WP7 where it belongs technically. In addition, this work has been widely disseminated in talks, papers and the relevant EC body considering standardization in IoT.

1.3        Achievements in the WP3

In this WP we research and develop a service layer enabling the interaction with different kind of Internet of Things components. We will propose an architecture and middleware for the scalable integration of actuators and sensors in a network of ubiquitous sensing. The objective is to define mechanisms to support the search for effective service layer for the sharing of sensor and other smart things information in real time, search and browse, as well as the discovery of resources and information in a distributed and loosely coupled approach.

•        Task 3.1 : Overlay Service layer: Look up and discovery, context-awareness and resource repository: Within this task a lightweight multicast DNS (lmDNS) for IPv6-enabled Smart Objects, in order to overcome of the limitations of mDNS due it is designed for host-based requirements, where they are not taking into account the design issues and constraints from Smart Objects. As a consequence this work converge to a global discovery architecture interoperable with DNS called digcovery and accessible via www.digcovery.net. Individual drivers have been designed to interconnect different kinds of objects, things, devices, sensors and tags (RFID, Handle System, legacy technologies, etc.) Finally, a search engine, an access control policies, and a set of management functions are proposed.  All these elements contribute towards the key purpose in the IoT6 project, to build an Open Service Layer which makes feasible its full integration into IPv6 architecture through protocols such as DNS, and other communication interfaces which define the Open Service Layer. Finally also as part of this task Local and Global Discovery interactions based on mDNS/DNS-SD and overlay networking solution has been analyzed and how to publish/search globally the resources and devices at registered at local level.

•        Task 3.2 - : Smart routing mechanisms: Within this period task 3.2 has concluded it work providing deliverable D3.2 on Smart routing. Two main solutions has been investigated and some initial testing of the solution has been carried out with the gateways in order to support the traffic differentiation from the IPv6 sensor nodes to a multicast/anycast address on the IPv6 intranet.

•        Task 3.3 - : Service layer implementation and tests: Within this period this task  has been working in the integration of the initial design and solution under the OSGi framework to provide a common API to be used within WP3-WP6 validation. Also the Java OSGi bundles have been extended to support some of the WP2 functionalities. Initial validation by means of the component interactions at WP7 has started. The IoT6 Stack has been performed in four environments: Contiki-motes, OSGi-Gateway, Digcovery-server and Mobile-phone. These implementations provide the functionalities of IPv6 connectivity and open service layer defined in WP2/WP3, respectively. Both implementations support the IoT6 interoperability in heterogeneous networks such wireless sensor devices or legacy technologies (BACnet and KNX). These implementations are divided into several modules according to their functionalities: IPv6 Addressing, Quality-of-Service, Service Discovery and Web Services, etc. The validation has been done in relation to the use case and interaction with the rest of the IoT6 components

Main outcomes:

•        Stable IoT6 stack platform based on:

o   OSGi and Contiki components deployed and tested by other WP

o   DigCovery platform allows registration and homogeneous access to the information provided by sensors or other devices.

o   Providing context awareness with the aid of MongoDB.

o   DigCovery makes use of enabling IPv6 QoS to control its own traffic.

·       IoT6 Open Service Layer enables that Smart objects can be discoverable, accessible, available, usable, and interoperable through IPv6 technologies like:

o   Lightweight multicast DNS (lmDNS) for local discovery in IPv6-enabled Smart Objects

o   Digcovery for scalable global discovery architecture interoperable with DNS-SD directories

o   Common description based on ontologies (SSN) and profiles (IPSO)

o   Elastic Search for look-up and context-awareness queries

1.4        Achievements in the WP4

The main target of this Work Package is to bring non-IP based communication systems and mainly the Building Automation Systems (BAS) from their close domains toward the IPv6 world. All the efforts in this WP have been focused on this problem.

The first step has been to understand the architecture of the system that could support the integration of BAS within the Internet. To this end, we have reviewed the main existing building automation protocols, in order to choose the ones to take into account in the design of the architecture and to understand their main features and the constraints that they impose on the architecture itself.

In a second phase, we focused on the high level design of the architecture, choosing among available frameworks and components, with the goal of guaranteeing a seamless integration and management between all the protocols considered. Two different approaches were considered. A first approach has been based on enriching the Universal Device Gateway (UDG)[1]  with the characteristics needed to satisfy the requirements defined in the work package. A second approach we considered was based on creating a BAS gateway using a generic semantics exploiting a standardised Information Exchange mechanism[2].  This last approach has led to the creation of the IoTSyS integration middleware[3].

When the two systems, UDG and IoTSyS, were built, the partners collaborated together to integrate them. This task was performed in order to demonstrate that the Control and Monitoring System (CMS) developed within UDG could work with different kinds of gateways despite using different semantics to manage devices from different technologies. The integration of these two systems ensured the satisfaction of the requirements in the WP4 directives on the integration of different legacy technologies.

A lot of efforts were made on the implementation of the CMS, improving its previous architecture in order to allow its usage into the scenarios envisaged within this project. This is a list of features added to CMS during these 3 years: capabilities to manage Virtual Variables, Dynamic Targets and Groups of Devices; creation of an IPv6 mapping to non-IP protocols [4] (proposed as Standard) that allows the automatic assignment of a unique IPv6 address to each legacy devices living under the CMS; the capability to distribute the intelligence (logic that is defined within the CMS) among different nodes, thus increasing the scalability; a novel Graphical User Interface (GUI) that allows to configure easily the devices and to design the scenarios desired using all new features introduces (this GUI is now available for both Computers, Mobile Devices and Tablets).

The next step was to integrate the CMS and the two gateways (IoTSyS and UDG) into the IoT6 ecosystem. This task has been performed by using the IoT6 Stack, which has been designed to allow all the IoT6 Components to work together, enabling more complex and fascinating scenarios (as will be shown in the third year’s demo).

Lastly, we performed a study about different schemes for Machine-to-Machine (specifically Device-to-Device) interactions, in order to understand their main features and their differences, and to figure out which one fits the context of this European Project. The outcome of this study has been documented in the Deliverable 4.4.

1.5        Achievements in the WP5

Work Package 5 (WP5, `Smart board and intelligence distribution') is aimed at integrating the concepts that have been developed within work packages WP2, WP3 and WP4. Main concern was to implement and to test the intelligence distribution tools and some specific routing and security mechanisms dealing with a complex ecosystem of heterogeneous components and heterogeneous applications and services. 

The very first aim of WP5 was to design an embedded board (“Smart board”) offering multiple physical interfaces and supporting translation protocols able to integrate legacy devices within IPv6 networks. This embedded board was aimed at providing the different research teams with the same generic compact system able to cope with heterogeneous devices, networks and protocols such as found in building automation systems (BAS).

Part of the challenge in designing that board was to ensure a large spectrum of physical accesses compatible with the numerous D1.1 use-case scenarios and a modularity allowing rational use of components for different deployment scenarios. The hardware components and part of the firmware were developed in task T5.1 (deliverables D5.1 and D5.2).

The multi-protocol integration, i.e. the implementation of the IoTSys architecture (designed in WP4), and its deployment on the Smart Board has been carried out in task 5.2 (main results described in D4.3). The multi-protocol interoperability has been realised by using the OSGI framework through the development of a set of protocol bundles associated to the main BAS technologies (KNX, Bacnet, M-Bus, En-Ocean, RF-ID, ZigBee). The protocol bundles have been deployed on the smart board, providing together with the gateway components a light-weight access to the heterogeneous technologies through the IoT6 stack.

A dedicated software application hosting the IoTSys as well as the Smart Routing components have been developed in order to handle the configuration of those components at launch (IoT6 Launcher).

The distribution of intelligence (such as studied in WP4, D4.2) was ensured by integrating the smart board software components into the frame of the IoT6-based CMS, (UDG). IoT6-based monitoring functionalities such as resource discovery (based on the Digcovery studied in D3.1) and Smart Things Information Service (STIS) have been implemented as well as powerful and flexible mechanisms providing dynamic control rules (D4.2). Those UDG flexible mechanisms may be deployed in a multi-stage, hierarchical configuration and are therefore adaptable to a wide variety of control loops, from lowest-level, direct control of an actuator set point, to high-level control like keeping a room with all its various properties in the comfort zone set by the user.

The content-based `Smart Routing' mechanism designed in D3.2 was implemented within the IoTsys middleware in order to improve the routing capabilities, allowing more efficient routing of sensor values.

Having implemented such a powerful IoT6 architecture with a plurality of actors/components it remained to find a coherent way to challenge and test the implementation. This quite difficult task was the subject of T5.3 and was carried out by taking into account the results of D7.1 which provided a general framework (abstract architecture) for each use case scenario planned in D1.1. Test cases were performed in order to evaluate the “Smart routing” and QoS features enabled by the Smart Board. The test cases showed how the Smart Board manages reliability of the data flows between the heterogeneous devices (IP sensors and Legacy actuators) and various control systems such as CMS, Safety Server and SaaS. The evaluation results have shown that all test cases are well completed and the smart routing and QoS mechanisms have been implemented successfully in order to achieve intelligence distribution among heterogeneous IoT devices and control systems.

Last but not least, WP5 (in line with D2.4 findings) proposes an original way to provide security operations such as authentication, authorisation, confidentiality and integrity using distributed elements based on the HANDLE system (HS) and DTLS cipher suite. Several use cases are proposed for the validation of security activities in the final demonstration of the IoT6 project. Although the application of a strict security policy through the deployment of a security infrastructure is way beyond the scope of the IoT6 project, the Handle System provides most of the technology needed to incorporate a credible measure of security into the sort of Use Cases we are studying in IoT6. The security proposal of the HANDLE system has shown that this approach could have impact on IoT far beyond IoT6.

1.6        Achievements in the WP6

This work package focused on the research challenges related to the integration of IoT6 with main stream applications such as business processes applications using the cloud computing platform of software as a service (SaaS), mobile network, and smart thing information service (STIS).

In order for IoT6 to be interoperable with STIS, analysis on unique identifiers are necessary because STIS has its own identification system, and it should be interoperable with that of IoT6, namely IPv6. Deliverable 6.1 reports on unique identifier analysis and integration of IoT6 with STIS, and ONS. We analyzed various unique identifiers such as Uniform Resource Identifier (URI), handle system micro ID (uID), Object Identifier (OID), Universally Unique Identifier (UUID), and Electronic Product Code (EPC), etc. Among them, we conclude that URI could be desirable for the identifier to enable interoperation among heterogeneous identifiers. In deliverable 6.3, the interoperability test was performed to verify IoT6’s interoperability with STIS, and its result was presented. The tests include unit tests for each interface as well as integration tests between IoT6, STIS, and ONS. It showed the feasibility of design and implementation of integrated system. Finally, it tested and presented the result of the proposed unique identifier implementation in the frame of IoT6 architecture. In deliverable 6.4, IEEE 802.15.4-based active RFID tags with STID is introduced as innovative interactions between STIS and IPv6. To enable interaction between these smart things and STIS, 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) is employed as a vehicle to integrate non-IP-based smart things with STIS. As a result, coverage of IEEE 802.15.4-based active RFID networks can be easily extended with the aid of 6LoWPAN networks, which is called 6LoWPAN-based active RFID networks. Also, by integrating 6LoWPAN gateway with LLRP (Low-level Reader Protocol) readers, smart things and STIS can communicate with each other without any modification to each other through 6LoWPAN-based active RFID networks.

For the interoperability of IoT6 with mobile network, the requirements were proposed: Task 6.1 has the goal to propose the best option to implement and test the above mentioned forms of interactions between mobile phones and IoT6. Deliverable 6.2 analyzed the registration procedure, addressing of mobile devices, and mobile devices acting as a gateways and half gateways in IoT6. It also explored various ways to integrate an IPv6-based Internet of Things into mobile phone networks enabling mobile devices to provide access to smart objects as well as to use mobile devices as sensors/actuators. As well as, for the ISPs not supporting IPv6, tunneling mechanism was used. An ability for smartphone sensor discovery and data gathering is presented, and possible options for non-IP device are also discovered and contacted. Feasibility of mDNS implementation on a mobile phone was also studied.

For the interoperability of IoT6 with the business process management tool, CoAP protocol and JSON format should be supported. Deliverable 6.5 demonstrated the feasibility of interaction and a new kind of applications. As a result, RunMyProcess Business Process Management tool has been interfaced with the Internet of Things by adding new functionalities to allow CoAP connectors and the development of a CoAP proxy to make the platform visible by CoAP objects. As well as, it exposed a vision, made of interaction between SaaS applications, the Internet of Things and legacy web services, called `Composite Business Ecosystems for the Web of Everything`.

1.7       Achievements in the WP7

As a first action in this work package, the use cases shortly described in Deliverable 1.1 have been analysed and refined. It was thereby necessary to re-evaluate the mentioned components and how they fit with the final IoT6 architecture. To achieve this task, the use case descriptions have subsequently been completed and spread among the partners. Following, use cases, descriptions and sequence diagrams have been updated according to their input.

Furthermore, an interoperability testing strategy had to be chosen. Different testing strategies have been evaluated for testing the interoperability of the IoT6 architecture. Finally, the ETSI EG 202 237 guideline which is also the basis for the PROBE-IT EU FP7 project has been selected as suitable.

As a next and at the same time first step of the testing guideline, interface descriptions have been extracted from the use case descriptions and sequence diagrams. Afterwards, first drafts for test cases have been developed. Thus, deliverable D7.1 describes the scenarios and interfaces between components of the IoT6 compound. As it was created as a guideline to be used by the different partners to test the interoperability in the IoT6 architecture, additionally test groups and test purposes have been defined which may be seen as basis for the development of formal test cases. In further consequence, the main outcome of this deliverable is a set of test cases necessary to perform the interoperability tests.

The next task was the development of a concise test plan for the defined test process that can be used to test the interoperability of the IoT6 components. Therefore, the scenarios of the initial test strategy have been adapted to a consolidated “extended smart office use case” that has been agreed upon in the IoT6 consortium. In this case, the test cases originally defined in D7.1 have been adopted to reflect a scenario that involves all elements of the IoT6 architecture and allows a thorough interoperability test at the same time economically using available resources. In this context, so-called “abstract architectures” have been defined for all steps of the scenario detailing the test setup and allowing the identification of communication dependencies between components and partners. Following, a distributed test plan was worked out, and dependencies between the partners have been identified. The local test setups at the sites of the different involved partners were adapted accordingly to support the interoperability test procedure of this work package. Further, the additional equipment needed for the final demonstration was evaluated.

Finally, in the test execution phase, several iterations of testing sessions have been scheduled according to the test plan. These iterations have been performed in a way so that all involved partners were monitoring their systems and thus validating the correct execution of the agreed-upon extended use case. The coordination of the testing efforts included regular VoIP meetings (“test days”) on which the agreed-upon use case has been executed step-by-step by the responsible partners. For each test session it was documented how many test cases associated with the use case could be successfully validated. Further, in the event of unsuccessful test cases, the reason for their failing was logged for documentation in the deliverable D7.2. 

Apart from interoperability testing, the second main focus of the work package was to evaluate the scalability of the IoT6 architecture. Therefore, a proposal for a scalability testing methodology was prepared and presented. Different approaches for scalability assessment have been used to test the various components in the compound. In this case, components of the IoT6 architecture have been analysed based on benchmarks as working prototypes were available. The performed analysis clearly shows the limits of scalability depending on the used hardware resources.

All efforts regarding interoperability and scalability testing have been collected and documented in the final test report for this work package (D7.2). Within D7.3, the results of the deployment and tests of the IoT6 architecture and components in a real smart office environment are presented. Further, innovative future applications of the IoT6 architecture have been created and introduced thoroughly in D7.4.

1.8        Achievements in the WP8

The IoT6 consortium has been actively involved and taking leadership in chairing and organizing peer reviewed, well-known, international conferences as well as actively participating in standardisation efforts.

-        Dissemination activities summary (see more details in D8.2.x)

o   Leadership in IoT Forum and IoT Week

o   Leadership in IEEE ComSoC IoT subcommittee

o   Leadership in IPv6 Forum to organise IoT6 panels

o   Organised directly over one dozen conferences

-  3 IoT Week events

-  4 IEEE ComSoc IoT events

-  2 IPv6 Forum panels

-  3 esIoT workshops

o   Participated in 100 partners and industry conferences

o   Authored more than 3 dozen papers, including in

-  3 IERC Books

-  IEEE ComSoc papers

o   Authored the SME handbook

o   IoT6 web site

-        Standardisation activities

The IoT6 consortium has also approached the industrial community and put effort to spread the knowledge and project achievements through the standardization bodies (IETF, ETSI and ITU-T) as they attract the leading industry players: IETF attracts some 1000 experts and ETSI has some 600 industry members. IoT6 sought to interest the industry with the project solutions and impact the standardization process (mainly in the IETF 6LoWPAN, 6lo and 6TiSCH and ETSI ISG).

o   Co-authored the standardisation chapter in the IERC Book – led by ETSI

o   Formed an ETSI Industry Specification Group for IPv6 and IoT

-        Exploitation

The IoT6 consortium focused exploitation activities on interaction with the SMEs and IoT industrial sector. The planned activities are organized in 2 strands:

o   Organization of dedicated events for presentation and promotion of the benefits and advantages of IPv6 based IoT solutions, focused on events targeting SMEs and IoT industrial sector players.

See more details in D8.4.x

 

o   Preparation of promotional material, including professionally designed content, aimed at researchers and industry, with specific focus on SMEs.:

 

-  A series of A1 size posters providing an overview of the project and the main outcomes

-  SME book, providing a description of the main outcomes of the projects

-  Short version of the SME book: a 10 page leaflet providing a summary of the full SME book

-  IoT6 comic poster and leaflet

-  IoT6 gadgets: in collaboration with a marketing company, a set of promotional gadgets such as postcards are created including Augmented Reality (AR)

o   A three portable IoT6 demo setups were created to enable easy demonstration of the main project concepts and outcomes.

-  TUV portable suitcase

-  Demonstration at the FIA conference

-  Demonstration at the ICT Spring conference

o   Contribution to creation of the IEEE ComSoc technical working group on Internet of Things (IoT) that has been created in November 2012. The group is chaired by Latif Ladid (UL), and vice-chaired by: Antonio Jara (HESSO), Antonio Skarmeta (UMU) and Sebastien Ziegler (MI).

o   Partners’ individual exploitation plans are given. Plan contains a short description of each partner and their interests, as well as the opportunities each partner sees for exploiting the results developed within the project. See more details in D8.4.x

2         Standardisation Efforts

Following the recommendations of the reviewers from the second review to take a strong step in getting the findings and results out to industry and major stakeholders, this Deliverable describes the new initiatives undertaken in Y3 by the IoT6 project partners for the standardisation and awareness creation during and beyond the life-time of the project.

The IoT6 project partners did not spare any effort to make coalitions and partnerships and took convincing stances and positive energy and attitude to win STD influencers and key industry advocates to endorse the mature results of the project and spread them for adoption.

The IoT6 project has been very fortunate in participating directly and leading some initiatives in the strategic standardisation bodies such ETSI, the IETF, ITU and IEEE ComSoc and standards influencing projects such as the IoT Forum and IERC Cluster. The embedding of ETSI in the IoT6 in the Industry Advisory board with one of its leaders proved to be of strategic value which lead to credible and influencing recommendations and acceptance of the IoT6 results.

The creation of the ETSI IP6 ISG and the IEEE ComSoc IoT/5G/SDN-NFV as well as the IoT Forum and IERC will contribute to the dissemination of best practices beyond the project lifetime with a strategic sustainability vision also beyond IoT including pre-standardisation efforts of IoT or MTC for 5G networks.

Some achievements with lasting impacts in this area are:

·       Leading the adoption of IPv6 as key communication protocol

·       Winning ETSI’s support to lead the ETSI IP6 ISG

·       Leading the IoT Forum

·       Leading the IEEE ComSoc IoT subcommittee

·       Contributing to the IoT Book for the 4th time

·       Leading the IoT Week program

·       Chairing many conferences and invited as speakers in standardisation

3         Overall Impact

 “By the year 2020 there will be one billion computers, 5 billion users of mobile communication systems, ten billion appliances, one hundred billion sensors, and one billion billion electronic tags, most of them Internet-enabled. Getting it right means a huge economic potential. Getting it wrong would be catastrophic.”

Viviane Reding, European Commissioner

 

This is to summarise how IoT6 addressed the expected impacts listed in the call:

Impact 1: IoT6 has opened a new range of Internet enabled services based on truly Inter-connected physical and virtual objects, person to object and object to object communication as well as their integration with enterprise business processes.

IoT6 has truly paved the way to a new range of Internet enabled services and their integration with enterprise business processes by enabling integration of cloud computing, heterogeneous devices, mobile phones networks and STIS. IoT6 has defined open architecture leveraging the capacity of IPv6 to provide ubiquitous access and seamless communication among a large population of mobile and networked smart objects located in diverse geographical locations thus enabling a cost effective integration and interoperability of heterogeneous smart things and systems. Integration of the Internet of Things with cloud computing will be enabled through software as a service (SaaS), such as enterprise business process management tools. A multi-protocol translation web service providing interoperability among heterogeneous smart things and systems using different communication protocols as well as IPv6 proxy services for legacy devices to ease their integration into the future Internet will be developed. IoT6 will provide STIS-IPv6 integration, thus enabling a global addressing scheme for STID & IPv6 as well as mechanisms for address registration and update, and sensor information exchange between IoT6 and STIS. Integration with mobile networks will be achieved through interfaces such as IMS.

The extension to the use of an IPv6-enabled Digital Object Architecture will allow secure description of the heterogeneous objects and processes that transcends the network address space. The secure linkage of identifiers with IPv6 addresses and security tokens will greatly facilitate multiple stakeholders to provide independent services to common IoT sensors and actuators. It will also ease the problems of IoT governance. It divorcies the management of the Internet IPv6 address space from the Identifier space. This will allow new Stakeholders, including complete industries, to manage their identifier space without impacting the management of the Internet.

Impact 2: Novel business models based on object connectivity and supporting innovative Internet services.

IoT6 developed an open service oriented architecture easing the integration of different products and services through the Internet. It interconnects the Internet of Things with the Internet of Services through IPv6. It paves the way to innovative ecosystems of companies, enabling the aggregation of complementary products and services from different companies in order to provide ad hoc solutions to the customers. It has instigated the creation of new business opportunities and revenue generating business models, stemming from the ability to structure ad-hoc platforms of heterogeneous products. These business models involve new roles and stakeholders, such as “solution brokers”, who will provide ad hoc combination of resources and services. In order to evaluate this approach, several business scenarios will be evaluated within the project that will be clearly linked with Future Internet priorities areas like intelligent buildings. For instance, an on-line maintenance management tool will enable new maintenance services for building automation components particularly relevant for building and construction industry, including some members of the IAB.

Impact 3: Emergence and growth of new companies, in particular SMEs, offering innovative technical solutions for making everyday objects readable, recognizable, locatable, addressable and/or controllable via the Internet.

IoT6 provided a handbook targeting SMEs to support their exploitation of IoT6 outputs as well as transition to IPv6. IoT6 has directly supported two emerging SMEs:

RunMyProcess and a spin-off company of the national UDG project. More generally, it facilitates in a sense the entry for new SMEs, by enabling them to integrate specific solutions with other solutions through an open framework. The focus on smart buildings paved the way to innovative technical solutions with huge business opportunities for companies who can offer flexible and secure solution to the users. The project has instead of initiating an alliance to support the development and dissemination of IoT6 architecture; it has taken leadership of IoT Forum and is the leader of the IPv6 Forum.

These channels enable direct support to the dissemination and adoption of IoT6 results by industries and SMEs.

Impact 4: Consensus by industry on the need (or not) for particular standards. More widely accepted benchmarks. Consensus by all stakeholders on the governance of the "Internet of Things" including key management aspects.

IoT6 is closely linked with major industries, international forums, standardization bodies and other research projects with a European and international perspective. IoT6 is in very good position to align and contribute to the consensus by industry and other stakeholders on the need and critical use of IPv6 for the Internet of Things, with a proposed open and decentralized service-oriented architecture.

 

4.    Conclusions

The IoT6 project is very pleased to state that it has achieved its very well outlined objectives, work plan and overall impact right from the outset to the end with very impactful sustainability initiatives. The project has justified all the statements below in its Deliverables, and demonstrated specific subsets in its applications and demonstrations.

The IoT6 project has:

·       Researched and exploited the rich features of IPv6 and related standards (6LoWPAN, CORE, CoAP, DTLS etc.) to support the future Internet of Things by developing a layer enabling IPv6 features (such as discovery, self-configuration, security, scalability, multiple addresses for an object, ubiquitous access, etc.) to be exploited by the service layer.

·       Researched, designed and developed an open and distributed IPv6-based Service-Oriented Architecture enabling interoperability, mobility, cloud computing and intelligence distribution among heterogeneous smart things components, applications and services.

·       Used this IPv6-based architecture to develop innovative forms of interactions for the Internet of Things with:

a) Heterogeneous devices using different communication protocols (including legacy devices), by exploring innovative schemes for achieving multi-protocol integration and interoperability.

b) Integration with Mobile telephone networks to provide ubiquitous access and seamless communication among a large population of mobile and networked smart objects located in diverse geographical locations, with solutions such as IP Multimedia Subsystem (IMS) and the Mobile Internet Protocols.

c) Cloud computing applications and services (Software as a Service), including business process management tools.

d) Smart Thing Information Service (STIS), exploring STID-IPv6 interactions and possible adaptation and extension of STIS to any IPv6 device.

e) Information and intelligence distribution with “Distributed resource repositories” (for look-up and discovery services) and “Smart routing”.

·       The above features can be extended for increased IoT governance, deployability, security, flexibility and scalability by suitable integration with a system like Handle. The detailed justification is given in D1.4.

 

References

[1] Internet of Things Architecture, IoT-A: Final Architectural Reference Model for the IoT, http://www.iot-a.eu/public/public-documents/d1.5/view

 

 

   


[4] http://datatracker.ietf.org/doc/draft-rizzo-6lo-6legacy/