Mapping of tech landscape to IoT approaches

From Web of Things Interest Group
Jump to: navigation, search

Below we analyze which TF-AP relevant topics are addressed in what way by related IoT consortia, initiatives, and working groups.

Consortium Focus Domain Model for "Things" Protocol mapping Resource structure / web API Client-side scripting API to acces remote things Server-side API to create/expose things Additional, platform specific findings of interest for this landscape
IETF CoRE (Carsten?, Mattias?) all  ?  ?  ?  ?  ?  ?
OMA (Mohammed Dadas / Orange (Johannes to outreach), bryant sullivan / AT & T?) all  ?  ?  ?  ?  ?  ?
OIC (Kaz to outreach : Daniel Park, Michael Koster) all  ?  ?  ?  ?  ?  ?
Allseen Alliance smart home Yes. See https://allseenalliance.org/framework/documentation/learn/core. Application exposes its services through a "BusObject" defining a set of interfaces, where each interface defines a set of Methods, Properties, and Signals (Events). Interface descriptions are XML-documents: https://allseenalliance.org/framework/documentation/learn/core/about-announcement/interface AllSeen is an application layer concept that is tranport layer agnostic. Today mapping to TCP/IP and UDP/IP over WiFi, WiFi-Direct, Ethernet and PLC. Mapping to non-IP transports, e.g. Bluetooth LE, ZigBee or Z–Wave can be added. See https://allseenalliance.org/framework/documentation/learn/core/system-description/alljoyn-transport AllSeen is not web focused. Applications are written in C, C++, Obj-C, Java etc but it is probably possible to give access for web apps to an AllJoyn network through an AllSeen Gateway Agent. APIs are exposed in different native languages. See https://allseenalliance.org/framework/documentation/develop/api-reference APIs are exposed in different native languages For basics see https://allseenalliance.org/framework/documentation/learn/architecture

https://allseenalliance.org/framework/documentation/learn/core/system-description https://allseenalliance.org/framework/documentation/learn

IPSO Alliance (Michael Koster) all  ?  ?  ?  ?  ?  ?
oneM2M (Soumya to outreach: Martin Bauer,Omar.) telecomunication  ?  ?  ?  ?  ?  ?
Hyper/Cat (TF-DI? -> Soumya) smart cities  ?  ?  ?  ?  ?  ?
Open Group (Dave to outreach)  ?  ?  ?  ?  ?  ?  ?
OGC SWE (discuss with TD if AP are there) smart cities, environmental monitoring  ?  ?  ?  ?  ?  ?
ECHONET Consortium (Naka-san, Kajimoto-san) smart home and small commercial building ECHONET device object, which expresses device/equipment functions as properties of each device class (e.g. LED Light or air-conditioner) with configurable values for properties. See http://echonet.jp/spec_object_rf_en/ No transmission layer is defined. ECHONET can be utilized on top of any types of network layer protocol (e.g. IPv4 or IPv6) and any types of transmission layer protocol (e.g. Ethernet or wireless technologies) Web API is not defined in ECHONET Lite specification Client-side scripting API is not defined in ECHONET Lite specification Server-side scripting API is not defined in ECHONET Lite specification Get, set and notify command is specified as binary ESV (ECHONET Lite Service) code embedded in ECHONET Lite frame. (http://echonet.jp/wp/wp-content/uploads/pdf/General/Standard/Echonet_lite_V1_11_en/ECHONET-Lite_Ver.1.11(02)_E.pdf) For overall ECHONET Lite spec. , see http://echonet.jp/spec_v111_lite_en/
Thread Group smart home No, Thread is a mesh network technology for connected things in the home. No application layer is defined. The Thread stack consists of: UDP + DTLS/ Distance Vector Routing/ IPv6 / 6LoWPAN/ IEEE 802.15.4 MAC Not defined Not defined Not defined Thread White Paper