All News | Boards | Chips | Devices | Software | Archive | About | Contact | Subscribe
Follow LinuxGizmos:
Twitter Facebook Pinterest RSS feed
*   get email updates   *

How IoTivity plus AllJoyn could form a "best-of-breed" IoT framework

Aug 29, 2016 — by Eric Brown 2,657 views

IoTivity and AllJoyn have much in common, including the ability for devices to find and communicate with each other without requiring cloud services.

At the Embedded Linux Conference in April, Open Connectivity Foundation (OCF) Executive Director Mike Richmond concluded his keynote on the potential for interoperability between the OCF’s IoTivity IoT framework and the AllSeen Alliance’s AllJoyn spec by inviting to the stage Greg Burns, the chief architect of AllJoyn. Burns briefly shared his opinion that not only was there no major technical obstacle to combining these two major open source IoT specs, but that by taking the best of both standards, a hybrid could emerge that improves upon both.

Later in the day, Burns gave a technical overview of how such a hybrid could be crafted in “Evolving a Best-of-Breed IoT Framework.” (See video below.) Burns stated in both talks that his opinions in no way reflect the official position of OCF or the AllSeen Alliance. At the time of the ELC talk in April, Burns had recently left his job as VP of Engineering at Qualcomm and Chair of the Technical Steering Committee at the AllSeen Alliance to take on the position of Chief IoT Software Technologist in the Open Source Technology Center at Intel Corp.

Several of Burns’s proposed mergers of AllJoyn features are already being actively evaluated at IoTivity. Later this year, IoTivity 2.0 will introduce the first layer of compatibility with AllJoyn, and subsequent releases will likely include more AllJoyn-inspired changes. Also at ELC, Intel’s Vijay Kesavan, who is Chair of the Iotivity Security Task Group, gave an overview of IoTivity 2.0.


Shared strengths and interesting differences

In his presentation, Burns explained how IoTivity and AllJoyn have a lot in common. Similarities include standardized wire protocols, schema definitions, and data models, as well as an IP multicast based proximal discovery scheme that lets devices find and communicate each other without requiring a cloud service. Both frameworks also support transport and OS independence, as well as collaborative, open source development, he added.

Burns acknowledged that many of the terms and concepts used by the two frameworks are different. Yet, many of these concepts map directly, he added. For example, a URI in IoTivity translates into a “bus name plus object path” in AllJoyn. Similarly, an IoTivity resource is essentially an AllJoyn object, a collection is a child object, a link is a local object path, and an observe is an add-match. “I don’t really see the challenge in making these concepts look more similar,” said Burns.

There are also a few unique concepts on each side. Burns proposes using at least two of them: IoTivity’s “interface” and AllJoyn’s “resource introspection.”

Slides 1-6 of Burns’s presentation
(click images to enlarge; download the full pdf here)

In his presentation, Burns analyzed each major component, noting the pros and cons of each. Later he revisited the topics to propose how each might be merged, or in some cases, one approach might be used in place of the other. Here, we combine these observations, giving a birds-eye summary of the major points. The quotes indicate selected, edited comments approved by Burns.

  • Programming Model – IoTivity’s RESTful with Notify vs. AllJoyn’s D-Bus, RMI (remote message indication), and PubSub:

    “It honestly doesn’t really matter. Anything you can express in one, you can express in the other. So stick with RESTful. It works, and is broadly adopted. We’ve had trouble trying to get people to accept AllJoyn’s approach because it was unfamiliar. Engagement with groups like W3C are really valuable for any IoT standard, and a D-Bus architecture is a tough sell. It’s a battle that isn’t worth fighting.”

  • Schema – IoTivity’s JSON payload with CBOR binary serialization and RAML (RESTful API Modeling Language) vs. AllJoyn’s binary payload with XML and D-Bus serialization:

    “AllJoyn’s XML solution is based on D-Bus, but over time has become richer and more evolved than JSON. Because AllJoyn uses D-Bus type signatures, it’s more precise. JSON needs to be extended to specify exactly how data gets serialized by adding data types, which are extended notations to the schema specifically for code generation. Being able to automatically generate code from a data model is extraordinarily powerful.

    “We need unambiguous serialization – both ways. Right now, IoTivity can serialize as a floating point number, integer, and other ways, so receiving devices have to handle multiple serialization types. It’s not a big deal to fix it. It would also be beneficial to add ‘events and actions’ from AllJoyn: support for multiple generic types, supplemental metadata, enumeration values, and human readable strings.

    “CBOR is a little more compact than D-Bus, but it’s pretty much equivalent. With AllJoyn you have to know how big the data is before you can serialize it, but CBOR has a nice mechanism for streaming that lets you identify consecutive blocks.

    “One of the most powerful things in AllJoyn is that devices know their own data model. Since IoT endpoints may last longer than the servers talking to them, this ‘resource introspection’ is pretty powerful. Some endpoints will have differentiating features that aren’t standardized, so you need to be able to get the data model from it. AllJoyn also uses resource introspection to do code generation, runtime data validation, and access rights checking, so it’s very powerful for the developer.”

  • Transport – IoTivity’s UDP (IPv4 and 6) and UDP multicast vs. AllJoyn’s UDP and TCP (IPv4 with 6 coming):

    “I don’t think IoTivity is there quite yet. Right now it’s a COaP-only implementation.”

  • Service Discovery — IoTivity’s CoAP vs. AllJoyn’s MDNS:

    “These are basically the same: IP multicast with unicast responses and different unicast addresses.”

  • Network Topology — IoTivity’s point-to-point and point-to-multipoint vs. AllJoyn’s “mesh of stars” with leaf and routing nodes:

    “Overall, IoTivity’s approach is preferable, but AllJoyn’s mesh of stars has its advantages. In AllJoyn, leaf nodes [endpoints] rely on routing nodes to do message passing and service advertisement and discovery. It started out looking a lot like D-Bus, but became more distributed. AllJoyn’s approach enables lightweight, simpler devices on the leaf nodes, but they need to be connected to a routing node running Linux or Windows. You can’t have two leaf nodes talking to each other. So unless the routing node is running on an access point, you’ve doubled your network bandwidth.”

    “AllJoyn’s advantage is that the routing nodes support store and forward so leaf nodes can advertise or discover and then go to sleep. For example, a leaf node can post the current temperature on the routing node and then sleep. To do that now on IoTivity you need a caching server. It would be extraordinarily difficult for AllJoyn to eliminate routing nodes and have leaf nodes talk to one another. However, you could fairly easily add a node type to IoTivity with additional functionality such as resource discovery and store and forward. You could end up with something that is better than either solution.”

  • Security and permissions — IoTivity’s DTLS link layer with ACL permissions and resource, interface, wildcard and CRUDN vs. AllJoyn’s application layer and ACL plus “capability” with interface, object, property, and method etc.”

    “The underlying security technologies are similar, with both using ECC, AES, and X509, but AllJoyn’s approach is better. With AllJoyn, packets are encrypted at the application level, so it doesn’t matter how they get to their destination. With IoTivity’s link layer encryption, you hit boundaries as you move over different layers, so you need a trusted relationship between the endpoint and each boundary point. If you’re going from COaP to a server that then bridges out to XMPP, you need a trust relationship with the network. But it’s not that hard to add an application layer.”

    “Both frameworks have access control lists, but I prefer the IoTivity approach. With IoTivity, ACLs work at the level of a resource and of an interface, with a notion of potential wildcarding. An ‘interface’ is a view on a resource, and you can have multiple views, or even a view on a single property. This lets you build interfaces that give you property level ACLs. IoTivity avoids having access rights that are too fine grained, as they can be with AllJoyn. However, AllJoyn has the benefit of letting you do membership certifications much more easily than with IoTivity.”

    “So once again, security is an example of how you can mix and match features together to make something better. We can build a more evolved framework that essentially takes the best from both worlds.”

Further information

Watch the complete video below, and download the presentation’s slide deck in PDF format here.

Evolving a Best-of-Breed IoT Framework

Additional videos From the 2016 ELC and OpenIoT Summit are available here (requires free registration).

This article is copyright © 2016 and was originally published here. It has been reproduced by this site with the permission of its owner. Please visit for up-to-date news and articles about Linux and open source.

(advertise here)

Print Friendly, PDF & Email

4 responses to “How IoTivity plus AllJoyn could form a "best-of-breed" IoT framework”

  1. nonya says:

    IoT is dead! No spy devices! Just say NO!!

  2. DELANO UCHOA says:

    very nice post. (Link to download pdf is wrong)

  3. zoobab says:

    In the same register, there is Zyre, based on zeromq. Don’t know if it has been ported to microcontrollers though.

Please comment here...