Add intersphinx link for UniMgr and remove docs
[docs.git] / docs / developer-guide / iotdm-developer-guide.rst
1 .. _iotdm_dev_guide:
2
3 IoTDM Developer Guide
4 =====================
5
6 Overview
7 --------
8
9 The Internet of Things Data Management (IoTDM) on OpenDaylight project
10 is about developing a data-centric middleware that will act as a oneM2M
11 compliant IoT Data Broker and enable authorized applications to retrieve
12 IoT data uploaded by any device. The OpenDaylight platform is used to
13 implement the oneM2M data store which models a hierarchical containment
14 tree, where each node in the tree represents an oneM2M resource.
15 Typically, IoT devices and applications interact with the resource tree
16 over standard protocols such as CoAP, MQTT, and HTTP. Initially, the
17 oneM2M resource tree is used by applications to retrieve data. Possible
18 applications are inventory or device management systems or big data
19 analytic systems designed to make sense of the collected data. But, at
20 some point, applications will need to configure the devices. Features
21 and tools will have to be provided to enable configuration of the
22 devices based on applications responding to user input, network
23 conditions, or some set of programmable rules or policies possibly
24 triggered by the receipt of data collected from the devices. The
25 OpenDaylight platform, with its rich unique cross-section of SDN
26 capabilities, NFV, and now IoT device and application management, can be
27 bundled with a targeted set of features and deployed anywhere in the
28 network to give the network service provider ultimate control. Depending
29 on the use case, the OpenDaylight IoT platform can be configured with
30 only IoT data collection capabilities where it is deployed near the IoT
31 devices and its footprint needs to be small, or it can be configured to
32 run as a highly scaled up and out distributed cluster with IoT, SDN and
33 NFV functions enabled and deployed in a high traffic data center.
34
35 oneM2M Architecture
36 -------------------
37
38 The architecture provides a framework that enables the support of the
39 oneM2M resource containment tree. The onem2m-core implements the MDSAL
40 RPCs defined in the onem2m-api YANG files. These RPCs enable oneM2M
41 resources to be created, read, updated, and deleted (CRUD), and also
42 enables the management of subscriptions. When resources are CRUDed, the
43 onem2m-notifier issues oneM2M notification events to interested
44 subscribers. TS0001: oneM2M Functional Architecture and TS0004: oneM2M
45 Service Layer Protocol are great reference documents to learn details of
46 oneM2M resource types, message flow, formats, and CRUD/N semantics. Both
47 of these specifications can be found at
48 http://onem2m.org/technical/published-documents
49
50 The oneM2M resource tree is modeled in YANG and essentially is a
51 meta-model for the tree. The oneM2M wire protocols allow the resource
52 tree to be constructed via HTTP or CoAP messages that populate nodes in
53 the tree with resource specific attributes. Each oneM2M resource type
54 has semantic behaviour associated with it. For example: a container
55 resource has attributes which control quotas on how many and how big the
56 collection of data or content instance objects that can exist below it
57 in the tree. Depending on the resource type, the oneM2M core software
58 implements and enforces the resource type specific rules to ensure a
59 well-behaved resource tree.
60
61 The resource tree can be simultaneously accessed by many concurrent
62 applications wishing to manage or access the tree, and also many devices
63 can be reporting in new data or sensor readings into their appropriate
64 place in the tree.
65
66 Key APIs and Interfaces
67 -----------------------
68
69 The API’s to access the oneM2M datastore are well documented in TS0004
70 (referred above) found on onem2m.org
71
72 RESTCONF is available too but generally HTTP and CoAP are used to access
73 the oneM2M data tree.
74