1
2
3
4
5
O NE M2M
T EC H NIC A L R EPO RT
Document Number
TR-0034-V-0.2.0
Document Name:
Developer Guide: CoAP binding and long polling for temperature
monitoring
Date:
2017-04-05
Abstract:
The document provides a simple use case for guiding application
developers to develop applications using functionalities provided by a
oneM2M service platform.
Template Version: 08 September 2015 (Dot not modify)
6
7
8
9
10
11
12
This Specification is provided for future development work within oneM2M only. The Partners accept no
liability for any use of this Specification.
13
14
15
The present document has not been subject to any approval process by the oneM2M Partners Type 1.
Published oneM2M specifications and reports for implementation should be obtained via the oneM2M
Partners' Publications Offices.
16
17
18
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 1 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
19
About oneM2M
20
21
22
23
The purpose and goal of oneM2M is to develop technical specifications which address the
need for a common M2M Service Layer that can be readily embedded within various
hardware and software, and relied upon to connect the myriad of devices in the field with
M2M application servers worldwide.
24
More information about oneM2M may be found at: http//www.oneM2M.org
25
Copyright Notification
26
© 2015, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
27
All rights reserved.
28
The copyright and the foregoing restriction extend to reproduction in all media.
29
30
Notice of Disclaimer & Limitation of Liability
31
32
33
34
The information provided in this document is directed solely to professionals who have the
appropriate degree of experience to understand and interpret its contents in accordance with
generally accepted engineering or other professional standards and applicable regulations.
No recommendation as to products or vendors is made or should be implied.
35
36
37
38
39
40
41
42
43
44
45
46
NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS
TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE,
GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO
REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR
FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF
INTELLECTUAL PROPERTY RIGHTS. NO oneM2M PARTNER TYPE 1 SHALL BE
LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY
THAT PARTNER FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN
NO EVENT SHALL oneM2M BE LIABLE FOR LOST PROFITS OR OTHER
INCIDENTAL OR CONSEQUENTIAL DAMAGES. oneM2M EXPRESSLY ADVISES
ANY AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVIDED IN
THIS DOCUMENT IS AT THE RISK OF THE USER.
47
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 2 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
48
Contents
49
Contents .............................................................................................................................................................. 3
50
1
Scope ........................................................................................................................................................ 4
51
52
53
2
References ................................................................................................................................................ 4
54
55
56
57
3
58
4
Conventions.............................................................................................................................................. 5
59
5
Use case .................................................................................................................................................... 6
60
6
Functional architecture ............................................................................................................................. 6
61
62
63
64
65
66
67
68
7
Procedures and call flows ......................................................................................................................... 7
69
70
71
72
73
74
75
76
77
78
79
8
80
9
81
82
Proforma copyright release text block ............................................................................................................. 18
83
Annex <y>: Bibliography ............................................................................................................................... 19
84
85
History .............................................................................................................................................................. 20
2.1
2.2
3.1
3.2
3.3
Normative references ......................................................................................................................................... 4
Informative references ....................................................................................................................................... 4
Definitions, symbols and abbreviations ................................................................................................... 4
Definitions ......................................................................................................................................................... 4
Symbols ............................................................................................................................................................. 5
Abbreviations ..................................................................................................................................................... 5
7.1
Overviews ......................................................................................................................................................... 7
7.2
Call flows ........................................................................................................................................................... 8
7.2.1
Registration .................................................................................................................................................. 8
7.2.2
Initial resource creation ................................................................................................................................ 9
7.2.3
Discovery and retrieval ................................................................................................................................ 9
7.2.4
PollingChannel resource creation ............................................................................................................... 10
7.2.5 Actuator switch via polling channel ...................................................................................................................... 11
8.1
8.2
8.2.1
8.2.2
8.2.3
8.2.4
8.3
8.3.1
8.3.2
8.3.3
Implementation ...................................................................................................................................... 12
Implementation assumption ............................................................................................................................. 12
Roles of entities ............................................................................................................................................... 13
oneM2M service platform (IN-CSE) ......................................................................................................... 13
Sensor applications (ADN-AE1 and ADN-AE2) ....................................................................................... 13
Actuator application (ADN-AE3) .............................................................................................................. 13
Smartphone application (ADN-AE4) ......................................................................................................... 13
Procedures........................................................................................................................................................ 13
Registration and resource creation ............................................................................................................. 13
Discovery and Retrieve .............................................................................................................................. 15
Long Polling .............................................................................................................................................. 17
Conclusions ............................................................................................................................................ 18
Annexes 19
86
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 3 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
87
1
Scope
88
89
The present document provides a simple use case for guiding application developers to develop applications using
functionalities provided by a oneM2M service platform with the scope of as follows:
90
 Objective of the use case,
91
 The architecture of the use case mapped into an oneM2M service platform,
92
 The execution procedures for implementation of the use case, and
93
 Implementation details of the use case: CoAP and JSON serialization.
94
2
References
95
The following text block applies.
96
97
98
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
99
2.1
Normative references
100
As a Technical Report (TR) is entirely informative it shall not list normative references.
101
The following referenced documents are necessary for the application of the present document.
102
Not applicable.
103
2.2
104
Clause 2.2 shall only contain informative references which are cited in the document itself.
105
106
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
107
[i.1]
108
[i.2]
oneM2M TS-0001 (V1.13.0): "Functional Architecture".
109
[i.3]
oneM2M TS-0004 (V1.5.0): "Service Layer Core protocol Specification”.
110
[i.4]
oneM2M TS-0008 (V1.4.0): "CoAP Protocol Binding".
111
[i.5]
oneM2M TS-0011: "Common Terminology".
Informative references
oneM2M Drafting Rules (http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf)
112
113
3
114
Delete from the above heading the word(s) which is/are not applicable.
115
3.1
116
Clause numbering depends on applicability.
117
Definitions, symbols and abbreviations

Definitions
A definition shall not take the form of, or contain, a requirement.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 4 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
118
119

The form of a definition shall be such that it can replace the term in context. Additional information
shall be given only in the form of examples or notes (see below).
120

The terms and definitions shall be presented in alphabetical order.
121
For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply:
122
Definition format
123
<defined term>: <definition>
124
125
If a definition is taken from an external source, use the format below where [N] identifies the external document which
must be listed in Section 2 References.
126
<defined term>[N]: <definition>
127
example 1: text used to clarify abstract rules by applying them literally
128
NOTE:
This may contain additional information.
129
3.2
130
Clause numbering depends on applicability.
131
For the purposes of the present document, the [following] symbols [given in ... and the following] apply:
132
Symbol format
133
134
135
Symbols
<symbol>
<2nd symbol>
<3rd symbol>
<Explanation>
<2nd Explanation>
<3rd Explanation>
136
3.3
137
Abbreviations should be ordered alphabetically.
138
Clause numbering depends on applicability.
139
For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:
140
Abbreviation format
141
142
143
144
145
146
147
148
149
150
151
Abbreviations
ARIB
Association of Radio Industries and Businesses
ATIS
Alliance for Telecommunications Industry Solutions
CCSA
China Communications Standards Association
ETSI
European Telecommunications Standards Institute
TIA
Telecommunications Industry Association,
TSDSI
Telecommunications Standards Development Society
TTA
Telecommunications Technology Association
TTC
Telecommunication Technology Committee
<ABBREVIATION1> <Explanation>
<ABBREVIATION2> <Explanation>
<ABBREVIATION3> <Explanation>
152
4
Conventions
153
154
The key words “Shall”, ”Shall not”, “May”, ”Need not”, “Should”, ”Should not” in this document are to be interpreted
as described in the oneM2M Drafting Rules [i.1]
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 5 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
155
5
Use case
156
157
This clause briefly describes the use case from perspective of service being provided by the oneM2M platform. The
physical device components are introduced in the current section.
158
159
The described use case enables the temperature monitoring function as well as related remote control of actuators via a
smartphone or smart tab which embeds an application that gains access to a oneM2M service platform.
160
An overview of the use case is shown in figure 5.1. The main components include:
161
-
The temperature sensors and actuators are deployed in any place as needed, and connected to a gateway.
162
163
-
The gateway connected with cloud or a remote server via the necessary communication technologies allowing the
temperature sensors and actuators to be managed remotely.
164
165
-
The cloud or remote server provides a set of services to enable the smartphone to manage the temperature sensors
and actuators such as collecting the data of sensors, and switching the actuators on/off, etc.
166
167
168
169
-
The smartphone (or a smart tab) hosts an application to manage the temperature sensors and actuators. The
application should support some functions such as discovery the deployed devices, retrieve the data of sensors, and
send control commands to actuators. For example, if the data of the temperature sensor indicates the possibility of
fire disaster, then the actuator can be triggered to provide water spray or fire alarm.
Cloud/ Server
Sensor#1
Sensor#2
Gateway
Actuator#1
Smartphone
170
171
Figure 5.1: Overview of temperature monitoring use case
172
173
6
Functional architecture
174
This clause describes the architecture of this use case with components represented by the oneM2M entity roles.
175
176
In the oneM2M, two basic types of entities are defined. One is an AE (short for Application Entity) and the other is a
CSE (short for Common Services Entity). Therefore, in this use case:
177
178
-
The sensor, actuator, and the smartphone each host an AE. The AE which resides in the Application Dedicated Node
is called ADN-AE.
179
180
-
An IN-CSE (short for Infrastructure Node CSE) is hosted in the cloud or server, and a MN-CSE (short for Middle
Node CSE) is hosted on the gateway.
181
For instance, the architecture is show in figure 6.1.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 6 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
Cloud/ Server
ADN-AE-1
Mca
Sensor#1
IN-CSE
Mca
ADN-AE-2
Sensor#2
Mca
Mcc
MN-CSE
Mca
Gateway
ADN-AE-3
ADN-AE-4
Actuator#1
Smartphone
182
183
Figure 6.1: oneM2M functional architecture of temperatue monitoring use case
184
185
186
The oneM2M defined Mca reference point is used to interface an AE and CSE, and the oneM2M defined Mcc reference
point is used to interface CSEs. Therefore, in this use case:
187
188
-
The reference point used between temperature sensor AE, actuator AE and gateway MN-CSE or Smartphone AE
and IN-CSE is Mca.
189
-
The reference point used between the gateway MN-CSE and IN-CSE is Mcc.
190
191
In summary, applications used in the current use case are classified as follows:
192
193
① ADN-AE-1: an application embedded in Sensor#1 with capabilities to monitor Sensor#1 and interact with the
gateway MN-CSE through Mca reference point;
194
195
② ADN-AE-2: an application embedded in Sensor#2 with capabilities to monitor Sensor#2 and interact with the
gateway MN-CSE through Mca reference point;
196
197
③ ADN-AE-3: an application embedded in Actuator#1 with capabilities to control Actuator#1 and interact with t
he gateway MN-CSE through Mca reference point;
198
199
200
④ ADN-AE-4: a smartphone application embedded in the smartphone device with capabilities to interact directly
with the oneM2M service platform IN-CSE through Mca reference point and thereby remotely monitor and c
ontrol Sensor#1, Sensor#2 and Actuator#1.
201
202
7
Procedures and call flows
203
7.1
Overviews
204
205
206
207
In this scenario, user can use the smartphone application to monitor the temperature data of applications embedded in
Sensor#1 and Sensor#2. Furthermore, the actuator application embedded in Actuator#1 also can be managed by the
smartphone application. To realize these functions, the deployment of the oneM2M standard in the present use case
requires procedures that are classified as follows:
208
209
① Registration: the current procedure contains sensor and actuator applications registration, gateway, and
smartphone application registration.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 7 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
210
② Initial resource creation: the current procedure contains container resource creation.
211
212
③ Discovery and retrieval: the current procedure contains discovery and retrieval of sensor applications using
resource identities through a smartphone application .
213
214
215
216
In some use cases, if the actuator application embedded in Actuator#1 is non server capable, which means it cannot be
notified by the gateway (MN-CSE). oneM2M defines the <pollingChannel> resource which represents a channel that
can be used for such situation [i.2]. The clause 7 also provides relevant procedures and call flows using
<pollingChannel> resource:
217
④ PollingChannel resource creation: The current procedure contains pollingChannel resource creation.
218
219
⑤ Actuator switch on/off: the actuator application that is discovered by and connected to the smartphone
application is able to be switched via polling channel.
220
221
7.2
Call flows
222
7.2.1
Registration
223
224
225
226
The first step is sensor and actuator application registration, gateway, and smartphone application registration.
Typically, sensors and actuators will register applications with the gateway, and then the gateway will register with the
oneM2M service platform. The smartphone applications can register with the oneM2M service platform anytime as
needed.
227
Call flows regarding the registration phase depicted in figure 7.2.1-1 are ordered as follows:
228
①
229
② Actuator applications (ADN-AE3) register with the gateway (MN-CSE).
230
③ Gateway (MN-CSE) registers with the oneM2M service platform (IN-CSE).
231
④
Sensor applications (ADN-AE1 and ADN-AE2) register with the gateway (MN-CSE).
Smartphone application (ADN-AE4) registers with the oneM2M service platform (IN-CSE).
ADN-AE1
ADN-AE2
ADN-AE3
MN-CSE
ADN-AE4
IN-CSE
Sensor application
(ADN-AE1) registers
into the gateway (MNCSE)
①-1
Sensor application
(ADN-AE2) registers
into the gateway (MNCSE)
①-2
Actuator application
(ADN-AE3) registers
into the gateway (MNCSE)
②
Gateway (MN-CSE)
registers into oneM2M
service platform (INCSE)
③
Smartphone
application (ADN-AE4)
registers into oneM2M
service platform (INCSE)
④
232
233
Figure 7.2.1-1: Registration phase call flows
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 8 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
234
After the initial resource creation process, the resource tree of MN-CSE and IN-CSE is depicted in figue 7.2.1-2.
MN-CSE
IN-CSE
ADN-AE1
MN-CSE
ADN-AE2
ADN-AE4
ADN-AE3
235
236
Figure 7.2.1-2: Resource tree of MN-CSE and IN-CSE
237
238
7.2.2
239
240
After registration, it is necessary to create container resources to store the data from sensors on the gateway.Call flows
regarding the initial resource creation phase depicted in figure 7.2.2-1 are ordered as follows:
241
242
①
Initial resource creation
Two container resources are created in the gateway (MN-CSE) to store the sensor data under the registered
sensor application ADN-AE1 and ADN-AE2, respectively.
ADN-AE1
ADN-AE2
ADN-AE3
MN-CSE
ADN-AE4
IN-CSE
container resource
creation for
sensor#1
①-1
container
resource is created
on the MN-CSE after
container resource
creation for
processing
sensor#2
①-2
container
Resource is created
on the MN-CSE after
processing
243
244
245
Figure 7.2.2-1: Initial resource creation phase call flows
246
247
7.2.3
Discovery and retrieval
248
Call flows regarding the discovery and retrieval of resources depicted in figure 7.2.3-1 are ordered as follows:
249
250
251
①
The smartphone application (ADN-AE4) periodically sends a RETRIEVE request including the parameter
filterUsage and specific filter criteria condition(s) as a query string for discovery of resources stored in the
MN-CSE of gateway.
252
253
②
The gateway (MN-CSE) responds to the smartphone application (ADN-AE4) with URIs of the discovered
resources under ADN-AE1, ADN-AE2, if any.
254
255
③
The smartphone application (ADN-AE4) sends GET requests for retrieval of the latest data from discovered
sensor resource, in this example, which is from the container1 of ADN-AE1.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 9 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
256
257
④ The gateway (MN-CSE) responds to the smartphone application (ADN-AE4) with the latest data of
sensor#1.
ADN-AE1
ADN-AE2
ADN-AE3
MN-CSE
ADN-AE4
IN-CSE
①-2
Discovery
Flow
Discover container
resource with filter
criteria
①-1
URI of discovered
resources is
responded
(container1)
②-2
Retrieve latest data
from container1
③-2
③-1
The latest data of
container1 is
responded
Request/response flow
②-1
(Temperature data)
④-1
④-2
258
259
Figure 7.2.3-1: Discovery and retrieval phase call flows
260
261
7.2.4
262
263
264
As mentioned in the clause 7.1, in some use cases, the actuator application cannot be notified by the gateway (MNCSE). oneM2M defines the <pollingChannel> resource which represents a channel that can be used for such situation
[i.2]. The clause 7.2.4 povides pollingChannel resource creation, as shown in figure 7.2.4-1:
265
266
PollingChannel resource creation
① a pollingChannel resources is created in the gateway (MN-CSE) to store the actuator status under the
registered actuator application ADN-AE3.
ADN-AE1
ADN-AE2
ADN-AE3
MN-CSE
IN-CSE
ADN-AE4
pollingChannel
resource creation
for actuator#1
①
pollingChannel
resource is created
on the MN-CSE after
processing
267
268
Figure 7.2.4-1: Initial resource creation phase call flows
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 10 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
269
270
It is assumped that applications of sensor#1 and sensor#2 are registered with MN-CSE via the process in clause 7.2.2.
So after the pollingChannel resource creation process, the resource tree of MN-CSE is depicted in figue 7.2.4-2.
MN-CSE
ADN-AE1
Container1
ADN-AE2
Container2
ADN-AE3
pollingChannel
pollingChannelURI
271
272
Figure 7.2.4-2: Resource tree of MN-CSE
273
274
7.2.5 Actuator switch via polling channel
275
276
277
278
279
280
So far, user can monitor temperature data of sensor#1 and sensor#2 by the procedures in clause 7.2.1, 7.2.2, and 7.2.3.
If the data of any temperature sensor is above the threshold, which may indicate the possibility of fire disaster, then the
actuator is able to be controlled remotely through the smartphone application accessing the oneM2M service platform
and the gateway, in order to achieve some safety management. In the clasue 7.2.4, the actuator applications is registered
with the gateway (MN-CSE), the smartphone application can discover the actuator application though the same process
in the clause 7.2.3. This clause provides the switch process via polling channel.
281
A call flow for remote control is depicted in figure 7.2.5-1 and the steps are ordered as follows:
282
283
①
284
285
286
② When the user updates the actuator state on the smartphone, the ADN-AE4 generates a request representing a
new state under the targeted pollingChannel resource of ADN-AE3 stored in the MN-CSE, which is marked
as REQ2.
287
288
③ The gateway (MN-CSE) internaly processes request and response to the ADN-AE3 with the REQ2 in content
parameter.
289
290
291
④ After processing, e.g. turning on the water spray, then the ADN-AE3 sends request REQ3 to the gateway
(MN-CSE) carrying the response “RESP2” in the content parameter, to indicate the switching requeste had
been successfully performed.
292
293
⑤
294
295
⑥ The gateway (MN-CSE) responds to the actuator application (ADN-AE3), to indicate that the response is
successfully sent.
The ADN-AE3 sends request periodically to the gateway in order to retrieve requests, which is marked as
REQ1.
The gateway (MN-CSE) responds to the smartphone application (ADN-AE4), to indicate that the status of
actuator is successfully updated.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 11 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
ADN-AE1
ADN-AE2
ADN-AE3
MN-CSE
ADN-AE4
IN-CSE
<pollingChannelURI>
Hosting CSE
REQ1: retrieve
request to
polllingChannelURI
resource
REQ2: request to
ADN-AE3 for update
actuator status
①
②-2
②-1
Internal
processing for
polling channel
RESP1: carrying
“REQ2” in
content param
Internal
processing for
updateing
③
status
REQ3: notify request to
polllingChannelURI
resource, carrying
“RESP2” in content
param
④
RESP2: update
successfully
RESP3 to ADNAE3
⑤-1
⑤-2
⑥
296
297
Figure 7.2.5-1: Actuator remote control phase call flows
298
8
Implementation
299
8.1
Implementation assumption
300
Assumptions are presented as below in order to ensure the use case can be correctly implemented.
301
 Security is not considered in the current use case;
302
 CoAP binding of oneM2M primitives is used in the current use case, required features according to [i.4];
303
 JSON serializations of oneM2M primitives is used in the current use case;
304
 Short names for the representation of the resources and attributes are used in the current use case;
305
306
307
Each oneM2M entity including AE and CSE are addressable with correct host address that can be IP addresses or
FQDN addresses resolved to IP addresses by DNS network services according to addressing rules specified in oneM2M
standards.
308
309
The IN-CSE and MN-CSE entities presented in this use case are addressable with the following identifiers, using SPrelative structure format.
310

IN-CSE:
311
 CSE-ID: /in-cse
312
 resourceName of IN-CSE’s CSEBase resource: server
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 12 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.

313
MN-CSE:
 CSE-ID: /mn-cse
314
315
resourceName of MN-CSE’s CSEBase resource: gateway
316
8.2
Roles of entities
317
8.2.1
oneM2M service platform (IN-CSE)
318
The oneM2M service platform is modelled as an IN-CSE and is responsible for
 handling the requests from smartphone ADN-AE4 and gateway MN-CSE
319
320
8.2.2
Sensor applications (ADN-AE1 and ADN-AE2)
321
Each of the sensor applications are modelled as an ADN-AE and are responsible for
322
 initializing the device,
323
 registering with the MN-CSE,
324

325
 creating content resources under containers sensor1 and sensor2 with data.
creating container resources in the MN-CSE,
326
8.2.3
Actuator application (ADN-AE3)
327
The actuator application is modelled as an ADN-AE3 and are responsible for
328
 initializing the device,
329
 registering with the MN-CSE,
330

331
8.2.4
332
333
The smartphone application is modelled as ADN-AE4, which directly communicates with the oneM2M service
platform IN-CSE and is responsible for
creating polling channel resource in the MN-CSE,
Smartphone application (ADN-AE4)
334
 initializing the monitor and control application,
335
 registering the smartphone application with the IN-CSE,
336
 discovering and displaying,
337
 accepting and executing the actuator contol commands.
338
8.3
339
8.3.1 Registration and resource creation
340
341
The following example shows an sensor application ADN-AE1 registration request and response in clase 7.2.1 using
CoAP with JSON serialization.
342
343
344
345
Procedures
CoAP Request:
Method: 0.02(POST)
Uri-Host: coap://mn.provider.com:5683
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 13 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
Uri-Path: ~
Uri-Path: mn-cse
Uri-Path: gateway
Content-Type: application/vnd.onem2m-res+json
oneM2M-TY: 2
oneM2M-FR: C
oneM2M-RQI: 0001
{
"m2m:ae":
{
"rn": "adn-ae1",
"api": "001.com.company.temsensor",
"rr": true
}
}
CoAP Response:
2.01 Created
oneM2M-RSC: 2001
oneM2M-RQI: 0002
Location-Path: /mn-cse/gateway/adn-ae1
{
"m2m:ae":
{
"ty": "2",
"ri": "ae-CAE23456789",
"pi": "/mn-cse/gateway",
"ct": "20170327T31415",
"lt": "20170327T31415",
"et": "20170927T66666",
"aei": "CAE23456789"
}
}
Then thefollowing example shows a container create request and response in the procedure of clause 7.2.2 using CoAP
with JSON serialization.
CoAP Request:
Method: 0.02(POST)
Uri-Host: coap://mn.provider.com:5683
Uri-Path: ~
Uri-Path: mn-cse
Uri-Path: gateway
Uri-Path: adn-ae1
Content-Type: application/vnd.onem2m-res+json
oneM2M-TY:3
oneM2M-FR: Cadn-ae1
oneM2M-RQI:0002
{
"m2m:cnt":
{
"rn": "container1"
}
}
CoAP Response:
2.01 Created
oneM2M-RSC: 2001
oneM2M-RQI: 0002
Location-Path: /mn-cse/gateway/adn-ae1/container1
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 14 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
414
415
416
417
418
419
Content-format: application/vnd.onem2m-res+json
Then the creation of a content instance resource under the container of ADN-AE1 with initial content is shown in the
following procedure. The following example shows a contentInstance create request and response using CoAP with
JSON serialization.:
CoAP Request:
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
According to similar procedures, ADN-AE2, ADN-AE3 and necessary resources can register with the gateway as well.
Then the gateway can register with the oneM2M service platform. The smartphone applications can register with the
oneM2M service platform anytime as needed.
467
8.3.2 Discovery and Retrieve
468
469
470
471
As mentioned in clause 7.2.3, the smartphone application (ADN-AE4) periodically sends a RETRIEVE request
including the parameter filterUsage and specific filter criteria condition(s) as a query string for discovery of resources
stored in the MN-CSE of gateway. It is assumed that the <Container1> resource with label "temp1" is created on MN
CSE.
472
473
The discovery of containers for each sensors registered with the MN-CSE by the smartphone AE is shown in the
following procedure.
474
475
Method: 0.02(POST)
Uri-Host: coap://mn.provider.com:5683
Uri-Path: ~
Uri-Path: mn-cse
Uri-Path: gateway
Uri-Path: adn-ae1
Uri-Path: container1
Content-Type: application/vnd.onem2m-res+json
oneM2M-TY: 4
oneM2M-FR: Cadn-ae1
oneM2M-RQI: 0003
{
"m2m:cin":
{
"cnf": "text/plains:0",
"con": "23"
}
}
CoAP Response:
2.01 Created
oneM2M-RSC: 2001
oneM2M-RQI: 0003
Location-Path: /mn-cse/gateway/adn-ae1/container1/cin-00000023
Content-format: application/vnd.onem2m-res+json
{
"m2m:cin":
{
"ty": "4",
"ri": "cin-00000023",
"pi": "/mn-cse/gateway/adn-ae1/container1",
"ct": "20170327T31415",
"lt": "20170327T31415",
"et": "20170927T66666",
"st": "1",
"cs": "2"
}
}
CoAP Request:
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 15 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
Method: 0.01(GET)
Uri-Host: coap://in.provider.com:5683/
Uri-Path: ~
Uri-Path: in-cse
Uri-path: server
Uri-path: gateway
Content-Type: application/vnd.onem2m-res+json
oneM2M-FR: Cadn-ae4
oneM2M-RQI: 0004
Uri-Query: fu=1
Uri-Query: ty=3
Uri-Query: lbl="temp1"
CoAP Response:
2.05
oneM2M-RSC: 2000
oneM2M-RQI: 0004
Content-format: application/vnd.onem2m-res+json
{
"m2m:uril":
[
"/gateway/adn-ae1/container1"
]
}
The smartphone application retrieves URI representing containers registered with MN-CSE from the response message,
e.g. /gateway/adn-ae1/container1 which is the URI of container created in ADN-AE1.
The smartphone application can retrieve the sensor data from ADN-AE1. If the response is preferred to be returned with
a JSON representation, the following is a CoAP request message example:
CoAP Request:
Method: 0.01(GET)
Uri-Host: coap://in.provider.com:5683
Uri-Path: ~
Uri-Path: in-cse
Uri-Path: server
Uri-Path: gateway
Uri-Path: adn-ae1
Uri-Path: container1
Content-Type: application/vnd.onem2m-res+json
oneM2M-FR: Cadn-ae4
oneM2M-RQI:0005
CoAP Response:
2.05
oneM2M-RSC: 2000
oneM2M-RQI: 0005
Content-format: application/vnd.onem2m-res+json
{
"m2m:cin":
{
"ty": "4",
"ri": "cin-00000023",
"pi": "/mn-cse/gateway/adn-ae1/container1",
"ct": "20170327T31415",
"lt": "20170327T31415",
"et": "20170927T66666",
"st": "1"
"cnf": "text/plain:0"
"cs": "2"
"con": "23"
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 16 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
543
544
545
}
}
546
8.3.3 Long Polling
547
548
549
As mentioned in clause 7.2.4, for using long polling procedures, ADN-AE3 creates <pollingChannel> resource on MNCSE. The following example shows <pollingChannel> resource create request and response using HTTP with JSON
serialization.
HTTP Request:
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
ADN-AE3 also generates a container and a content instance resource under the container of ADN-AE3, according to
the similar procedure in 8.3.1. It is assumed that a subscription to this container resource has been created using the
<pollingChannel> as a notificationURI in the subscraption.
Then user can subscribe or make a change of the actuator state on the gateway. It is assumed that the user already
subscribed this resource, so when the user makes a change to the actuator state via the smartphone user interface, the
smartphone application performs a new content instance creation procedure carrying the new state in request.
580
If the contentInstance create request body is represented in JSON, the following is a HTTP request message example:
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
POST /~/mn-cse/gateway/adn-ae3?rcn=0 HTTP/1.1
Host: http://mn.provider.com:8080
X-M2M-Origin: Cadn-ae3
Content-Type: application/vnd.onem2m-res+json;ty=15
X-M2M-RI: mncse-12345
{
"m2m:pch":
{
"rn":"actuator01"
}
}
HTTP Response:
201 Created
X-M2M-RSC: 2001
X-M2M-RI: mncse-12345
Content-Location: /mn-cse/pch-78901234
Content-Type: application/vnd.onem2m-res+json
HTTP Request:
POST /~/mn-cse/gateway?rcn=0 HTTP/1.1
Host: http://mn.provider.com:8080
X-M2M-Origin: Cadn-ae4
Content-Type: application/vnd.onem2m-res+json;ty=4
X-M2M-RI: mncse-11123
{
"m2m:cin":
{
"cnf": "text/plains:0",
"con": "ON"
}
}
HTTP Response:
201 Created
X-M2M-RSC: 2001
X-M2M-RI: mncse-11123
Content-Location: /mn-cse/cin-789356234
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 17 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
605
606
607
Then the gateway will generate a notification based on the new content instance creation procedure. Usually the
actuator (ADN-AE3) sends request periodically to the gateway in order to retrieve this notification though long polling
procedure.
608
If the request body is represented in JSON, the following is a HTTP request message example:
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
HTTP Request:
GET /~/mn-cse/gateway/adn-ae3/actuator01/pcu HTTP/1.1
Host: http://mn.provider.com:8080
X-M2M-Origin: Cadn-ae3
X-M2M-RI: mncse-11223
HTTP Response:
200 OK
X-M2M-RI: mncse-11223
{
"m2m:sgn":
{
"nev":{
"rep":
{
"cin":
{
"cnf": "text/plain:0",
"con": "ON"
}
}
},
"sur":"/mn-cse/sub-856463728"
}
}
After retrieved the notification, the states of actuator (ADN-AE3) can be updated automatically. Then the ADN-AE3
sends request to the gateway to indicate the previous notification had been successfully performed.
643
9
Conclusions
644
645
646
The current use case is realized by following the high level procedures such as registration of smart devices, gateway
with the oneM2M service platform, container resource creation, content instance retrieveal, and using polling channel
for actuator switch.
647
648
XML serialization and HTTP binding of oneM2M primitive, as well as other implementation examples are intended to
be covered in other developer guidances.
649
650
Proforma copyright release text block
651
652
This text box shall immediately follow after the heading of an element (i.e. clause or annex) containing a proforma or
template which is intended to be copied by the user. Such an element shall always start on a new page.
653
654
655
Notwithstanding the provisions of the copyright clause related to the text of the present document, oneM2M grants that
users of the present document may freely reproduce the <proformatype> proforma in this {clause|annex} so that it can
be used for its intended purposes and may further publish the completed <proformatype>.
656
<PAGE BREAK>
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 18 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
657
Annexes
658
Each annex shall start on a new page (insert a page break between annexes A and B, annexes B and C, etc.).
659
Use the Heading 9 style for the title and the Normal style for the text.
661
Annex <A>:
Title of annex (style H9)
662
<Text>
663
<PAGE BREAK>
660
665
Annex <B>:
Title of annex (style H9)
666
<Text>
667
B.1
668
<Text>
669
B.1.1
670
<Text>
671
<PAGE BREAK>
664
First clause of the annex (style H1)
First subdivided clause of the annex (style H2)
673
Annex <y>:
Bibliography
674
The annex entitled "Bibliography" is optional.
675
676
It shall contain a list of standards, books, articles, or other sources on a particular subject which are not mentioned in the
document itself.
677
It shall not include references mentioned in the document.
678
Use the Heading 9 style for the title and B1+ or Normal for the text.
672

679
<Publication>: "<Title>".
680
OR
681
<Publication>: "<Title>".
682
<PAGE BREAK>
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 19 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
683
History
684
685
This clause shall be the last one in the document and list the main phases (all additional information will be removed at
the publication stage).
Publication history
V.1.1.1
<dd Mmm yyyy> <Milestone>
686
687
Draft history (to be removed on publication)
V.0.0.1
05 October 2016
Initial skeleton
V.0.1.0
20 January 2017
Incorperated contributions:
TST-2016-0227R02-Clause_5_Use_case_introduction_of_TR-0034
TST-2016-0228R02-Clause_6_Functional_architecture_of_TR-0034
V.0.1.1
08 March 2017
Incorperated contributions:
TST-2017-0029R02-Monitoring_procedures_of_TR-0034
TST-2017-0030R03-Registration_call_flows_of_TR-0034
TST-2017-0031R02-Discovery_and_retrieval_call_flows_of_TR-0034
TST-2017-0032R02-Actuator_switch_call_flows_of_TR-0034
V.0.2.0
05 April 2017
Incorperated contributions:
TST-2017-0087R01-Implementation_and_conclusions_of_TR-0034
TST-2017-0100R01-Registration_procedures_of_TR-0034
TST-2017-0101R01- Discover_and_Retrieve_procedures_of_TR-0034
TST-2017-0103R02-Polling_Channel_procedures_of_TR-0034
688
689
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 20 of 20
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.