Mapping of tech landscape to IoT approaches
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 |