Open Connectivity Foundation (OCF)

Objective of Open Connectivity Foundation (OCF)

• The goal is to understand the technical specifications governing device interaction in the Internet of Things (IoT).
• OCF covers communication protocols, data formats, and security and device management protocols.
• OCF standards ensure device interoperability, data security, and user privacy, supporting the integration of smart technologies.

OCF Specifications (ISO/IEC 30118-x) Parts

• Part 1, core: Defines the mandatory architecture, core features, resource framework, and protocols for OCF implementations for IoT.
• Part 2, security: Provides a strong security foundation to address future threats.
• Part 3, bridging: Facilitates translation between devices in the OCF ecosystem and non-OCF ecosystems.
• Part 4, resource type: Outlines the resources that can be exposed by an OCF Device, building on the OCF Core Specification.
• Part 5, device: Details how a device is represented in the OCF and lists known OCF device types.
• Part 6, Resource to AllJoyn interface mapping: Provides mapping to ensure equivalency between AllJoyn defined Interfaces and OCF defined Resources.
• Part 6 continuation, AllJoyn: AllJoyn is an open-source software framework that enables device and application discovery and communication across platforms and manufacturers without Internet.
• Part 6 continuation, AllJoyn: AllJoyn enables interoperability in the IoT ecosystem, facilitating communication between devices and applications.
• Part 7, Wi-Fi easy setup: Defines extensions to the OCF Core Specification for easy setup of Wi-Fi or eSIM connectivity on an OCF Device.
• Part 8, resource to oneM2M resource mapping: Provides mapping to establish equivalency between oneM2M defined Module Classes and OCF defined Resources.
• Part 8 continuation, oneM2M: Global partnership founded in 2012 created technical standards for Machine-to-Machine (M2M) and IoT technologies, ensuring interoperability/security.
• Part 9, core optional: Outlines implementable capabilities within the OCF core architecture for features like scenes, rules, and alerts.
• Part 10, cloud API for cloud services: Provides APIs for device information retrieval and event subscription between two OCF Cloud instances, agnostic of data models.
• Part 11, device to cloud services: Defines extensions to the OCF Core Specification for devices connected to an OCF Cloud.
• Part 12, device to cloud services: Defines extensions to the OCF Core Specification for devices connected to an OCF Cloud.
• Part 12, cloud security: Outlines security requirements for OCF devices and clouds, covering device provisioning, credential management, and ISO/IEC standards alignment.
• Part 13, onboarding tool: Facilitates a secure connection between a client and a server in the IoT client-server model.
• Part 14, resource to BLE mapping: Standardizes the interaction between Bluetooth Low Energy devices and OCF-defined resources.
• Part 15, resource to EnOcean mapping: Provides mapping to establish equivalency between OCF defined Resources and EnOcean (energy harvesting wireless technology) defined elements.
• Part 16, resource to UPlus mapping: Provides mapping between U+ (high-quality lead-acid batteries for vehicles) and OCF defined Resources.
• Part 17, resource to Zigbee cluster mapping: Provides mapping between Zigbee (low-power, low-data-rate wireless communication protocol) defined Clusters and OCF defined Resources.
• Part 18, resource to Z-wave mapping: Provides mapping to establish equivalency between Z-Wave (mesh network technology) defined commands and OCF defined Resources.

IoT Protocols

• CoAP
• MQTT
• MQTT-SN
• DDS
• LPWAN
• OPC-UA
• Sigfox
• Thread
• Z-Wave
• Zigbee
• XMPP
• BLE Mesh
• DASH7
• DDS-XRCE
• RPL
• 6LoWPAN
• LTE-M
• Category M1
• NB-IoT

Constrained Application Protocol (CoAP)

• CoAP is a specialized Internet application protocol designed for constrained devices in IoT.
• CoAP enables constrained devices ("nodes") to communicate with the wider Internet using similar protocols, making it ideal for smart homes and industrial automation.
• CoAP is useful for low power and lossy networks, and more energy-efficient compared to HTTP or MQTT.
• CoAP supports both confirmable and non-confirmable messages.
• CoAP is based on a resource model similar to HTTP, using methods like GET, PUT, POST, and DELETE.
• CoAP can be bound to Datagram Transport Layer Security (DTLS) for secure communication.

Message Queuing Telemetry Transport (MQTT)

• MQTT is a lightweight, publish-subscribe, machine-to-machine network protocol for remote locations with resource-constrained devices or limited bandwidth.
• MQTT is designed for bandwidth efficiency, low power usage, and suitability for devices connected via satellite or other resource-constrained networks.
• MQTT supports messaging between devices and the cloud, and easy broadcasting of messages to groups of devices.
• MQTT has defined quality of service levels for delivery: at most once (QoS 0), at least once (QoS 1), and exactly once (QoS 2).
• MQTT runs over a transport protocol providing ordered, lossless, bi-directional connections, typically TCP/IP.
• Using MQTT, Clients publish messages to an MQTT broker, and other clients subscribe to the messages they want.
• MQTT brokers filter incoming messages and distribute them correctly to subscribers.
• MQTT has been used since 1999 in monitoring oil pipelines within the SCADA industrial control system.

Message Queuing Telemetry Transport for Sensor Networks (MQTT-SN)

• MQTT-SN is a specialized version of MQTT, designed for low-power, constrained devices in sensor networks.
• MQTT-SN is optimized to work on non-TCP/IP networks like Zigbee and Bluetooth.
• MQTT-SN is suitable for devices lacking Ethernet or WiFi capabilities.
• MQTT-SN supports MQTT QoSs and a special QoS level -1 for blind fire-and-forget messaging.

Data Distribution Service (DDS)

• DDS is a middleware protocol and API standard for machine-to-machine (M2M) communication in IoT applications.
• DDS enables dependable, high-performance, interoperable, real-time, and scalable data exchanges using a publish-subscribe pattern.
• DDS is optimized for distributed processing, directly connecting sensors, devices, and applications without dependence on centralized IT infrastructure.
• DDS is suited for aerospace, defense, autonomous vehicles, medical devices, robotics, and other fields requiring real-time data exchange.
• DDS has extreme reliability and a scalable architecture for mission-critical and safety-critical applications.