Matthias KovatschResearch History & Career Background

Dr. Matthias KOVATSCHCitizen of Germany

Objective

Research and development in networked embedded systems, large-scale systems, and RESTful environments and building an Internet of Things (IoT) around them

Education

Dipl.-Ing. in Erlangen, Germany

Doctorate in Zurich, Switzerland

Erlangen

Dipl.-Ing. Oct 2003 – Nov 2008

Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany• Information and Communication Technologies (semesters 1 – 6)• Signals and Systems• Communications• Algorithms• Distributed Systems

• Systems of Information and Multimedia Technology (semesters 7 – 10)Elite graduate program of the Elite Network of Bavaria• Wireless Communication• Embedded Systems

• Thesis “Services for Wireless Sensor Networks”

Electrical Engineering (Dipl.-Ing. degree)

Computer Science

Individual Curriculum

Doctorate Mar 2009 – Mar 2015

ETH Zurich, Switzerland• Institute for Pervasive Computing / Distributed Systems Group• Wireless Sensor Networks (Contiki OS)• Seamless Internet connectivity (6LoWPAN)• A Web-like application layer for the Internet of Things (CoAP)

• Dissertation “Scalable Web Technology for the Internet of Things”

• Teaching responsibilities• Supervision of 20 bachelor and master students• Main teaching assistant for the Distributed Systems lecture

Professional Experience (selected)

• Freelance Web Developer, Germany• Custom online shop and content management systems for small businesses

• Fraunhofer IIS, Germany• Technical study of ZigBee and middleware for medical applications

• Siemens Pte Ltd, Singapore• Automated testing tools for SMT placement equipment via CAN bus

• SICS – Swedish ICT, Sweden• Protocol development for Contiki OS

• ETH Zurich, Switzerland• Publication of scientific articles, standard documents, and open source projects

Publications(selected)

Embedding Internet Technology for Home AutomationM Kovatsch, M Weiss, D GuinardEmerging Technologies and Factory Automation (ETFA), 2010A Low-Power CoAP for ContikiM Kovatsch, S Duquennoy, A DunkelsMobile Adhoc and Sensor Systems (MASS), 2011Moving Application Logic from the Firmware to the Cloud:Towards the Thin Server Architecture for the Internet of ThingsM Kovatsch, S Mayer, B OstermaierInnovative Mobile and Internet Services in UbiComp (IMIS), 2012Actinium: A RESTful Runtime Container forScriptable Internet of Things ApplicationsM Kovatsch, M Lanter, S DuquennoyInternet of Things (IoT), 2012CoAP for the Web of Things:From Tiny Resource-constrained Devices to the Web BrowserM KovatschWeb of Things (WoT), 2013Californium: Scalable Cloud Services for the Internet of Things with CoAPM Kovatsch, M Lanter, Z ShelbyInternet of Things (IoT), 2014

Google Scholar

Citation indices All Since 2010

Citations 424 421h-index 10 10i10-index 10 10

Open Source Projects

• Californium (Cf) CoAP framework• Java project for CoAP in unconstrained environments• Eclipse Foundation

• Erbium (Er) REST Engine• C project for Class 1 devices (~100 KiB ROM, ~10 KiB RAM)• Contiki OS

• Copper (Cu) CoAP user-agent• Mozilla Firefox add-on for user interaction, testing, debugging

• OMA LWM2M DevKit• Mozilla Firefox add-on for virtual LWM2M Clients (devices)

Standardization Activities

• Internet Engineering Task Force (IETF)• IoT-related working groups• Shepherd for draft-ietf-core-block

• European Telecommunication Standards Institute (ETSI)• IoT CoAP Plugtests• (involvement in TTA CoAP interop event in April 2015)

• World Wide Web Consortium (W3C)• Web of Things Interest Group (WoT IG)

• Open Mobile Alliance (OMA)• Collaboration with Joaquin Prado for improved openness• OMA LWM2M workshop and feedback on technical specification

Technical QuestionHow to get an interoperability between IoTivity andother IoT standards such as OneM2M and AllSeen?

Differentiation of Goals

• IoTivity/OIC device in other environments• Other devices in OIC environment• Mixed environments

• Small device• Powerful device

• Local communication• Cloud-based communication

Differentiation of IoT Standards

• Service layer specifications• OneM2M• IoT-A (EU project)

• Data model specifications• IPSO Objects• ZigBee Cluster Library*

• Device level specifications• OIC• OMA LWM2M• AllSeen• Bluetooth GAP/GATT

Provide bindings for multiple protocolsDefine their own mechanisms on topUsually introduce unmanageable complexity

Provide bindings for multiple protocolsReuse protocol mechanisms

Often include own data modelOften define own protocolUsually define the local environment

* for IP-based ZigBee solutions

Example Solution: OneM2M Binding Solution• Requirements• OneM2M “gives in”

• Advantages• No change in IoTivity• Working for all device classes

• Disadvantages• Forced into OneM2M architecture• Possibly limited OneM2M service functions• No direct device-to-device communication

Application-level Gateway

OneM2M API

App App App

OIC Devices

Example Solution: Additional IPSO Data Model• Requirements• IoTivity “gives in”

• Advantages• IPSO devices can use IoTivity devices• Re-use of code (CoAP stack)• No gateway or cloud service

• Disadvantages• IoTivity devices cannot use IPSO devices• IPSO functionality limited (e.g., no discovery)• Unclear security model• Slightly higher resource requirements on devices

Example Solution: AllSeen Plug-in

• Requirements• IoTivity “gives in”• Powerful device

• Advantages• No gateway or cloud service

• Disadvantages• Not possible for small devices• Possible IPR issues

Example Solution: BLE (GAP/GATT) Gateway• Requirements• Someone “gives in” (provides gateway)• Users buy additional hardware

• Advantages• No change in IoTivity• Working for all device classes• GATT to REST mapping application-agnostic

(if done correctly)

• Disadvantages• Gateway (could be part of high-end device)

BLE GatewayLWM2M Server with

OIC northbound interface

General Recommendations

• Reuse exiting open standards as far as possible• see Internet protocol suite (IP as narrow waist)• look for mechanisms instead of inventing them

• Keep core features lean• see Web architecture (REST constraints)• extend with plug-ins for special content (e.g., link to RTP for multimedia)

• Plan for (secure) software updates• see living standard in Web browsers (apply moderately in the IoT)• confirm specification with running code (good approach already in OIC)

Promising Future Solutions

• Progress in CoRE working group (Thing-to-Thing Research Group)• RESTful application templates (see draft-hartke-core-apps)

Common Internet Media Types derived from individual data models• e.g., SenML for accessing and understanding sensors

• IoTivity with text/plain sub-resources?• Split compound JSON data model into atomic resources

• OMA LWM2M with RESTful peer-to-peer support• Strict Object/Instance/Resource structure is modeled through Web Linking

Common set of link attributes describing resources serving text/plain