Bringing Remarkable Things to Life.
OCF brings together a wide ecosystem of developers and resources to help create and deliver products that continue to make IoT a reality. Here you will find the resources necessary to design, build and achieve OCF certification, reducing total time to market costs, all while ensuring secure interoperability across market sectors.
How do you want to connect?
OCF allows you to connect IoT devices and systems using three distinct methods, namely Device-to-Device, Device-to-Cloud and Cloud-to-Cloud. In this page, we outline each of these methods, and provide the necessary flow and options required for each, along with links to the required resources and documentation.
Device-to-Device
Device2Device communication is establishes communication in the same network, meaning all devices are on the same network. The communication addressed is IPV6.
Using OCF Models
The OCF models can be found in the specifications.
The function that each device should contain is expressed via resources. The following kinds of resources exist:
- Infrastructure, e.g. the resources that are mandatory and make up the OCF Secure IP Device Framework
- Optional Core resources, resources that are generic for all devices
- Mandatory resources for the device type
- Any other optional resource
OCF models are specified in Open API Specification 2.0, and is governed by OPENAPI initiative. This is API definition format is widely used to describe restful interfaces.
Each resource is denoted with the resource type value, “rt”. This is a string and all OCF definitions start with “oic.r”. All OCF standardized resource types are registered with IANA. What is typically descibed in OAS2.0 for a URL are the GET and POST actions, with schema definition of the payload.
This is what OCF uses to describe which HTTP methods must be implemented per resource type and which payloads are used for the methods. The payloads are described in JSON and the JSON schema is using draft-04 format. The actual implementation of OCF is not using HTTP but CoAP. This is a direct translation of HTTP into CoAP, for example: HTTP-GET into CoAP-GET. Also, JSON is not on the wire, CBOR is on the wire, JSON can be directly translated into CBOR. However, all resource definitions are using HTTP & JSON for readability. Also, the URL is not important, the URL is place holder for the real URL to be used in the implementation.
Use OCF GitHub
If no appropriate model is found, then follow the flow to create new model in OCF.
The function that the device should contain is expressed via resources. The following kinds of resources exist:
- Mandatory resources for the device type
- Resources that are mandated for the device type.
- Easy to figure out by device type:
- https://openconnectivityfoundation.github.io/devicemodels/docs/index.html
- Any other optional resource
- Recommendation can also be found at
- https://openconnectivityfoundation.github.io/devicemodels/docs/index.html
- However every resource can be used:
- Infrastructure, e.g. the resources that are mandatory and make up the OCF Secure IP Device Framework
- Don’t worry about these, these will come with the framework
- https://github.com/openconnectivityfoundation/core
- Optional Core resources, resources that are generic for all devices
- https://github.com/openconnectivityfoundation/core-extensions/tree/master/swagger2.0
- Example: network monitoring
If no appropriate model is found, then follow the flow to “Create OAS2.0 models”.
IoTivity Getting Started
When all resources are identified, then follow the instructions of getting started with device simulation.
This getting started guide will create a device on a Linux PC and will create the communication infrastructure that is required for the implemented resources. Here one will learn:
- How to generate the server code
- How to interact with the server code
- How to update the example, so that the generated code will have the resources that you want.
- Note that the environment that has been set up contains all OCF resources.
Device-to-Cloud
Device2Cloud communication involves communication between OCF devices on one or more proximal networks communicating with devices outside the local network. This is accomplished via connection through a secure account in a secure cloud environment. All communications are secured using auth-crypt ACE credentials. Authorization is done using auth0 with a unique ID and an authorization code from the cloud. Communication addressing is done through secure COAP and TCP at a URL using a specific port. Clients logged into a specific account on the cloud can discover and onboard servers logged into the same account as if they were local.
Setup cloud infrastructure
Vendors using device-to-cloud communications can use any OCF compliant cloud where they have accounts, or they can create their own OCF cloud. The cloud communications interface is defined in OCF specifications here. There is no limit to the number of OCF clouds that can be created. One OCF compliant open-source cloud, PLGD, is here. Instructions for building your own OCF cloud are here. OCF compliant as well as non-OCF clouds can be securely linked using the OCF-defined Universal Cloud Interface (UCI) cloud-to-cloud interface described below in the C2C section.
PLGD
As mentioned in the previous paragraph, the PLGD cloud is an open-source OCF cloud implementation that is available for general use and has been certified to comply with the OCF D2C specifications. You can find it here. Instructions for using the PLGD cloud are on the on the PLGD site. As with all OCF clouds, they are used with the CoapCloudConfResURI described below.
Create client talking to cloud
All OCF clouds are used with the CoapCloudConfResURI resource defined here. This resource must be included and any device intending to use an OCF cloud directly. An OCF proxy device can be used to connect D2D devices to an OCF cloud even if the D2D device does not include the CoapCloudConfResURI resource directly. Instructions for using the CoapCloudConfResURI resource are documented the D2C sample. This example illustrates connecting to both the existing PLGD open-source cloud as well as a local private cloud running in a Docker container.
OTGC
Onboarding Tool and Generic Client (OTGC) is an OCF-provided tool that can securely onboard and control any OCF server using an automatically generated user interface. The interface is derived from the resources advertised by the device itself. No programming or device configuration is necessary. OTGC is open-source and versions are maintained by OCF on the Android and Linux platforms. Instructions for installing these versions are here (Android) and here (Linux). Open source code is available here. OTGC will work with D2D devices with no setup. For D2C connections, configuration must be set up to indicate the cloud to use. Once configured, OTGC can discover, securely onboard and control OCF devices.
Create device talking to cloud
Of course, server devices must be connected to and registered in a common OCF cloud account in order to be used by OTGC or any other client. More complex servers that can implement any OCF resources can be created using DeviceBuilder. This script automatically generates fully functional code for any device described in a simple device description file. There are convenient tools that will also compile the code, set security and run the code. This process is described in the examples here.
Iotivity
All of the examples are built using the IoTivity open-source implementation of OCF. Twice a year, updated versions of the OCF specifications are released (latest version here). Each release also includes an updated automatic certification tool and a version of IoTivity that complies with the latest version of the specifications and passes the certification tool.
Cloud-to-Cloud (Universal Cloud Interface)
The Cloud-to-Cloud communication establishes communication between two clouds: Client-side Cloud and Device-side Cloud. It specifies a set of APIs on the cloud with the design concepts:
- OAuth 2.0 based cloud account linking
- HTTPS request and response
- JSON payload of OCF models or external models
The clients and devices communicating through Cloud-to-Cloud APIs (UCI) may not be OCF compliant.
Setup a Client-side Cloud
Client-side Cloud is called Origin Cloud in the OCF specification. It’s the cloud to which the user’s clients are connected.
Through Cloud-to-Cloud APIs, the Client-side Cloud can:
- Get access token and refresh token from the Device-side Cloud
- Retrieve the information of all devices or a single device of the user
- Retrieve a specific resource (e.g. get the on/off status of a binary switch)
- Update a specific resource (e.g. change the binary switch from on to off)
- Subscribe/Unsubscribe to multiple event types at all devices, a single device, or a single resource level
Setup a Device-side Cloud
Device-side Cloud is called Target Cloud in the OCF specification. It’s the cloud to which the user’s devices (servers) are connected.
Through Cloud-to-Cloud APIs, the Device-side Cloud can:
- Grant access token and refresh token to the Client-side Cloud
- Expose APIs to devices and resources according to the scopes contained in access token.
- Send notifications to the Client-side Cloud according to the established subscription.
plugged.in
plgd, an open source project, delivers an open source reference implementation which presents best practices for Cloud deployment of the OCF specifications.
plgd contains all components to create the OCF Cloud infrastructure, including the Cloud component of the Device to Cloud Services and OCF Cloud API for Cloud Services specifications.
Open Source Project
There is also an Open Source implementation of the OCF specification called the IoTivity Project. The project brings together the open source community to accelerate the development of a single framework and the services required to securely connect devices.
