November 12, 2015 - Habib Virji
The Layered Architecture of IoTivity
This article is part 2 of a 4 part series on how IoTivity handles security for the connected IoT world.
IoTivity is an implementation of the OIC standard. In part one of this series, I covered the how the client and server model is used to establish connectivity. The server hosts resources and the client finds and controls resources. Each resource is represented by a type that is standardized by the OIC and includes details such as addresses and access control policies.
IoTivity has a layered architecture where each layer performs different functionality. This article will cover each of these layers.
IoTivity supports Bluetooth Low Energy using GATT, Bluetooth EDR (Enhanced Data Rate) using RFCOMM, Dual IPv4/v6 stack, and XMPP (remote access connectivity). All of the details for each of these bearers is hidden in the connectivity abstraction layer. The IoTivity stack has support for these bearers built in by default, and support for other protocols can be added via primitive services.
The Connectivity Abstraction layer provides a common platform for all bearers, and it exposes functionality that is supported by all of them, it includes the following functionality:
- Transport-specific functionality that’s specific to to each bearer.
- Listen server to receive multicast packets for resource discovery. It also includes functionality to stop receiving resource discovery requests. Low-power devices can use this to publish their resources to a resource directory and avoid participating in active discovery to save energy.
- Send functionality for direct communication with other devices and communication across the network.
- Read functionality to get data through network interfaces.
- Specific network information, like addresses of the interfaces.
IoTivity security is provided at two layers: transport and application. The transport layer improves security through the encryption of packets. IoTivity security relies on DTLS (Datagram Transport Layer Security) to provide packet to packet encryption. The application layer provides security through the use of an Access Control List (ACL) to control access to resources. DTLS encryption is facilitated during the device onboarding and provisioning process, and the ACL is referred to when a device is first brought on to a network.
OIC representation and payload are defined in the C Stack. It contains the main functionality of IoTivity and is capable of communicating directly with the security and connectivity abstraction layers.
Payload handling is carried out via Concise Binary Object Representation – CBOR (RFC 7049). The advantage with the CBOR is that it does not require the encoding of binary data as base64; instead, it’s possible to send data directly in binary format. It can handle all JSON-related data.
The protocol used in this layer is the Constrained Application Protocol – CoAP (RFC 7252). Much like HTTP, CoAP is based on the REST model, where a device hosts resources and makes them available under a URL. Devices intending to connect to these resources can find interface information to connect and perform control operations. CoAP provides a smaller header than the HTTP protocol, and can work on devices with as little as 10 KiB of RAM and 100 KiB of storage space. OIC uses CoAP to define how to represent interfaces and make them interoperable between devices.
This is a thin layer that exposes the C stack API to other modules. It is intended for the server and clients to use this API to write the IoT application on top of the C stack. The C++ API is intended to be used primarily on higher-end client devices such as mobile phones. The C++ API is used to write IoT applications for the user to interact with. All of the client-side communication is defined in the C++ API.
The primitive services layer provides multiple functionalities on top of the C++ API. These modules are not mandatory and can be used as they are needed by applications. This includes:
- Resource Container/Builder – Creates a server and handles resources.
- Resource Directory – Holds resource information for thin devices and respond to the discovery response on behalf of these devices.
- Resource Hosting – Provides similar functionality to resource directory, but also provides functionality to host the resource on behalf of the thin client.
- Easy Setup – Allows devices to be enrolled to the user network.
- Simulator – Helps simulate server and client functionality without need of real hardware.
- Things Manager – Allows addressing multiple devices simultaneously.
- Resource Broker – Finds information about the resources and check the presence information of the resource server
- Resource Cache – Delivers the data of selected resources.
IoTivity is targeted for small constrained devices, and supporting multiple operating systems makes IoT development much more useful. The IoTivity server component is designed to run on small devices, while client applications can run on high end devices like tablets, mobiles phones, or televisions.
IoTivity currently support following platforms:
Widespread availability for users, coupled with an efficient platform for connecting IoT devices makes IoTivity a strong candidate to run the future of smart, connected devices. Stay tuned for the next articles in this series!
About Habib Virji
Habib Virji is a Senior Software Engineer for the Samsung Open Source Group. He has contributed to many open source projects over the last 5 years including Webinos, an open source platform for secure communication between devices. Now, he is a committer for the Blink project and has contrbuted to areas including Keyboard Events, WebCrypto and HTML Forms; he is also a sub-maintainer for the device interoperability modules of the IoTivity Project.