Open Connectivity Foundation (OCF)

Resources

• Open Connectivity Foundation Home page

Introduction

The OCF is an industry consortium with a large and diverse membership. The Diamond level members (at April 2016) are Arris, CableLabs, Cisco, Electrolux, GE Digital, Intel, Qualcomm, Microsoft and Samsung. Below that are Platinum members and Gold members. About 190 members in total representing a huge cross-section of industry.

The stated goal is

Billions of connected devices (devices, phones, computers and sensors) should be able to communicate with one another regardless of manufacturer, operating system, chipset or physical transport. The Open Connectivity Foundation (OCF) is creating a specification and sponsoring an open source project to make this possible. OCF will unlock the massive opportunity in the IoT market, accelerate industry innovation and help developers and companies create solutions that map to a single open specification. OCF will help ensure secure interoperability for consumers, business, and industry.

The open source project sponsored by the OCF is IoTivity This is a Linux Foundation Collaborative Project. Anyone can download the software, and also help by documentation, source code or testing. This helps to ensure the open nature of the OCF project.

Specifications

The specifications are available. There are presently five:

Core Framework

This specifies the OIC core architecture, interfaces, protocols and services to enable OIC profiles implementation for Internet of Things (IoT) usages and ecosystems. The OIC architecture is based on the Resource Oriented Architecture design principles. A resource model to define resources is described in detail. Additional functional interactions (Endpoint and Resource Discovery, Advertisement, Monitoring and Maintenance) and necessary resources for the same are specified. Different vertical specifications use the definitions and models defined in this document.

Security

This describes device on-boarding with a trusted on boarding tool within the IoT network, in particular for a variety of devices with different cryptographic capabilities. The document also defines security resources needed for security functions within the OIC resource-oriented architecture as well as mechanisms for protecting the resources both at rest and in transit. In particular, it defines access control mechanisms to handle OIC software resources hosted by devices and the transport security mechanisms for security exchanges between different devices. Finally, it provides security hardening requirements for the underlying platform hosting the OIC software.

Smart Home Device

Smart Home Device defines an OIC Device for usage in the Smart Home vertical by making use of functionality defined in the OIC Core Specification and OIC Smart Home Resource Specification. This document further profiles the OIC Core Specification where implementation choices exist in the areas of: messaging protocol, payload encoding and network layer. For the devices defined, the document specifies which resources are mandatory to be implemented.

Resource Type

This specifies a base resource schema for all Smart Home resources and a set of resources that are on built on the base schema that may be exposed by OIC Devices. The Resource specification uses RAML as a specification language for the APIs exposed by the resources and JSON Schemas as payload definitions for the resource representations. These resources support the modeling of the key Use Cases of: Device Control, Notification, Environment Control, Energy Management and Energy Saving.

Remote Access

Remote Access describes the use of industry-standard protocols (initially XMPP), in conjunction with OIC Core Framework, Security, and Smart Home Device specifications to facilitate secure access to OIC IoT devices of all types. In Remote Access, the security and resource models described in the other OIC Specifications are mapped to XMPP (and later other) protocols, leveraging the rich capabilities of XMPP for remote discovery, presence, and Pub-Sub functions. Fundamentally, Remote Access makes the I in IoT truly (and securely) mean “Internet”, and not “Intranets”

From this it can be seen that the initial focus is on the Home IoT. However, the intention is that the Core Framework should be applicable in multiple vertical domains. The Home IoT domain is the only one fleshed out so far.

Entities and servers

The basic level of objects and interactions with objects is heavily based on the REST model. Entities in the physical world (sensors, actuators, etc) are represented as resources. "Interactions with an Entity are achieved through its resource representations using operations that adhere to Representational State Transfer (REST) architectural style."

Entities are accessed through their addresses, typically as URIs. Formally, all OCF entities have the URI scheme as oic, as in

      
	oic://myhome.org/thermometer1/
      
    

(the OIC stands for Open Interconnect Consortium, an earlier name for the OCF). If a message to that URI is sent out over HTTP, the oic: scheme is changed to http: and similarly to coap: over CoAP.

In addition to the URI for an entity (device), there are also URIs related to this one. They give extra information about the entity. Using the above URI, these are

• oic://myhome.org/thermometer1/res
• oic://myhome.org/thermometer1/d

Servers and clients interact. A client (which may be a user's system, another server, etc) makes requests of servers. These requests may be to discover what resources the server knows about or manages, or to cause an interaction with a resource. The server may be in control of some resources: for example, a Raspberry Pi may have some sensors attached, so the sensors can be read through directly through the Pi as server.

Other servers may act as directory services, keeping information about entities within a particular network. These can be especially useful for keeping track of devices that are often sleeping due to power constraints.

Operations

The actual operations in OCF are written as CRUDN data repository operations, but they map into REST network operations fairly easily:

• Create → POST
• Read → GET
• Update → PUT or POST
• Delete → DELETE
• Notify: not in REST, means the server notifies the client of a change

Operations are typically carried out using HTTP or CoAP, depending on the network. The Core specification gives an abstract form of the messages. For example. for the CREATE request it says"

The CREATE request message will carry the following parameters:

• fr: Unique identifier of the OIC Client
• to: URI of the target resource responsible for creation of the new resource.
• ri: Identifier of the CREATE request
• cn: Information of the resource to be created by the OIC Server
  • cn will include the URI and resource type property of the resource to be created.
  • cn may include additional properties of the resource to be created.

And for the response on success:

The CREATE response message will include the following parameters.

• fr: Unique identifier of the OIC Server
• to: Unique identifier of the OIC Client
• ri: Identifier included in the CREATE request
• cn: Information of the resource as created by the OIC Server.
  • cn will include the URI of the created resource.
  • cn will include the resource representation of the created resource.
• rs: The result of the CREATE operation

Later sections give the details of encoding these CRUDN messages over HTTP and CoAP. The required representation of the parameters is CBOR . However, content type negotiation may be used to give, say, JSON format for the parameters.

Resource types

Copyright © Jan Newmarch, jan@newmarch.name

"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.

If you like this book, please donate using PayPal