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