This mirror is provided for easy forking. To contribute code to the project, please visit
C Makefile C++ Other
Clone or download
kmaloor Misc. fixes
* Make DYNAMIC=1 the default in the Linux Makefile which can be
  overridden while invoking Make.
* Fix memory leaks in unit tests.
* Fix leaks in oc_main_init/shutdown sequences when oc_main_init()
  returned with an error.
* Add EXTRA_CFLAGS while building apitest that was previously omitted.

Change-Id: I4b14daf6d82236c49cca3807761701f50ad0eab3
Signed-off-by: Kishen Maloor <>
Tested-by: IoTivity Jenkins <>
Latest commit d310650 Aug 13, 2018


Getting Started

IoTivity-Constrained is a lightweight implementation of the Open Connectivity Foundation (OCF) standards for the Internet of Things (IoT).

It was designed to build secure and interoperable IoT applications in full compliance with the OCF specifications with a minimal footprint not exceeding the needs of the specifications. The stack architecture lends itself to be ported rapidly to any chosen hardware/OS environment.

IoT applications may be built for a wide variety of rich and resource-constrained devices across the IoT landscape. As a general guideline, it should be feasible to deploy applications on class 2 constrained devices (>256KB Flash, >50KB RAM), or better.

The project is open-source, and its code is distributed under the commercial-friendly Apache v2 license.


IoTivity-Constrained Architecture

IoTivity-Constrained Architecture

IoTivity-Constrained's design presents the following features:

  • OS agnostic core: This cross-platform core (written in pure C) encompasses the APIs, OCF resource model, protocol, security features, memory management and event loop. The core interacts with lower level platform-specific functionality via a very limited collection of abstract interfaces. Such a decoupling of the common OCF standards related functionality from adaptations to any OS/target facilitates greater ease of long-term maintenance and evolution of the stack through successive releases of the OCF specifications.

  • Platform abstraction: These are a collection of abstract interfaces with a small set of hooks to platform-specific features. These interfaces are defined in generic terms and elicit a specific contract from implementations. The core calls into these interfaces to interact with the underlying OS/platform. The simplicity and boundedness of these interface definitions allow them to be rapidly implemented on any chosen OS/target. Such an implementation then constitutes a "port". A number of ports (adaptations) currently exist for immediate use, and the project will continue to expand this set.

  • Support for static OR dynamic allocation of internal structures: On environments with a C library that supports heap allocation functions, the stack can be configured at build-time to use dynamic memory allocation to operate without any pre-determined set of resource constraints.

    Alternatively, the stack may be configured to statically allocate all internal structures by setting a number of build-time parameters that constrain the number of serviceable connections and requests, payload sizes, memory pool sizes, timeouts etc. These collectively characterize an acceptable workload for an application.

  • Lightweight design and low complexity: This is achieved through the implementation of functionally cohesive modules, and weak coupling between stack layers.

  • Simple C APIs: The APIs are defined so as to closely align to OCF specification constructs aiding greater ease of understanding. Application code utilizing these APIs are largely cross-platform as a consequence of the design, and can be quickly migrated over to a any other target environment.

Project directory structure

contains the implementations of client/server APIs, the resource model, utility and helper functions to encode/decode to/from OCF’s data model, module for encoding and interpreting type 4 UUIDs, base64 strings, OCF endpoints, and handlers for the discovery, platform and device resources.
contains a tailored CoAP implementation.
contains resource handlers that implement the OCF security model.
contains a few primitive building blocks used internally by the core framework.
contains the sample onboarding tool (OBT).
contains external project dependencies.
contains the tinyCBOR sources.
contains the mbedTLS sources.
contains patches for deps/mbedTLS and need to be applied once.
contains all common headers.
contains client/server APIs.
contains helper functions to encode/decode to/from OCF’s data model.
contains utility functions for allocating strings and arrays either dynamically from the heap or from pre-allocated memory pools.
contains the collection of APIs for security onboarding and provisioning.
collectively represents the platform abstraction.
contains adaptations for each OS.
contains sample OCF applications.

Setup source tree

Grab source and dependencies using:

git clone --recursive

Apply mbedTLS patches into deps/mbedtls using:

patch -p1 < ../../patches/mbedtls_ocf_patch_1

patch -p1 < ../../patches/mbedtls_iotivity_constrained_patch_2

Building sample applications on Linux

The entire build is specified in port/linux/Makefile. The output of the build consists of all static and dynamic libraries, and sample application binaries which are stored under port/linux.

Run make for a release mode build without debug output, or support for dynamic memory allocation.

Add DYNAMIC=1 to support dynamic memory allocation.

Add SECURE=0 to exclude the OCF security layer and mbedTLS. The security layer is built by default.

Add DEBUG=1 for a debug mode build with verbose debug output.

Add TCP=1 to include support for TCP endpoints and CoAP over TCP (RFC 8323).

Add IPV4=1 to include IPv4 support in the build. Excluding IPV4=1 produces an IPv6-only build.

Note: The Linux, Windows, and native Android ports are the only adaptation layers that are actively maintained as of this writing (July 2018). The other ports will be updated imminently. Please watch for further updates on this matter.

Framework configuration

Build-time configuration options for an application are set in config.h. This needs to be present in one of the include paths.

Pre-populated (sample) configurations for the sample applications for all targets are present in port/<OS>/config.h.