Page 22

EETE OCT 2015

Internet of things Intel-led group touts OIC 1.0 over rival IoT specs By Junko Yoshida The Open Interconnect Consortium (OIC), led by such industry heavyweights as Intel, Cisco, Samsung, General Electric and Samsung, has made public its long-waited Internet of Things specification 1.0. The OIC move is expected to add weight to the IoT debates brewing over several incompatible specs promoted by different groups. The newly released OIC 1.0 is technically still a “candidate spec,” because the OIC is currently going through a 60-day formal IPR process, explained Mike Richmond, executive director at the Open Interconnect Consortium. “By the third week of October, we expect it to become the formal spec.” During an interview with EE Times, Richmond stressed that “we all need to understand that the big unresolved problem with IoT is not about ‘things.’ But it’s about the network.” He laid out two key points which he believes will set OIC apart from rival offerings. First, the OIC offers “cloud-native architecture.” Second, it provides a better Intellectual Property Rights policy. To be more specific, OIC is based on “the industry’s first cloud-native architecture designed for IoT” documented in a formal specification, according to Richmond. “You hear about cloud-native architecture – as it’s being used by web services. It’s a concept more familiar to the enterprise market.” But how does the cloud-native design matter to the IoT world? “We’ve adapted the cloud architecture to IoT, because it allows us to scale. Our goal in connectivity is to go beyond a single home, or a single machine,” Richmond said. OIC’s approach leverages cloud techniques to enable smooth integration between local and cloud (e.g., local-to-local and local-to-cloud) use cases. “Cloud-native architecture means that even if developers start with a local-only approach they don’t have to re-architect it to scale,” explained the consortium. Chris Rommel, executive vice president at VDC Research Group, Inc., told EE Times that the benefit of OIC’s ‘cloud-native approach’ is architecture that allows devices to intelligently self-organize and communicate locally if the cloud is not directly accessible.” In other words, “The OIC is using the combination of XMPP, 6LowPAN, and RESTful APIs help to provide this flexibility.” Rommel noted that OIC is using the approach based on Representational State Transfer (REST), a software architecture style for building scalable web services. In contrast, Qualcomm-led AllSeen, one of OIC’s competitors, is using Remote Procedure Call (RPC). RPC allows a computer program to cause a subroutine or procedure to execute in another address space – often on another device on a shared network – without the programmer explicitly coding the details for this remote interaction. Asked to compare the two approaches, Rommel said, “The REST-based approach of OIC can sometimes lead to better interoperability compared to the RPC approach used in AllSeen since REST is semantically/ contextually consistent.” Rommel, however, added, “But both frameworks ultimately have a goal of supporting broad-based interoperability.” IPR policy Although many engineers roll their eyes over talk about differences in IPR policy, the distinctions are important, OIC’s Richmond noted. Under OIC, two legally separate entities exist. One develops specifications/certification programs, and another, called IoTvity, is specifically designed to be an open source project. The key here is that OIC and the associated IoTivity open source project both grant royalty free licenses, but they depend on separate patent policies. The OIC spec is covered by RAND-Z (Reasonable & Non-Discriminatory Zero royalty) patent licensing, while IoTivity code is covered by Apache v2.0. Why is this so important? Richmond sees this approach as the best patent coverage available in any OSI- approved open-source license. For instance, under IoTivity, covered by Apache 2.0, anyone, whether an OIC member or not, can download, use, modify or contribute back to IoTivity and will get the full benefit of Apache 2.0 patent provisions. Under OIC, covered by RAND-Z patent licensing, members are granted a royalty-free license to any necessary claims. They must implement OIC Specifications for the “compliant portion” of their product, regardless of whether the member was involved in developing the relevant portion of the spec. Some AllSeen members, however, believe that building a wall between software developers working on open source code (i.e. IoTivity) and developers of specs/certification (OIC) is a bad idea. They say it’s critical to give developers access to both code and spec. Richmond disagrees. His claim is that OIC offers software developers freedom “not to become an OIC member.” He said, “It’s not required for software developers to be an OIC member. It’s not fair to ask them to pay a membership fee in order to develop codes, which creates a conflict for those working in the open-source community.” VDC Research Group’s Rommel said that in contrast to OIC, “AllSeen is mired in some ambiguity based on the ownership of certain IP patents by a holding company (Qualcomm) while, technically, it is a subsidiary of Qualcomm that is a member of AllJoyn.” Rommel is concerned that this might lead to IP contamination by an organization or if there were a change in policy at the holding company (as opposed to the member subsidiary) 22 Electronic Engineering Times Europe October 2015 www.electronics-eetimes.com


EETE OCT 2015
To see the actual publication please follow the link above