User Tools

Site Tools


Notification Manager (NM)

This document provides the programming model and interaction details between Rich Block and Lite Block clients. The intent is to provide enough detail to a developer to understand all the relevant use cases for the client and server model of the Lite Block Hosting.

The document is divided into three main chapters.

One chapter describes how the hosting resources are discovered and hosted by another smart device, a Rich Block. The SDK and the service on the Rich Block provide a rich object-oriented object model.

Another chapter describes how a hosting resource is registered and made available and consumable on the network by another smart device as a virtual resource. The examples for these interactions are provided in a later section.

Finally, one chapter describes the interaction model between Lite Block, Hosting Smart Devices and Consumer Smart Devices. The examples for these interactions is provided later.


In subsequent releases, the IoT Notification Manager Service functionalities will be enhanced to include other important features as follows:

Hosting Service Handler

The Hosting Service Handler will be mainly responsible for setting the hosting flag. It will also handle the race conditions for Rich devices, to host simultaneously the same Lite block resources and prevent duplicate hosting. Network topology change scenarios for the Lite block and the hosting device will be taken care by the handler.

Priority Subscription

Priority Subscription will have priority settings to select dynamically between virtual resources and physical resources giving virtual resources more priority.

Notification Manager SDK

In the Notification Manager SDK, the APIs will be exposed for notification manager resource discovery.

Virtual Resource Caching Mechanism

The Virtual Resource Caching Mechanism will have virtual resource tree management which will dynamically check the caching policy to address the topological changes of original hosted device.

Notification Caching Mechanism

With the Notification Caching Mechanism, notification data will be added to the persistent storage if required for supporting the pending and sync functionalities.

Notification Persistent Storage

With Notification Persistent storage, the database has to be implemented to store and retrieve notification data asynchronously.

Notification Synchronization

With Notification Synchronization, an Iotivity Device can provide the state (create/read/update/delete) synchronization of the corresponding notifications with the target Iotivity Device.

Notification QoS (Priority)

With Notification QoS (Priority) a device can deliver the prioritized notification based on the requested QoS level.

Pending Notification

With Pending Notification, the Notification Manager can cache notifications and send them to the target Iotivity Devices later. Check Subscribed Consumer comes within the range of the IOT devices.

Targeted Notification

With Targeted Notification, explicit notification can be made for unsubscribed IOT devices

Network Topology Variation Handling

Network Topology Variation handling will provide handling of different user scenarios of topological changes in the network with respect to Lite and Rich blocks.

Relative Intelligent Hosting

Relative Intelligent Hosting will provide intelligence during hosting resource discovery to check the memory and power capability of the devices in network vicinity. This will help in selecting the best device to host.


Virtual Resource

A virtual resource is a resource of another Lite device or smart device that is hosted by a smart device for other devices to consume via the hosting device.

Notification Manager Operations

Operations are actions that a Rich Device performs for hosting a particular resource of a Lite device. The event driven mechanism is implemented to detect the presence of devices whose resources needs to be hosted, then targeted discovery of hosting resource is performed.

A resource is registered as virtual in the smart device base to differentiate and give priority to the hosting resource. The Notification Manager will have the priority settings to select dynamically between a virtual resource and a physical resource giving the virtual resource more priority.

NM Architecture and Components

NM Architecture

This section defines the programming model on the RICH side for interacting with Thin Block devices (and other RICH devices) for hosting/servicing resources. An introduction and overview to the main classes and interfaces is provided, followed by specific usage scenarios and sample code. Figure 1. NM Architecture

NM Class Diagram

Figure 2. NM Class Diagram

NM Components

<class notificationmanager>

NotificationManager is the root service class and consists of two internal entities called the registration manager and resource manager. It initializes the configuration parameters such as the service operation mode, service type etc.

It also registers the event listeners for the presence of devices whose resources need to be hosted.

<class registrationmanager>

RegistrationManager handles the virtual representation of the Lite device resource and (un)registers the virtual resource to the IoT base.

<class resourcemanager>

ResourceManager is responsible for Lite device resource discovery. It implements the event driven mechanism of listening to the on presence of any Lite block devices in the vicinity.

In future versions, resource manager will implement the caching policy and resource database for pending and sync cases.

<class virtualrepresentation>

VirtualRepresentation adds the virtual tag and virtual entity handler for the hosting resource.

Notification SDK

The Notification SDK supports applications to find and subscribe the notification resources. It prioritizes virtual resources and maps the virtual resource to the original resource.

Service Initialization

Initializes the configuration parameters such as the service operation mode, service type etc.

It also registers the event listeners for the presence of devices whose resources need to be hosted.

NB: This event driven mechanism can be further enhanced to pre-check the power and memory capabilities of a device and dynamically decide which device needs its resources to be hosted.

void NotificationManager::initialize()
  cfg.ipAddress = "";
  cfg.port = 5683;
  cfg.mode = ModeType::Both;
  cfg.serviceType = ServiceType::InProc;
  nmOCPlatform = new OCPlatform(cfg);
  //Register Hosting Event
  //Listen to on presence of Lite device
  //Check if Hosting Required


The advertisement/discovery mechanism for Lite Block clients is event driven. Discovery of hosting resource happens by listening to the on presence of the Lite devices. Querying or probing for all resources for the particular discovered Lite device follows.

Once a target Lite device is found, the Lite device IP address can be used as a host IP to direct the resource discovery query.

The query parameters and mode of discovery vary based on whether a specific resource or all resources of the Lite device can be hosted.

(@param host, @param resource URI) Mode of Discovery
(Not Empty, NULL/Empty) Performs ALL resource discovery on a particular service
(Not Empty, Not Empty) Performs query for a filtered/scoped/particular resource(s) from a particular service
void NotificationManager::findHostingCandidate()
    ResourceManager::getInstance()->findNMResource("", "coap://",true);
  catch(OCException e)
    std::cout << "Fail!!" << endl;

Registering as Virtual Resource

In the preceding sections all the interactions have been discovering a resource from a Lite Block device. This section wraps up local resource management functionality by illustrating how a Rich Block device can register a hosting resource as virtual and make it available to other Rich Block devices.

Registering a resource as virtual is done by adding a virtual tag and making it available for other entities to discover and consume. A resource is made available by registering onto a CBServer object.

In the example below a light resource is registered.

Example: Registering a resource as virtual

bool RegistrationManager::registerNMResource(VirtualRepresentation &resourceObject, std::shared_ptr<ocresource> resource)
  std::string uri = resourceObject.getUri();
  std::string type = resourceObject.getResourceTypeName();
  std::string interface = resourceObject.getResourceInterface();
  OCResourceHandle resourceHandle;
  OCStackResult result;
  result = NotificationManager::getOCPlatform()->registerResource(
    interface, std::function<void(std::shared_ptr<ocresourcerequest> request,
    std::shared_ptr<ocresourceresponse> response)>
      (std::bind(&VirtualRepresentation::entityHandler, resourceObject,
  // On successful registration
  // Observe to the changes of the parameters of the original Lite
  // resource

Observing a Hosting Property

Once a resource of a Lite device is registered as virtual resource in the hosting device, it monitors that resource property for any state change. The hosting device reports back any change in state of the resource to any of the subscribers of that property.

bool RegistrationManager::registerNMResource(VirtualRepresentation &resourceObject, std::shared_ptr<ocresource> resource)
  // Get the resource URI, interface, type and property flag
  // Register as virtual resource
  // On success, observe on the resource parameters of the original
  // Lite resource
  if(OC_STACK_OK != result)
    std::cout << "Resource : " << uri << "Register Fail\n";
    return false;
    QueryParamsMap queryParmaMap;
    resource->observe(ObserveType::Observe, queryParmaMap,
      std::function<void(const const="">
  return true;

Notify All Consumers

The hosting device notifies all consumers who are observing the hosted resource property of any change in state.

void VirtualRepresentation::onObserve(const OCRepresentation& rep, const int& eCode, const int& sequenceNumber)
    AttributeMap tmp = rep.getAttributeMap();
    std::string targeturi = addVirtualTag(rep.getUri());
    OCStackResult result = OC_STACK_OK;
    VirtualRepresentation tmpObj = *this;
      AttributeMap tmpAttMap = ResourceManager::getInstance()->copyAttributeMap(tmp);
        // lock attribureMap
        std::unique_lock<std::mutex> ck(mutexAttributeMap);
        { conditionAttributeMap.wait(lck); }
          isReadyAttributeMap = false;
          attributeMap = tmpAttMap;
          // unlock attributeMap
          isReadyAttributeMap = true;
        result = OCPlatform::notifyObservers(tmpObj.getResourceHandle());

Finding Hosting Resource By Consumer

The Rich block acting as a consumer can find the resource using the Notification Manager tag.

Example: Finding a light resource hosted by Notification Manager.

void findResourceCandidate()
		nmfindResource("", "coap://");
			// some operations
	}catch(OCException& e)
notification_manager_for_linux.txt · Last modified: 2015/04/21 10:38 by Myungjae Lee