1

O N E M2M
TECHNICAL SPECIFICATION
Document Number oneM2M-TS-0001 oneM2M Functional Architecture-V-0.0.7
Document Name: oneM2M Functional Architecture

Date: 2013-AUGUST-26
Abstract: This document illustrates end-to-end M2M Services Architecture and
specifies the functional architecture of the oneM2M Services Platform.

5
6
7

8 oneM2M IPR and copyright statements

9 Text required
10
11

12

1 © OneM2MPartners Page 1 of 43
13 Contents
14 Contents....................................................................................................................................................2
15 1 Scope..............................................................................................................................................4
16 2 References......................................................................................................................................4
17 2.1 Normative references..................................................................................................................................4
18 2.2 Informative references................................................................................................................................4
19 3 Definitions, symbols and abbreviations..........................................................................................4
20 3.1 Definitions...................................................................................................................................................4
21 3.2 Symbols.......................................................................................................................................................5
22 3.3 Abbreviations..............................................................................................................................................5
23 4 Conventions....................................................................................................................................6
24 5 Architecture Model.........................................................................................................................6
25 5.1 General Concepts........................................................................................................................................6
26 5.2 Architecture Reference Model....................................................................................................................6
27 5.2.1 High Level Functional View.................................................................................................................6
28 5.2.2 Reference Points....................................................................................................................................7
29 5.2.2.1 X Reference Point............................................................................................................................7
30 5.2.2.2 Y Reference Point............................................................................................................................8
31 5.2.2.3 Z Reference Point............................................................................................................................8
32 6. Functional Architecture...................................................................................................................8
33 6.1 Deployment Scenarios..............................................................................................................................11
34 6.1.1 Single Middle Node case.....................................................................................................................11
35 6.1.2 Multiple Middle Nodes........................................................................................................................11
36 6.1.3 Applications located outside of Application Service Node.................................................................11
37 6.2 Common Service Functions......................................................................................................................11
38 6.2.1 Addressing and Identification..............................................................................................................12
39 6.2.1.1 General Concepts...........................................................................................................................12
40 6.2.1.2 Detailed Descriptions.....................................................................................................................12
41 6.2.2 Communication Management and Delivery Handling........................................................................12
42 6.2.2.1 General Concepts...........................................................................................................................12
43 6.2.2.2 Detailed Descriptions.....................................................................................................................12
44 6.2.3 Data Management and Repository......................................................................................................13
45 6.2.3.1 General Concepts...........................................................................................................................13
46 6.2.3.2 Detailed Descriptions.....................................................................................................................13
47 6.2.4 Device Management............................................................................................................................14
48 6.2.4.1 General Concepts...........................................................................................................................14
49 6.2.4.2 Detailed Descriptions.....................................................................................................................14
50 6.2.5 Discovery.............................................................................................................................................14
51 6.2.5.1 General Concepts...........................................................................................................................14
52 6.2.5.2 Detailed Descriptions.....................................................................................................................14
53 6.2.6 Group Management.............................................................................................................................15
54 6.2.6.1 General Concepts...........................................................................................................................15
55 6.2.6.2 Detailed Descriptions.....................................................................................................................15
56 6.2.7 Location...............................................................................................................................................16
57 6.2.7.1 General Concepts...........................................................................................................................16
58 6.2.7.2 Detailed Descriptions.....................................................................................................................16
59 6.2.8 Network Service Exposure, Service Execution and Triggering..........................................................16
60 6.2.8.1 General Concepts...........................................................................................................................16
61 6.2.8.2 Detailed Descriptions.....................................................................................................................16
62 6.2.9 Registration..........................................................................................................................................17
63 6.2.9.1 General Concepts...........................................................................................................................17
64 6.2.9.2 Detailed Descriptions.....................................................................................................................17
65 6.2.10 Security................................................................................................................................................17
66 6.2.10.1 General Concepts...........................................................................................................................17

2 © OneM2MPartners Page 2 of 43
 67 6.2.10.2 Detailed Descriptions.....................................................................................................................18
68 6.2.11 Service Charging and Accounting.......................................................................................................19
69 6.2.11.1 General Concepts...........................................................................................................................19
70 6.2.11.2 Detailed Descriptions.....................................................................................................................19
71 6.2.12 Session Management...........................................................................................................................20
72 6.2.12.1 General Concepts...........................................................................................................................20
73 6.2.12.2 Detailed Descriptions.....................................................................................................................20
74 6.2.13 Subscription and Notification..............................................................................................................21
75 6.2.13.1 General Concepts...........................................................................................................................21
76 6.2.13.2 Detailed Descriptions.....................................................................................................................22
77 6.3 Functional Entities Comprising Enablers..................................................................................................22
78 6.3 Security Aspects........................................................................................................................................23
79 6.4 Other Aspects............................................................................................................................................24
80 7. M2M Identification and Addressing.............................................................................................24
81 7.1 M2M Identifiers........................................................................................................................................24
82 7.1.1 M2M Service Provider Identifier (M2M-SP-ID)................................................................................24
83 7.1.2 Application Instance Identifier (App-Inst-ID).....................................................................................24
84 7.1.3 Application Identifier (App-ID)..........................................................................................................24
85 7.1.4 CSE Identifier (CSE-ID).....................................................................................................................24
86 7.1.5 M2M Node Identifier/Device Identifier (M2M-Node-ID)..................................................................24
87 7.1.6 M2M Service Subscription Identifier (M2M-Sub-ID)........................................................................24
88 7.1.7 Request Identifier (M2M-Request-ID)................................................................................................25
89 7.2 M2M Identifiers lifecycle and characteristics...........................................................................................25
90 8. X and Y Reference Points.............................................................................................................25
91 8.1 General Communication Flow Scheme....................................................................................................26
92 8.1.1 Description..........................................................................................................................................26
93 8.1.2 Request................................................................................................................................................26
94 8.1.3 Successful Operation...........................................................................................................................28
95 8.1.4 Unsuccessful Operation.......................................................................................................................28
96 8.2 Procedures for Accessing Resources........................................................................................................28
97 8.2.1 Generating Responses.........................................................................................................................29
98 8.2.2 Accessing Resources in CSEs.............................................................................................................29
99 9 Resource Management..................................................................................................................34
100 9.1 General Principles.....................................................................................................................................34
101 9.2 Resource Types.........................................................................................................................................34
102 9.2.1 Types of Virtual Resources.................................................................................................................36
103 9.3 Resource Addressing.................................................................................................................................36
104 9.4 Resource Structure....................................................................................................................................36
105 9.5 Resource Operations.................................................................................................................................37
106 9.5 TBD...........................................................................................................................................................37
107 10. Information Flows.........................................................................................................................37
108 10.1 General Concepts......................................................................................................................................37
109 Proforma copyright release text block....................................................................................................37
110 Annex <y>: Bibliography.....................................................................................................................40
111 History....................................................................................................................................................41
112

3 © OneM2MPartners Page 3 of 43
113 1 Scope
114 This specification describes the end-to-end oneM2M functional architecture, including the description of the functional
115 entities and associated reference points.

116 oneM2M functional architecture has focus on the Service Layer aspects and takes Underlying Network-independent
117 view of the end-to-end services. The Underlying Network is used for the transport of data and potentially for other
118 services.

119 2 References
120 References are either specific (identified by date of publication and/or edition number or version number) or
121 non-specific. For specific references,only the cited version applies. For non-specific references, the latest version of the
122 referenced document (including any amendments) applies.

123 2.1 Normative references

124 The following referenced documents are necessary for the application of the present document.

125 [1] ETSI TR 102 473: "<Title>".

126 2.2 Informative references

127 The following referenced documents are not necessary for the application of the present document but they assist the
128 user with regard to a particular subject area.

129 [i.1] oneM2M Drafting Rules

130 (http://member.onem2m.org/Static_pages/Others/Rules_Pages/oneM2M-Drafting-Rules-
131 V1_0.doc)

132 3 Definitions, symbols and abbreviations

133 3.1 Definitions

134 For the purposes of the present document, the following terms and definitions apply:

135 Application Layer: This layer comprises oneM2M Applications and related business and operational logic.

136 Common Services Layer: This layer consists of oneM2M service functions that enable oneM2M Applications (via
137 management, discovery and policy enforcement to name a few).

138 Common Services Entity: The Common Services Entity is an instantiation of Common Services Functions (CSFs).
139 Common Services Entity provides a subset of CSFs that could be used and shared by M2M Applications. Common
140 Services Entity can utilize Underlying Network capabilities and can interact with each other to fulfil the service.

141 Editor’s Note: This is a provisional definition.

142 Common Services Function: A Common Services Function (CSF) is a set of service functions that are common to the
143 M2M environment and specified by oneM2M. A CSE contains one or more CSFs.

144 Editor's Note: This definition needs some more work so that it is more clear (about the M2M environment and the
145 relationship between CSE/CSF and level of service functions.

146 Hosting CSE: The CSE where the addressed master/original resource resides.

4 © OneM2MPartners Page 4 of 43
147 Local CSE: The CSE where an Application or a CSE has registered. It is the first CSE that receives Request from an
148 Originator. For example:

149 • If an Application on an Infrastructure Node is the Originator, the Local CSE is the CSE on the
150 Infrastructure Node;

151 • If an Application on a Middle Node is the Originator, the Local CSE is the CSE on the Middle Node;

152 • If an Application on an End Node is the Originator, the Local CSE is the CSE on the End Node.

153 Editor's Note: Need to provide definition of an End Note. This is FFS.

154 Editor's Note: The concept of a CSE registering at a Local CSE needs to be understood. This is FFS.

155 Editor's Note: Review/clarify "or a CSE" in the definition of Local CSE. Should "or a CSE" be replaced with "or a
156 Node"? This is FFS.

157 Editor's Note: Need definition for "Application Entity". Need to define relationship between an Application Entity
158 and an Application.

159 M2M Service Provider Domain: It is the part of the M2M System that is associated with a given M2M Service
160 Provider.

161 Network Services Layer: Provides transport, connectivity and service functions.

162 Node: A functional entity containing one of the following:

163 • one or more M2M Applications,

164 • one CSE and zero or more M2M Applications.

165 Originator: The actor that initiates a Request. An Originator can either be an Application or a CSE.

166 Receiver: The actor that receives the Request. A Receiver can be a CSE or an Application.

167 Resource: A uniquely addressable entity in oneM2M System such as by the use of a Universal Resource Identifier
168 (URI). A resource can be accessed and manipulated by using the specified procedures.

169 Editor’s Note: The above stated definition of Resource needs to be revisited. This is FFS.

170 Editor’s Note: It is expected that more definitions are needed. This is FFS.

171 3.2 Symbols

172 <symbol> <Explanation>
173 <2nd symbol> <2nd Explanation>
174 <3rd symbol> <3rd Explanation>

175 3.3 Abbreviations

176 AE Application Entity
177 ADN Application Dedicated Node
178 AE Application Entity
179 ASN Application Service Node
180 CSE Common Service Entity
181 CSF Common Service Function
182 EF Enabler Function
183 IN Infrastructure Node
184 MN Middle Node
185 NSE Network Service Entity
186
187 The following Common Service Functions (CSFs) have been defined:

5 © OneM2MPartners Page 5 of 43
188 AID CSF Addressing and Identification CSF
189 CMDH CSF Communication Management and Delivery Handling CSF
190 DMR CSF Data Management and Repository CSF
191 DMG CSF Device Management CSF
192 DIS CSG Discovery CSF
193 GMG CSF Group Management CSF
194 LOC CSF Location CSF
195 NSE CSF Network Service Exposure, Service Execution and Triggering CSF
196 REG CSF Registration CSF
197 SEC CSF Security CSF
198 SCA CSF Service Charging and Accounting CSF
199 SMG CSF Session Management CSF
200 SUB CSF Subscription and Notification CSF
201
202

203 4 Conventions
204 The key words “Shall”, ”Shall not”, “May”, ”Need not”, “Should”, ”Should not” in this document are to be interpreted
205 as described in the oneM2M Drafting Rules [i.1]

206 5 Architecture Model

207 Editor's Note: Definitions are FFS. As definitions get refined and agreed to, the following text to be adjusted to
208 eflect the agreements

209 5.1 General Concepts

210 Figure 5.1-1 depicts the oneM2M Layered Model for supporting end-to-end (E2E) M2M Services. This layered model
211 comprises three layers: Application Layer, Common Services Layer and the Underlying Network Services Layer.

212

213
214 Figure 5.1-1: oneM2M Layered Model

215

6 © OneM2MPartners Page 6 of 43
216 5.2 Architecture Reference Model
217 5.2.1 High Level Functional View
218 Figure 5.2.1-1illustrates high level functional view of the oneM2M architecture.

219
220 Figure 5.2.1-1: High Level Functional View

221
222 Editor's Note: Applicability of this functional view to network infrastructure and /or to M2M devices is FFS.

223 The high level functional view in Figure 5.2.1-1 comprises of the following functions:

224 1. Application Entity (AE): Application Entity provides Application logic for the end-to-end M2M solutions.
225 Examples of the Application Entities can be fleet tracking application, remote blood sugar monitoring
226 application, or remote power metering and controlling application.

227 2. Common Services Entity (CSE): A Common Services Entity comprises the set of "service functions" that are
228 common to the M2M environments and specified by oneM2M. Such service functions are exposed to other
229 entities through Reference Points X and Y. Reference point Z is used for accessing Underlying Network Service
230 Entities.

231 Examples of service functions offered by CSE are: Data Management, Device Management, M2M Subscription
232 Management, Location Services etc. Such "subfunctions" offered by a CSE may be logically apprehended as
233 Common Services Functions (CSFs). Inside a Common Services Entity (CSE), some of the CSFs can be
234 mandatory and others can be optional. Also, inside a CSF, some subfunctions can be mandatory or optional (e.g.,
235 inside a "Device Management" CSF, some of the subfunctions like "Application Software Installation",
236 "Firmware Updates", "Logging", "Monitoring", etc. can be mandatory or optional).
237 3. Underlying Network Services Entity (NSE): An Underlying Network Services Entity provides services to the
238 CSEs. Examples of such services include device management, location services and device triggering. No
239 particular organization of the NSEs is assumed.

240 Note: Underlying Networks provide data transport services between entities in the oneM2M system. Such data transport
241 services are not included in the NSE.

242 5.2.2 Reference Points

243 The following reference points are supported by the CSE.

7 © OneM2MPartners Page 7 of 43
244 5.2.2.1 X Reference Point
245 This is the reference point between an Application Entity and a CSE. The X reference point shall allow an Application
246 Entity to use the services provided by the CSE, and for the CSE to communicate with the Application Entity.

247 The services offered via the X reference point are thus dependent on the functionality supported by the CSE. The
248 Application Entity and the CSE it invokes may or may not be co-located within the same physical entity.

249 5.2.2.2 Y Reference Point

250 This is the reference point between two CSEs. The Y reference point shall allow a CSE to use the services of another
251 CSE in order to fulfill needed functionality. Accordingly, the Y reference point between two CSEs shall be supported
252 over different M2M physical entities. The services offered via the Y reference point are dependent on the functionality
253 supported by the CSEs

254 5.2.2.3 Z Reference Point

255 This is the reference point between a CSE and the Underlying Network Services Entity. The Z reference point shall
256 allow a CSE to use the services (other than transport and connectivity services) provided by the Underlying Network
257 Services Entity in order to fulfill the needed functionality.

258 The instantiation of the Z reference point is dependent on the services provided by the Underlying Network Services
259 Entity.

260 Note: Information exchange between two M2M nodes assumes the usage of the transport and connectivity services of
261 the Underlying Network Services Entity, which are considered to be the basic services.

262 Editor's Note: While allowing for different instantiations of the CS Function into different functional Entities, this
263 specification follows the following guidelines/principles while specifying the interfaces on X, Y and Z
264 reference points:

265 • Specification of the interfaces on reference points X and Y are independent of the functionality
266 provided by the CSE.

267 • Specification of the interfaces on reference point Z may take into account the functionality
268 provided by the CSE.

269 6. Functional Architecture

270 Figure 6-1 illustrates the Functional Architecture for providing oneM2M services, illustrating the relations amongst the
271 functional entities in relation to the reference points identified in Figure 5.2.1-1 (High Level Functional View).

272

8 © OneM2MPartners Page 8 of 43
273
274 Figure 6-1: Functional Architecture

275
276 Node: A oneM2M Node is a functional entity that shall contain at least one oneM2M Common Services Entity or one
277 oneM2M Application Entity. A oneM2M Node may be contained in a physical object e.g., M2M device, gateway or
278 server/service infrastructure.

279 NOTES:

280 1. CSEs resident in different nodes are not identical and are dependent on the services supported by the CSE in that
281 node.

282 2. Y' reference point aims to be as similar as possible to the Y reference point. But due to the nature of inter-M2M
283 Service Provider communications, some differences are anticipated.

284 Editor's Notes:

285 • The illustration above does not provide an exhaustive list of possible configurations and is subject to
286 qualification. Other possible functions/configurations are FFS.

287 • Y' reference point aims to be as similar as possible to the Y reference point. But due to the nature of
288 inter-M2M Service Provider communications, some differences are anticipated.

289 Editor's Note:

290 - In Figure 6-1, should we explain how Application Function (AF) and Application (A) relate?

291 - should Case 1 and 2 Application Nodes have Z interfaces else should it be explained why not?

9 © OneM2MPartners Page 9 of 43
292 - Should the placement of the text "Application node" and "Device Node" in Figure 6-1 be placed to indicate
293 which applies to cases 2 and 3 ?

294 Description of Nodes:

295 oneM2M architecture foresees the following Nodes. It is important that as functional objects, such Nodes are not
296 necessarily mapped to actual physical objects, although they may be mapped to actual physical objects.

297 Application Service Node (ASN):

298 An Application Service Node is a Node that contains one Common Services Entity and contains at least one
299 Application Entity.

300 An Application Service Node may communicate over a Y reference point with either:

301 - exactly one Middle Node;

302 - or exactly one Infrastructure Node.

303 Example of physical mapping: an Application Service Node could reside in an M2M Device.

304 Application Dedicated Node (ADN):

305 An Application Dedicated Node is a Node that contains at least one Application Entity and does not contain a Common
306 Services Entity.

307 An Application Dedicated Node communicates with a Middle Node or an Infrastructure Node over an X reference
308 point.

309 Example of physical mapping: an Application Dedicated Node could reside in a constrained M2M Device.

310 Middle Node (MN):

311 A Middle Node is a Node that contains one Common Services Entity and may contain Application Entities.

312 A Middle Node communicates over a Y references point with at least two other Nodes among either (not exclusively):

313 - one or more Application Services Nodes;

314 - one or more Middle Nodes;

315 - one Infrastructure Node.

316 A Middle Node may communicate with Application Dedicated Nodes over an X reference point.

317 Example of physical mapping: a Middle Node could reside in an M2M Gateway.

318 Infrastructure Node (IN):

319 An Infrastructure Node is a Node that contains one Common Services Entity and may contain Application Entities.

320 An Infrastructure Node communicates over a Y reference point with either:

321 - one or more Middle Node(s);

322 - and/or one or more Application Service Node(s).

323 An Infrastructure Node may communicate with one or more Application Dedicated Nodes over one or more respective
324 X reference points.

325 Example of physical mapping: an Infrastructure Node could reside in an M2M Server Infrastructure.

326 Editor’s Note: as of now, It is not clear what actually differentiates the Infrastructure Node from the Application
327 Service Node or the Middle Node. It could be a minimum feature scope of its CSE that would be bigger,
328 or a particular requirement on its Z reference point. It could also be the cardinality of this Node in a
329 deployment. ( there would typically be just one).

10 © OneM2MPartners Page 10 of 43
330 6.1 Deployment Scenarios
331 In this clause various deployment scenarios are introduced based on the functional architecture in Figure 6-1.

332 6.1.1 Single MiddleIntermediate Node case

333 A single MiddleIntermediate Node is placed between an Device Node Application Dedicated Node and/or Application
334 Service Node and an Infrastructure Node.

335 6.1.2 Multiple MiddleIntermediate Nodes

336 An MiddleIntermediate Node can be connected to one or more other MiddleIntermediate Nodes. In this deployment
337 scenario, the CSE in an MiddleIntermediate Node can communicate with the CSE in another MiddleIntermediate Node
338 over the Y reference point.

339 6.1.3 Applications located outside of Device NodeApplication Service Node

340 For a node such as that illustrated in Case 3 and Case 4, Applications can be located outside of the Device Application
341 Service Node.

342 6.2 Common Service Functions

343 This clause describes the "service functions" provided by the Common Services Layer that are common to the oneM2M
344 environment. Such service functions are referred to as Common Service Functions (CSFs). The CSFs provide services
345 to the Applications via the X reference point and to other CSEs via the Y reference point. Interaction with the
346 Underlying Network Service Functions is via the Z reference point. An instantiation of a CSE in a Node comprises a
347 subset of the CSFs from the CSFs described herein.

348
349 Figure 6.2-1 Common Services Functions

350

11 © OneM2MPartners Page 11 of 43
351 6.2.1 Addressing and Identification

352 6.2.1.1 General Concepts

353 Addressing and Identification (AID) CSF provides information needed for identifying and manipulating physical and
354 logical resources in M2M environment. The logical resources are entities related to software such as Applications,
355 CSEs and Data. The physical resources are hardware related entities such as the entities in the Underlying Network and
356 M2M Devices etc.

357 The AID CSF provides for the provisioning of different types of M2M Identifiers and the association of such Identifiers
358 with M2M Applications, CSEs, M2M Devices etc.

359 6.2.1.2 Detailed Descriptions

360 AID CSF shall provide the functionality for creating and managing the Identifiers for Applications, CSEs, M2M Nodes,
361 etc. It is assumed that the "Application Identifier" and the "CSE Identifier" have been assigned initially and are known
362 before M2M System boot up.

363 The AID CSF shall provide the capability to support other CSFs e.g., Registration CSF and Security CSF.

364 The AID CSF shall provide the capability to associate identifiers with the information required for M2M services. This
365 capability may be used during the M2M System boot up or CSE initialization, including the association of the
366 Underlying Network Identifiers or External Identifiers with CSE Identifiers and/or with Application Identifiers.

367 6.2.2 Communication Management and Delivery Handling

368 6.2.2.1 General Concepts

369 The Communication Management and Delivery Handling (CMDH) CSF is responsible for providing communications
370 with other CSEs, AEFs and NSEFs .

371 The CMDH CSF is responsible to decide at what time which communication connection to use for delivering
372 communication (e.g. CSE-to-CSE communication) and, when needed and allowed, store communication requests so
373 that they can be forwarded at a later time. This processing in the CMDH CSF has to be carried out in line with the
374 provisioned policies and delivery handling parameters that can be specific to each request for communication.

375 For communication using the Underlying Network data transport services, the Underlying Network can support the
376 equivalent delivery handling functionality. In such case the CMDH CSF is able to use the Underlying Network, and it
377 may act as a front end to access the Underlying Network equivalent delivery handling functionality.

378 6.2.2.2 Detailed Descriptions

379 The services that other CSFs, AFs or NSFs can request from the CMDH CSF is to transport some given data to a
380 specific target (CSE, AF or NSF), according to specific delivery instructions while staying within the constraints of
381 provisioned communication management and delivery handling Policies.

382 The content of the data provided by the requestor shall be opaque to the delivery handling function and shall not
383 influence the behaviour of the CMDH. In particular, the CMDH CSF shall not be aware of the specific destination
384 function (CSF) within the target entity including the parameters of such a function. For instance if the destination of the
385 data to be delivered is a DMR CSF within a target entity (CSE, NSF, AF), the CMDH CSF shall not be aware of the
386 DMR CSF including the specific storage location or other parameters pertaining to that DMR CSF. That means all
387 attributes that are intended to be shared with the destination function (e.g., which CSF is the destination on the target
388 entity, what that CSF should do with the data etc.) should be hidden from the CMDH CSF.

389 The target entity may be reached either directly or via the CSE of a Middle Node.

390 Editor’s Note: For Rel-1 it would probably make sense to limit to one Middle Node along the path since we need to
391 define how to handle routing which could become more complex and should be able to be added at a later
392 stage without or with little impact on the message exchanges.

12 © OneM2MPartners Page 12 of 43
393 The delivery instructions that are given to the CMDH CSF shall set the limits in the delivery process that the requestor
394 is capable of accepting. For instance those instructions can contain acceptable delay tolerance etc.

395 In line with provisioned policies and delivery instructions that can be specific to each communication request, the
396 CMDH CSF shall decide at what time which communication path to use for delivering the communication (e.g. CSE-to-
397 CSE communication) and, when needed and allowed, store communication requests so that they can be forwarded at a
398 later time.

399 As a consequence the CMDH CSF shall need to be aware of the already established connections to other Nodes via the
400 Underlying Networks, request establishment of new connections and tear down existing ones.

401 In order to accomplish this function, the CMDH CSF shall need to have access to provisioned delivery handling
402 policies and shall need to parse them so that a proper use of buffers for store-and-forward processing can be managed.

403 Editor’s Note: Clarification of complexity impacts due to use of multiple Underlying Networks are FFS.

404 6.2.3 Data Management and Repository

405 6.2.3.1 General Concepts

406 One of the goals of oneM2M CSEs is to enable M2M Applications to exchange data with each other.

407 Data Management and Repository (DMR) CSF is responsible for providing data storage and mediation functions. It
408 includes the capability of collecting and aggregating large amounts of data, converting this data into a specified format,
409 and storing it for analytics and semantic processing. The "data" can be either raw data transparently retrieved from an
410 M2M Device, or processed data which is calculated and/or aggregated by M2M entities. This collection of large
411 amounts of data constitutes what is known as the Big Data Repository functionality.

412 6.2.3.2 Detailed Descriptions

413 DMR CSF shall provide the capability to store data such as Application data, subscriber information, location
414 information, device information, semantic information, communication status, access permission, etc. The "data" stored
415 by the DMR CSF enables management of the data and provides the foundation of Big Data. Further, the DMR CSF
416 shall be able to support the physical replacement of M2M Devices and/or Gateways in terms of the stored data.

417 The DMR CSF shall support transfer of data to/from the AEFs, other CSFs and remote CSEs. The DMR CSF shall
418 support transfer of data regardless of the peer entity being on-line or not. The DMR CSF shall support operations such
419 as Create, Read, Update and Delete. The DMR CSF may associate event categorization (e.g., normal, urgent) with the
420 data for supporting differentiated services. External entities such as AFs, other CSFs or remote CSEs shall be able to be
421 granted access to the data in the DMR CSF based on defined policies.

422 Editor's Note: Needs to clarify what is meant by "peer entity" being on-line or not. Is the reference to peer-CSE or
423 something more than that.

424 The organization of the data helps describe how they relate with each other and how they are addressed. DMR CSF
425 shall allow removal, addition, search of the data. The DMR CSF shall support structured data. Some structures may be
426 specified by oneM2M, others may not. Elements of data stored in the DMR CSF shall be uniquely addressable.

427 The DMR CSF shall support aggregating the data from the same device or from different devices.

428 The DMR CSF shall enable the sharing of the data amongst local CSFs, remote CSEs and AFs.

429 Contextual information such as data types, semantic information, time stamps, location etc. shall complement the data
430 stored by the DMR CSF. This will allow the DMR CSF to access and search the data based on a rich set of parameters.
431 The DMR CSF shall be able to trigger data processing based on access to its data.

432 Semantic information needs to be available on the data that are transferred within the oneM2M system. The DMR CSF
433 shall provide functions annotating such semantic information to M2M data and exposing M2M resources using the
434 semantic information so that the M2M resources can be discovered by applications that do not have prior knowledge of
435 them. The DMR CSF shall be responsible for enabling applications to discover, interpret and use M2M data from
436 different sources.

437 Editor's Note: Semantics related capabilities are FFS subject to discussions in MAS (WG5) WG.

13 © OneM2MPartners Page 13 of 43
438 6.2.4 Device Management

439 6.2.4.1 General Concepts

440 Device Management (DMG) CSF enables the management of device capabilities including one or more of the
441 following:

442 • Application Software installation and settings;

443 • Configuration settings and Provisioning;

444 • Firmware Updates;

445 • Logging, Monitoring, Diagnostics;

446 • Topology Management of Area Networks;

447 • Devices within an Area Network Management.

448 Note: Such device management capabilities aremay be assigned to one or more Execution Environments within the
449 Device, and access to such Execution Environments is controlled through delegation via Role based permissions.

450 6.2.4.2 Detailed Descriptions

451 The DMG CSF shall provide capabilities for the purpose of managing M2M Devices/Gateways as well as devices in
452 M2M Area Networks. Such capabilities shall include:

453 • Application Software installation and settings;

454 • Configuration settings and Provisioning;

455 • Firmware Updates;

456 • Logging, Monitoring, Diagnostics;

457 • Topology Management of Area Networks;

458 • Devices within an Area Network Management.

459 Note: Such device management capabilities are assigned to one or more Execution Environments and access to such
460 Execution Environments is controlled through Role based permissions.

461 The DMG CSF shall be able to interact with a Device Management Server for managing M2M Devices/Gateways as
462 well as with devices in the M2M Area Networks that are provisioned with Management Clients.

463 Editor's Note: Need to provide definition of Execution Environment, Device Management Server, Management
464 Clients, Role based permissions.

465 6.2.5 Discovery

466 6.2.5.1 General Concepts

467 Discovery (DIS) CSF is responsible for searching information/resources according to a "request" from an
468 Originatorissuer within a given scope and subject to permissions, including those allowed by M2M service subscription.
469 An Originatorissuer could be an Application or another CSE. The scope of the search could be in one CSE, or in more
470 than one CSE. The discovery results are returned back to the Originatorissuer.

471 6.2.5.2 Detailed Descriptions

472 DIS CSF shall provide discovery of information/resources residing in its own CSE subject to permissions including the
473 M2M service subscription. The DIS CSF shall be able to support various discovery methods through the use of "filter
474 criteria" that can limit the scope of information/resources that are returned based on various filters (e.g. keyword,
475 identifiers, location, semantic information) or a combination of such filters.

14 © OneM2MPartners Page 14 of 43
476 The DIS CSF shall be triggered by sending a "request" to the address (e.g., URI) of the discovery resource. Upon
477 receiving such request, the DIS CSF shall identify and return the matching information/resources. A successful response
478 may include the actual discovered information or address(es) (e.g., URI(s)) pertaining to the discovered resources. In
479 addition, based on the policies or Originatorissuer request, the CSE which received the Discovery request may forward
480 the request to other CSEs on its registered Middle/Infrastructure Node.

481 6.2.6 Group Management

482 6.2.6.1 General Concepts

483 Group Management (GMG) CSF is responsible for handling Group related requests. The request is sent for the
484 management of a Group and its membership as well as for the bulk operations supported by the Group. When adding or
485 removing members to/from a Group, it is necessary to validate if the member complies with the purpose of the Group.
486 Bulk operations includes read, write, subscribe, notify, device management, etc. Whenever a request or a subscription is
487 made via the Group, the Group is responsible for aggregating its responses and notifications. The members of a Group
488 can have the same role with regards to access rights control towards a resource. In this case, access control is facilitated
489 by grouping. When the Underlying Network provides broadcasting and multicasting capability, the GMG CSF is able to
490 utilize such capability.

491 6.2.6.2 Detailed Descriptions

492 GMG CSF shall be responsible for the management of a Group and its membership. The GMG CSF shall support bulk
493 operations to multiple resources of interest and aggregate the results. The GMG CSF shall be able to facilitate access
494 control based on grouping. When needed and available, the GMG CSF may leverage the existing capabilities of the
495 Underlying Network including broadcasting/multicasting.

496 The GMG CSF handles requests from Applications and/or from other CSEs.

497 Grouping enables the oneM2M system to perform bulk operations to multiple devices, applications, or resources. The
498 GMG CSF shall manage the resources and operations associated with grouping.

499 The GMG CSF shall handle the requests to create, query, update, and delete a Group. An Application or a CSE may
500 request the creation/retrieve/update/deletion of a Group as well as the addition and deletion of members of the Group.
501 The GMG CSF shall be able to create one or more Groups in CSEs in any of the Nodes in oneM2M System for a
502 particular purpose (i.e. facilitation of access control, device management, fan-out common operations to a group of
503 devices, etc.). The GMG CSF shall handle the requests to retrieve the information (e.g. URI, metadata, etc.) of a Group
504 and its associated members.

505 The GMG CSF shall manage Group membership. The GMG CSF shall handle requests to add or remove members to
506 and from a Group’s member list. A member may belong to one or more Groups. A Group may be a member of another
507 Group. When new members are added to a Group, the GMG CSF should validate if the member complies with the
508 purpose of the Group.

509 In order to fulfil the functionalities of the GMG CSF, functionalities from other CSFs may be needed. Examples include
510 Network Service Exposure CSF for leveraging broadcasting/multicasting capability from the Underlying Network,
511 Security CSF for authentication and authorization etc.

512 Editor’s Note: How the Underlying Network supports broadcasting/multicasting is FFS.

513 When facilitating access control using a Group, only members with the same access rights towards a resource shall be
514 included in the same Group. Also, only M2M Applications or CSEs which have a common role with regards to access
515 rights shall be included in the same Group. This shall be used as a representation of the "role" when facilitating role
516 based access control.

517 Editor's Note: Suggest adding description on what is meant by Group member, what entities can be members of a
518 Group? Can a Group consist of heterogeneous members?

519 The GMG CSF shall forward requests to all members in the Group. In case the Group contains another Group as a
520 member, the forwarding process shall be done recursively, i.e. the nested Group shall forward the request to its
521 members. After forwarding the request to all members in the Group, the GMG CSF shall generate an aggregated
522 response by aggregating the corresponding responses from the Group members.

15 © OneM2MPartners Page 15 of 43
523 Editor’s Note: The structure of the resource in oneM2M System is FFS.

524 The GMG CSF shall support subscriptions to individual Groups. Subscriptions to a Group shall be made only if the
525 subscriber is interested in all members of the Group. If subscription to a Group is made, the GMG CSF shall aggregate
526 the notifications from the Group members, and it shall notify the subscriber with the aggregated notification. Responses
527 and event notifications relevant to a subscription may be selectively filtered by filtering criteria. The filtering criteria
528 shall be managed by the GMG CSF. In order to subscribe to or query a Group, methods for group discovery shall be
529 provided.

530 Editor's Note: Methods used for subscribing to and for querying a Group are FFS.

531 6.2.7 Location

532 6.2.7.1 General Concepts

533 The Location (LOC) CSF allows M2M Applications to obtain geographical location information of M2M entities (e.g.,
534 M2M Devices and Gateways) for location-based services. Such location information requests may be from M2M
535 Applications residing on either the same or on different M2M Nodes. The location information provided depends on the
536 location technology available on the M2M Node and/or on the location-criterion specified in the location "request".

537 Note: Geographical location information can be more than simply the longitude and the latitude information.

538 6.2.7.2 Detailed Descriptions

539 LOC CSF shall obtain and manage geographical location information based on the requests from M2M Applications
540 residing on either the same or on different M2M Nodes. The LOC CSF shall interact with either the location server in
541 the Underlying Network, or with a GPS module in the M2M device to obtain the geographical location information.

542 Note: The location technology (e.g., Cell-ID, Assistant-GPS, and Fingerprint) used by the Underlying Network depends
543 on the capabilities of the Underlying Network.

544 The LOC CSF shall be able to request M2M Devices and M2M Gateways to share and report their own or other M2M
545 device's geographical location information with the requesting M2M Applications.

546 Editor's Note: Define what is meant by M2M Devices and Gateways. Provide association between M2M Devices
547 and Gateways and the various types of Nodes defined in the functional architecture.

548 The LOC CSF shall provide means for protecting the privacy and confidentiality of geographical location information.

549 Editor’s Note: Details of the protection of privacy (e.g. obtaining the consent) is FFS.

550 6.2.8 Network Service Exposure, Service Execution and Triggering

551 6.2.8.1 General Concepts

552 Network Service Exposure, Service Execution and Triggering (NSE) CSF manages communications with the
553 Underlying Networks for accessing network service functions over the Z reference point. The NSE CSF uses the
554 available/supported methods for service "requests" on behalf of M2M Applications. The NSE CSF shields other CSFs
555 and AFs from the specific technologies and mechanisms supported by the Underlying Networks.

556 Note: The NSE CSF provides adaptation for different set of network service functions supported by various Underlying
557 Networks.

558 The network service functions provided by the Underlying Network include service functions such as, but not limited
559 to, device triggering, small data transmission, location notification, policy rules setting, location queries, IMS services,
560 device management, etc. Such services do not include the general transport services.

16 © OneM2MPartners Page 16 of 43
561 6.2.8.2 Detailed Descriptions
562 NSE CSF shall manage communication with the Underlying Networks for obtaining network service functions on
563 behalf of other CSFs, remote CSEs or M2M Applications. The NSE CSF shall use the Z reference point for
564 communicating with the Underlying Networks.

565 Note: The network services provided by the Underlying Networks include services such as, but not limited to, device
566 triggering, small data transmission, location notification, policy rules setting, location queries, IMS services, device
567 management, etc. Such services do not include general transport services.

568 The M2M system shall allow the Underlying Networks to control network service procedures and information exchange
569 over the Underlying Networks while providing such network services. For example, for the 3GPP networks, the
570 Underlying Network may chose to provide the network services based on control plane signalling mechanisms.

571 Other CSFs in a CSE that need to use the services offered by the Underlying Network shall use the NSE CSF.

572 The NSE CSF shall shield other CSFs and AFs from the specific technology and mechanisms supported by the
573 Underlying Networks.

574 Note: The NSE CSF provides adaptation for different set of network service functions supported by various Underlying
575 Networks.

576 The NSE CSF shall maintain over the Z reference point, the necessary connections and/or sessions between the CSE
577 and the Underlying Network when local CSFs are in need of a network service.

578 The NSE CSF shall provide to the CMDH CSF information related to the Underlying Network so the CMDH CSF can
579 include them to determine proper communication handling.

580 6.2.9 Registration

581 6.2.9.1 General Concepts

582 Registration (REG) CSF is responsible for handling an Application or another CSE to register with a CSE in order to
583 allow the registered entities to use the services offered by the registered-with CSE. The REG CSF handles registration
584 of a Device also, so as to allow registration of Device's properties/attributes with the CSE.

585 6.2.9.2 Detailed Descriptions

586 The CSE on a Device or on a Middle Node shall perform registration with the CSE in the Infrastructure Node in order
587 to be able to use M2M services offered by the CSE in the Infrastructure Node. An Application on a Device or on a
588 Middle Node shall perform registration locally with the corresponding CSE in order to use M2M services offered by
589 that CSE. The same holds for the registration of an Application on the Infrastructure Node. An Application on an
590 Infrastructure Node shall perform registration locally with the associated CSE on Infrastructure Node. A registered
591 Application shall be able to have interactions with its local CSE without the need to have the local CSE registered with
592 other CSEs. Such registrations are applicable to a single M2M Service Provider dDomain.

593 A CSE on a Device or on a Middle Node shall perform registration with the CSE on an Infrastructure Node and vice
594 versa. As a result of successful CSE registration, the CSEs on Device/Middle Node and Infrastructure Node establish a
595 peering relationship and shall be able to exchange context information.

596 A (physical) Device shall be able to register with its local CSE for registering its properties/attributes. Such registration
597 enables correlation of Devices Identities such as M2M-Node-ID with the CSE-ID.

598 Editor’s Note: The need for Device Registration and the relationship with CSE Registration are FFS.

599 Editor’s Note: The use of External ID in Registration is FFS.

600 6.2.10 Security

601 6.2.10.1 General Concepts

602 Security (SEC) CSF comprises the following functionalities:

17 © OneM2MPartners Page 17 of 43
603 • Sensitive Data Handling functionality;

604 • Security Administration functionality;

605 • Security Association Establishment functionality;

606 • Authorization and Access Control functionality;

607 • Identity Protection Functionality.

608 Sensitive Data Handling functionality in the SEC CSF protects the local credentials on which security relies during
609 storage and manipulation. Sensitive Data Handling functionality performs other sensitive functions as well such as
610 security algorithms. This functionality is able to support several cryptographically separated security environments.

611 Security Administration functionality enables services such as the following:

612 • Creation and administration of dedicated security environment supported by Sensitive Data Handling
613 functionality;

614 • Post-provisioning of a root credential protected by the security environment;

615 • Provisioning and administration of subscriptions related to M2M services and M2M application services.

616 Security Association Establishment functionality is responsible for establishing security association between
617 corresponding M2M nodes, in order to provide services such as confidentiality, integrity, authentication, authorization,
618 etc.

619 Authorization and Access Control functionality is responsible for authorizing services and data access to authenticated
620 entities, according to provisioned security policies and assigned roles.

621 While unique identifier of an entity are used for authentication, the Identity Protection functionality provides
622 pseudonyms which serve as temporary identifiers which cannot be linked to the true identity of either the associated
623 entity or its user.

624 6.2.10.2 Detailed Descriptions

625 SEC CSF shall comprise the following functionalities:

626 • Sensitive Data Handling functionality;

627 • Security Administration functionality;

628 • Security Association Establishment functionality;

629 • Authorization and Access Control functionality;

630 • Identity Protection Functionality.

631 Sensitive Data Handling Functionality in the SEC CSF shall have the capability to protect the local credentials on which
632 security relies during storage and manipulation. The SEC CSF shall be able to extend sensitive data handling
633 functionality to other sensitive data used in the M2M systems such as subscription related information, security policies
634 and personal data pertaining to individuals. The Sensitive Data Handling functionality shall perform other sensitive
635 functions as well, such as security algorithms. The Sensitive Data Handling functionality shall be able to support several
636 cryptographically separated security environments.

637 Security Administration functionality in the SEC CSF shall enable the following services:

638 1. Creation and administration of a dedicated security environment supported by Sensitive Data Handling
639 functionality;

640 2. Post-provisioning of a root credential protected by the security environment;

641 Note: The security environment can also be pre-provisioned with a root credential prior to deployment;
642 therefore this capability is not always required. Post-provisioning is required when the security
643 bootstrapping needs to be performed or re-initiated after deployment.

18 © OneM2MPartners Page 18 of 43
644 3. Provisioning and administration of subscriptions related to M2M services and M2M application services.
645 Besides the root secret, a subscription includes other information classified as sensitive data such as
646 associated authorization and security policies.

647 Security Association Establishment functionality in the SEC CSF shall be able to establish security associations
648 between corresponding M2M nodes, in order to provide specific security services (e.g. confidentiality, integrity,
649 authentication, authorisation, or support for application level signature generation and verification) involving specified
650 security algorithms and sensitive data. This involves key derivation based on provisioned root secrets. This functionality
651 of the SEC CSF is mandatory when security is supported.

652 Editor's Node: The definition of Security Association will be provided by WG4. A definition may be: "Security
653 associations (SAs) are logical relationships between 2 entities that may be associated with a
654 communications link, but SAs are not communications links. Security associations may take a number of
655 forms but in each case they identify the nature of the security service (confidentiality, integrity,
656 authentication or authorisation), the required algorithm and key. Security associations may be
657 established for single transactions (and thus their establishment may form part of the transaction itself)
658 or for session based associations (in such instances the association is generally established independently
659 of the individual transactions that are to be secured)".

660 The Authorization and Access Control functionality in the SEC CSF shall be able to authorize services and data access
661 to authenticated entities, according to provisioned security policies and assigned roles. This functionality is mandatory
662 when any services relying on authorization and access control are present. Among other usages, the services of this
663 functionality may be applied to personal information as a means to preserve privacy.

664 Although an M2M system User is generally considered to be an application or functional agent that represents a human,
665 there are links between a device and its User that can be either directly derived or indirectly deduced. Consequently,
666 identifiers used for communication in the M2M system shall not be directly related to the real identity of either the
667 device or its User, except where this is a requirement for operation of a specific M2M application.

668 While the unique identifier of an entity shall be used for authentication, the identity protection functionality provides
669 pseudonyms which serve as temporary identifiers which shall not be able to be linked to the true identity of either the
670 associated entity or its user.

671 6.2.11 Service Charging and Accounting

672 6.2.11.1 General Concepts

673 Service Charging and Accounting (SCA) CSF provides charging functions for the Service Layer. It supports different
674 charging models which include online charging and offline charging. The SCA CSF is responsible for capturing
675 chargeable events, recording of information, generating charging records and charging information. The SCA CSF can
676 interact with the charging system in the Underlying Network also. But the SCA CSF is responsible for generating and
677 recording of the final service level charging information. It is the responsibility of the SCA CSF in the Infrastructure
678 Node or the Service Layer Charging Server to handle the charging information for the purpose of charging.

679 Editor's Node: To provide more information Service Layer Charging Server. What is this entity?

680 6.2.11.2 Detailed Descriptions

681 SCA CSF shall perform information recording corresponding to a chargeable event. The SCA CSF shall be able to
682 handle the charging information for the purpose of charging. The SCA CSF shall be able to send the charging
683 information transformed from the specific recorded information to the charging server by the use of a standard or
684 proprietary interface for charging purposes.

685 The SCA CSF shall support "independent service layer charging" and "correlated charging with the Underlying
686 Network" charging system. For independent service layer charging, only charging functions in the Service Layer shall
687 be involved. For correlated charging, charging functions in both the Service Layer and the Underlying Network shall be
688 involved.

689 The SCA CSF shall support one or multiple charging models, such as the follows:

690 • Subscription Based Charging: A service subscriber is charged based on Service Layer subscriptions.

19 © OneM2MPartners Page 19 of 43
691 • Event Based Charging: Charging is based on Service Layer chargeable events. A chargeable event refers to
692 the discretenon-continuous transactions. For example, an operation on data (Create, Update, Retrieve) can
693 be an "event". Chargeable events shall be configurable.

694 • Session Based Charging: Charging is based on an M2M service session, such as based on secure service
695 connections.

696 • Service Based Charging: Service Layer can support charging based on the services it provides. A service
697 may require multiple transactions and the requestor is charged based on the services it received.

698 Two types of service layer charging shall be able to be supported: Online and Offline charging. Offline charging does
699 not affect services provided in real time. Charging triggering information is generated at the CSFs where the chargeable
700 transaction happens. The charging report is passed via different nodes to the network to generate CDRs. Online
701 charging affects the services granted in real time. A service request is first generated and the requestor’s credit is
702 checked before the service is granted.

703 Editor's Note: Online charging items is FFS.

704 The Service Layer charging system shall consist of the following logical functions:

705 • Charging Triggering Function: This function shall reside in the Service Layer and shall be able to capture
706 the chargeable event and generate recorded information for charging. Recorded information may contain
707 mandatory and optional elements.

708 Editor's Note: The system may record information for other purposes also such as for Event Logging. Some of such
709 information may be applicable for charging purposes.

710 • Offline Charging Function: This function shall handle offline charging related operations. It shall generate
711 charging information, such as Service Layer Charging Data Record (CDR)s. CDRs are formatted collection
712 of information about a chargeable event (e.g. amount of data transferred) for use in billing and accounting.

713 • Online Charging Function: This function shall handle online charging related operations.

714 • Charging Management Function: This function shall handle charging related policies, configurations, inter-
715 node charging function communications, and interacting with the charging system in the Underlying
716 Network.

717 6.2.12 Session Management

718 6.2.12.1 General Concepts

719 An M2M service session is an end-to-end Service Layer connection managed by the Session Management (SMG) CSF.
720 The SMG CSF manages M2M service sessions between M2M Applications, between an M2M Application and a CSE,
721 or between CSEs.

722 Editor's Note: Provide information as to when an M2M service session is needed.

723 The management of a M2M service session includes capabilities such as the management of session state, session
724 authentication and establishment, management of Underlying Network connections and services related to the session,
725 coordination of sessions spanning multiple hops of CSEs, exchange of information between session endpoints, and
726 session termination.

727 The SMG CSF uses the CMDH CSF within its local CSE for sending/receiving messages to/from the next-hop CSE or
728 to/from an Application for a given M2M service session. The SMG CSF also uses the SEC CSF for the management of
729 session related security credentials and authentication of session participants. The SMG CSF generates session specific
730 charging events also that it communicates to the SCA CSF within its local CSE.

731 6.2.12.2 Detailed Descriptions

732 An M2M service session is an end-to-end Service Layer connection managed by the SMG CSF. The SMG CSF shall
733 support the management of the following M2M service session related information.

734 • Session ID: Used by the SMG CSF and session endpoints to uniquely identify M2M service layer session.

20 © OneM2MPartners Page 20 of 43
735 • Session Credentials: Security credentials associated with M2M service session. For example, E2E security
736 certificates, public keys, etc. An M2M service session can support an independent set of credentials or it
737 can optionally leverage security credentials from Underlying Network sessions or network connections.

738 • Session Descriptor: Information describing the M2M service session that can be used by the existing
739 session endpoints or prospective session participants in order to discover an existing session. For example,
740 a description for each session participant (e.g. device identifiers, type of participant, services that
741 participant supports, interface requirements of participant, type of compression used, etc.).

742 • Session Routing Information: Information describing how to route M2M service session messages. For
743 example, list of CSEs in the routing path, or next-hop CSE in the routing path.

744 • Session Context/History: Information related to M2M service session activity such as session related events
745 that have occurred or transactions that have been processed. For example, keeping track of the type,
746 number, rate, size, etc. of the resources targeted by the session endpoints. Or keeping track of different
747 service sessions that a specific application establishes (e.g. rate, type, etc).

748 • Session Policies: Policies that define rules for how SMG CSF manages sessions. For example, session
749 routing policies, session store-and-forward policies, session access control policies, session data
750 management policies, etc. The SMG CSF can use these policies by itself or provide such policies to other
751 CSFs (e.g. CMDH CSF, DMR CSF, SEC CSF, etc).

752 Some M2M sessions may require security. In order to secure an M2M session, proper security credentials shall be used
753 by session endpoints (e.g., M2M Applications and/or CSEs). If M2M session credentials are not pre-provisioned, the
754 SMG CSF shall support securely bootstrapping of the session credentials to the session endpoints. The SMG CSF shall
755 use the SEC CSF for supporting such bootstrapping. The SMG CSF may also leverage security credentials and trust
756 relationships from Underlying Networks.

757 The SMG CSF shall support requests to establish an M2M service session between M2M Applications, between an
758 M2M Application and a CSE, or between CSEs. Before a request to establish an M2M service session is granted, the
759 SMG CSF shall first authenticate the requester using session credentials. The SMG CSF shall use the SEC CSF to
760 support session authentication. Once authenticated, the SMG CSF shall establish the M2M session between the
761 requesting and targeted session endpoints. This shall involve the SMG CSF coordinating with the targeted session
762 endpoint on an agreed upon session ID that can be used to identify the session messages. The SMG CSF shall return
763 this session ID to the requester. The SMG CSF shall also maintain additional session information for the management
764 of the session such as session policies, session routing information, session descriptor, etc.

765 The SMG CSF shall support layering of a M2M service session over the top of Underlying Network connections. The
766 SMG CSF shall support persistency of the M2M sessions with respect to the Underlying Network connections. The
767 SMG CSF shall maintain an active M2M session independent of the state of the Underlying Network connections and
768 shall be robust to network connections that are dynamically torn-down and re-established. The SMG CSF shall support
769 initiating or providing input to other CSFs and/or the Underlying Network on whether the network connections should
770 be torn-down/re-established based on M2M session activity or state.

771 The SMG CSF shall support requests to terminate an M2M service session between M2M Applications, between an
772 M2M application and a CSE, or between CSEs. Before a request to terminate an M2M service session is granted, the
773 SMG CSF shall first authenticate the requester using session credentials. The SMG CSF shall use the SEC CSF to
774 support session authentication. Once authenticated, the SMG CSF shall terminate the M2M session between the
775 requesting and targeted session endpoints. This shall involve removal of session information on the session endpoints as
776 well as the SMG CSF.

777 The SMG CSF shall support M2M sessions that span multiple intermediate CSE hops. The SMG CSF shall leverage the
778 SEC CSF on its local CSE as well the SMG CSF and the SEC CSF on intermediate CSEs to support multi-hop M2M
779 sessions. In doing so, SMG CSFs on different CSEs shall support coordinated M2M session management. This includes
780 bootstrapping of session credentials, session authentication and establishment, management of underlying network
781 connections and services related to the session, management of session routing information, and session termination
782 across multiple SMG CSFs.

783 Editor' Note: Security related descriptions for this CSF need to be updated.

784 Editor' Note: The session involves Z reference point or does it involve X and Y reference points as well. This is
785 FFS.

21 © OneM2MPartners Page 21 of 43
786 6.2.13 Subscription and Notification

787 6.2.13.1 General Concepts

788 The Subscription and Notification (SUB) CSF is responsible for providing notifications pertaining to a subscription that
789 tracks changes on a resource (e.g., delete a resource). A subscription to a resource is initiated by an M2M Application
790 or a CSE, and is granted by the hosting CSE subject to access rights. During an active subscription, the hosting CSE
791 sends a notification to the ownerissuer of the subscription to notify of a change on the subscribed-to resource.

792 Editor’s Note: Determining subscribe-able resources is FFS.

793 6.2.13.2 Detailed Descriptions

794 SUB CSF shall manage subscriptions to resources, subject to access rights, and send corresponding notifications to the
795 ownerissuer of the subscriptions. An M2M Application or a CSE shall be the ownerissuer of a subscription. An M2M
796 Application shall be able to subscribe to a resource on a local CSE or on a remote CSEs. A CSE shall be able to
797 subscribe to resources ion multiple CSEs. A subscription hosting CSE shall send a notification to the ownerissuer of the
798 subscription per modification on a resource.

799 A subscription request shall include subscription ownerissuer ID, the hosting CSE ID and subscribed-to resource
800 address (e.g., URI). It may also include a criteria e.g., to specify the interested modifications and the address (e.g., the
801 URI) where to send the notifications.

802 A single subscription can subscribe a single resource. Multiple resources shall be able to be subscribed via a single
803 subscription when they are grouped and represented as a single group resource. However, there may be resources that
804 cannot be subscribed to.

805 A subscription is represented as "subscription resource" in CSE resource structure.

806 Editor’s Note: The resource structure is yet to be agreed to. How Subscription resource is represented is FFS.

807 6.3 Functional Entities Comprising Enablers

808 Figure 6.3-1 illustrates the architecture of the Common Services Entity (CSE). The CSE comprises of a set of Common
809 Service Functions (CSFs) and a set of Enabler Functions (EFs).

810

811
812 Figure 6.3-1 Common Service Entity Architecture

22 © OneM2MPartners Page 22 of 43
813
814 Figure 6.3-2 illustrates an example of CSFs and EFs within the Common Services Entity (CSE), showing newly added
815 CSFs and associated CSF capabilities.

816

817
818 Figure 6.3-2 Example of CSFs and EFs within Common Services Entity Architecture

819
820 The Services Extension Enabler enables the CSE to offer M2M Services over the X and Y reference points. The
821 Services Extension Enabler provides the following functions:

822 1. Check module authentication

823 2. Check node resources

824 3. Check interoperability with existing modules

825 4. Check policy and rights to determine how to handle conflicts e.g. Do not register new module or deregister
826 existing module, etc.

827 5. Register new module

828 6. Add new service(s) due to new module to list of services

829 7. Modify API support to reflect new service capabilities

830 8. Modify inter-module communications to incorporate new module

831 Editor’s Note: The above list is preliminary and is for FFS.

832 Editor’s Note: How the Service Extension Enabler is associated with the APIs is FFS.

23 © OneM2MPartners Page 23 of 43
833 6.3 Security Aspects
834 <Text>

835 6.4 Other Aspects

836 <Text>

837

838 7. M2M Identification and Addressing

839 This clause provides a list of identifiers required for the purpose of interworking within the oneM2M architectural
840 model.

841 7.1 M2M Identifiers

842 7.1.1 M2M Service Provider Identifier (M2M-SP-ID)
843 An M2M Service Provider shall be uniquely identified by the M2M Service Provider Identifier (M2M-SP-ID). This is a
844 static value assigned to the Service Provider.

845 7.1.2 Application Instance Identifier (App-Inst-ID)

846 An Application Instance Identifier (App-Inst-ID) uniquely identifies an M2M Application instance resident on an M2M
847 node, or an M2M Application instance that requests to interact with an M2M node. An App-Inst-ID shall identify an
848 Application for the purpose of all interactions from/to the Application within the M2M framework.

849 It is the responsibility of the M2M Service Provider to ensure that the App-Inst-ID is globally unique. The App-Inst-ID
850 shall include the Application ID (see clause 7.2.3.)

851 7.1.3 Application Identifier (App-ID)

852 This is equivalent to the application name and is not guaranteed to be globally unique on its own.

853 Editor's Note: Who assigns the App-ID is FFS.

854 7.1.4 CSE Identifier (CSE-ID)

855 A CSE shall be identified by a globally unique identifier, the CSE-ID, when instantiated within an M2M node in the
856 M2M architecture.

857 The CSE-ID shall identify the CSE for the purpose of all interactions from/to the CSE within the M2M framework.

858 7.1.5 M2M Node Identifier/Device Identifier (M2M-Node-ID)

859 An M2M node, hosting a CSE and/or Application(s) shall be identified by a globally unique identifier, the M2M-Node-
860 ID.

861 The M2M system shall allow the M2M Service Provider to set the CSE-ID and the M2M-Node-ID to the same value.

862 The M2M-Node-ID enables the M2M Service Provider to bind a CSE-ID to a specific M2M node.

863 Editor's Note: Several terms used in this clause: "M2M framework", "M2M architecture", "M2M system". Need to
864 agree on a single terminology.

24 © OneM2MPartners Page 24 of 43
865 7.1.6 M2M Service Subscription Identifier (M2M-Sub-ID)
866 The M2M-Sub-ID enables the M2M Service Provider to bind application(s), M2M nodes, CSEs to a particular M2M
867 service subscription.

868 The M2M Service Subscription Identifier has the following characteristics:

869 • belongs to the M2M Service Provider,

870 • identifies the subscription to an M2M Service Provider,

871 • enables communication with the M2M Service Provider,

872 • can differ from the M2M Underlying Network Subscription Identifier,

873 • changes with the change of the M2M Service Provider.

874 There can be multiple M2M Service Subscription Identifiers per M2M Underlying Network subscription.

875 7.1.7 Session Identifier (M2M-Session-ID)

876 M2M-Session-ID is an identifier that tracks a request initiated by a CSE end to end. M2M-Session-ID is also included
877 in the "response" to the request. The M2M-Session-ID is allocated by the CSE initiating the request. The request
878 initiated by the CSE could be the result of an Application request, or a request initiated autonomously by the CSE to
879 fulfil a service.

880 A CSE receiving a request from a peer CSE shall include the received M2M-Session-ID in all additional requests that it
881 generates (including propagation of the incoming request) and that are associated with the incoming request, where
882 applicable.

883 The CSE may include the same M2M-Session-ID in its interactions with the underlying network, where applicable

884 An M2M-Session-ID allocated to a request by a CSE shall be unique within the CSE.

885 7.1.7 Request Identifier (M2M-Request-ID)

886 This is an identifier that tracks a Request initiated by a CSE end to end. It is also included in the Response to the
887 Request. The M2M-Request-ID is allocated by the CSE initiating the Request. The Request initiated by the CSE could
888 be the result of an Application Request, or a Request initiated autonomously by the CSE to fulfil a service.

889 Hence, a CSE receiving a Request from a peer CSE shall include the Received M2M-Request-ID in all additional
890 Requests it has to generate (including propagation of the incoming Request) and that are associated with the incoming
891 Request, where applicable.

892 The CSE shall include the same M2M-Request-ID in its interactions with the Underlying Network, where applicable

893 An M2M-Request-ID allocated to a Request by a CSE shall be globally unique.

894 Editor’s Note: The need for an M2M-Request-ID on the X reference point for Applications that generate multiple
895 simultaneous Requests is FFS.

896 Editor’s Note. The applicable reference points for various sections will be added.

897 Editor’s Note: Bring in a contribution to indicate where this information will be carried.

898 Editor’s Note: The case for multiple Request Identifiers is FFS.

899

900 7.2 M2M Identifiers lifecycle and characteristics

901 <Text>

902

25 © OneM2MPartners Page 25 of 43
903 8. X and Y Reference Points
904 Procedures involving a CSE and Applications are executed the exchange of data according to message flow described in
905 clause 8.1.

906 The exchange of data consists of the information transferred across the reference points, and stored in a standardized
907 resource structure as described in clause 9.

908 The use of the addressable resources also enables the “store-and-share” paradigm of application information and Big
909 Data. Access and manipulation of the resources is subject to their associated permissions.

910 Some of the procedures on the X and Y reference points may adopt a different approach than the ones described in this
911 clause. Such procedures are described in <reference to be included when available>.

912 Editors Note: Which of the procedures do not adopt the approach described in this clause and how they are
913 performed is FFS.

914 8.1 General Communication Flow Scheme

915 8.1.1 Description
916 Figure 8.1.1-1 shows the general flow that governs the information exchange within a procedure, which is based on the
917 use of Request and Response scheme. The scheme applies to communications such as:

918  between an Application and a CSE (X reference point), and

919  among CSEs (Y reference point).

920 The communications can be initiated either by the Applications or by the CSEs.

921

922
923

924 Figure 8.1.1-1: Resource Manipulation by an Application within an Entity

925 8.1.2 Request

926 Request from an Originator to a Receiver includes the following information:

927 op: operation to be executed: Create (C), Retrieve (R), Update (U), Delete (D),

928 to: address of target resource, e.g. /m2m.provider1.com/netBase/temp1,

929 fr: address of the resource representing the Originator. Used for access control, e.g.,
930 /m2m.provider2.com/remBase/app1,

931 mi: meta-information about the Request,

26 © OneM2MPartners Page 26 of 43
932 Editor's Note: Defaults for meta-information are FFS.

933 cn: resource content to be transferred.

934 Note: The to target resource needs to be known by the Originator. It can be known either by pre-provisioning or by
935 discovery.

936 Editor’s Note: How pre-provisioning and discovery are performed is FFS.

937 The op information shall indicate the operation to be executed at the Receiver:

938 Create (C): a new resource addressable with to parameter is created,

939 Retrieve (R): an existing to addressable resource is read and provided back to the Originator,

940 Update (U): the content of an existing to addressable resource is replaced with cn new content,

941 Delete (D): an existing to addressable resource and all its sub-resources are deleted from the Resource Storage.

942 Editor’s Note: This is an initial list of the verbs. The need for more verbs is anticipated to cover all use cases,
943 configuration and functions.

944 The to information shall address the target resource in the Receiver.

945 The fr information shall be used by the Receiver to check the Originator identity for access permission verification.

946 The cn information shall be present in Request for the following operations:

947 Create: cn is the content of the new resource,

948 Update: cn is the content to be replaced in an existing resource,

949 Retrieve: cn is the filter to be applied for discovery purposes.

950 The mi information shall be as follows:

951 ot: optional originating timestamp of when the message was built,

952 Example usage of the originating timestamp includes: to measure and enable operation (e.g. message logging,
953 correlation, message prioritisation/scheduling, accept performance requests, charging, etc.) and to measure
954 performance (distribution and processing latency, closed loop latency, SLAs, analytics, etc.)

955 et: optional expiration timestamp,

956 Example usage of the expiration timestamp includes to indicate when messages (including delay-tolerant) should
957 expire due to the freshness of the responses being no longer of value, and to inform message
958 scheduling/prioritisation.

959 rt: optional response type: indicates whether response should contain content or the address of the content,

960 Example usage of the response type set to "address of the content" includes when the response content is extremely
961 large, or when multiple response content from a target group are to be aggregated asynchronously over time

962 rp: optional response persistence: indicates the duration for which the address containing the responses is to persist.

963 Example usage of response persistence includes requesting sufficient persistence for analytics to process the
964 response content aggregated asynchronously over time. If an expiration timestamp is specified then the
965 response persistence should last beyond the Request expiry time.

966 Once the Request is delivered, the Receiver shall analyze the Request to determine the target resource.

967 If the target resource is addressing another M2M node, the Receiver shall route the request appropriately.

968 If the target resource is addressing the Receiver, it shall:

969 • Check the existence of to addressed resource,

970 • Identify the resource type,

27 © OneM2MPartners Page 27 of 43
 971 • Check the permission for fr Originator to perform the requested operation,

972 • Perform the requested operation (using cn content when provided),

973 • Respond to the Originator with indication of successful or unsuccessful operation results. In some specific
974 cases (e.g. limitation in the binding protocol or based on application indications), the Response could be
975 avoided.

976 The message flow procedure started with an Originator Request shall be considered closed when either:

977 • A Request is received with an expired et (expiration timestamp),

978 • A Response is delivered to the Originator,

979 • The requested operation at the Receiver is successfully completed and no Response is needed.

980 8.1.3 Successful Operation

981 The Response from the Receiver of a Request to the Originator of that Request, in the case of a successful completion
982 of the requested operation includes the following information:

983 op: operation being executed: Create (C), Retrieve (R), Update (U), Delete (D) (optional),

984 mi: meta-information about the Request,

985 Editor's Note: Defaults for meta-information are FFS.

986 rs: operation result: e.g. Okay, Okay and Done; Okay and Scheduled; Okay and In Progress, etc.,

987 cs: optional additional result information, e.g. status codes,

988 to: address of target resource, e.g. /m2m.provider1/netBase/temp1,

989 cn: resource content to be transferred (optional).

990 The mi information includes:

991 ot: optional originating timestamp of when the message was built,

992 et: optional expiration timestamp.

993 The cs information includes:

994 ra: optional, address for the temporary storage of end node Responses.

995 The cn information may be present in a Response in the following cases:

996 Update: cn is the content replaced in an existing resource,

997 Delete: cn is the content actually deleted.

998 The cn information shall be present in a Response in the following cases:

999 Retrieve: cn is the retrieved resource content or aggregated contents of discovered resources.

1000 8.1.4 Unsuccessful Operation

1001 The Response from the Receiver of a Request to the Originator of the Request, in the case of unsuccessful completion
1002 of the requested operation includes the following information:

1003 op: operation being executed: Create (C), Retrieve (R), Update (U), Delete (D) (optional),

1004 mi: meta-information about the Request,

1005 Editor's Note: Default for meta-information are FFS.

28 © OneM2MPartners Page 28 of 43
1006 rs: operation result: e.g. Not okay.

1007 cs: optional additional result information, e.g. status codes.

1008 The mi information includes:

1009 ot: optional originating timestamp of when the message was built,

1010 et: optional expiration timestamp.

1011 8.2 Procedures for Accessing Resources

1012 This clause describes the procedures for accessing the resources. The procedures include:

1013 • Generating Responses to the Requests for accessing resources,

1014 • Accessing the resources that may be located in different CSEs.

1015 Editor’s Note: Other procedures related to accessing the resources are FFS.

1016 The procedures are applicable to all cases described in the following clauses.

1017 8.2.1 Generating Responses

1018 The following types of Responses are supported for accessing the resources over the X and Y reference points:

1019 • Success: indicates to the Originator that the Request has been executed successfully by the Hosting CSE.

1020 • Failure: indicates to the Originator that the Request has not been executed successfully by the Hosting
1021 CSE.

1022 Both, the Success and the Failure Response types may convey other information also to the Originator of the Request.

1023 Detailed Success and Failure codes are provided in the Protocol specifications.

1024 Editor’s Note: References to Protocol specifications will be provided when available.

1025 • In addition to the above mentioned Success and Failure Response types, there is another Response type
1026 that indicates an Acknowledgement of the Request. This indicates to the Originator that the Request has
1027 been received by the Hosting CSE, but not executed yet. The Success or the Failure of the execution of the
1028 Request is to be conveyed later.

1029 Editor's Note: Details of Acknowledgement Response type is FFS.

1030 8.2.2 Accessing Resources in CSEs

1031 For the procedures described herein, the addressed resource can be stored in different CSEs. Table 8.2.2-1 describes the
1032 possible scenarios, where the addressed resource may be on the local-CSE or on a CSE located elsewhere in the
1033 oneM2M System.

1034 Editor’s Note: How the target of a Request (i.e, an Application or local/hosting CSE) is identified and addressed, is
1035 FFS.

1036 Editor’s Note: A message (Request, Response) can be forwarded immediately or forwarded at a later time (e.g in the
1037 case of congestion).The procedures related to the forwarding of the Request at a later time are FFS.

1038

29 © OneM2MPartners Page 29 of 43
1039 Table 8.2.2-1 Accessing Resources in different CSEs

Traversals across
X/Y Reference Description
Reference
Points
 The Originator of the Request accesses a resource.
No Hops  The Originator of the Request can be an Application Figure 8.2.2-1
or a CSE.
 Local CSE and Hosting CSE are the same entity.
 The CSE shall check the Access Rights for
accessing the resource.
 The CSE shall respond to the Originator of the
Request, either with a Success or Failure Response.
 The Originator of the Request accesses a resource.
1 Hop  The Originator of the Request may only be an Figure 8.2.2-2
Application. (Note-1)
 Local CSE and Hosting CSEs different entities. (Editor's Note-1)
 Local CSE shall forward the Request to the Hosting
CSE, after an optional checking of the Access Rights
for accessing the resource and the syntax of the
Request message.
 Hosting CSE shall check the Access Rights for
accessing the resource and respond with a Success
or Failure Response.
 The Originator of the Request accesses a resource.
Multi Hops  The Originator of the Request may be an Application Figure 8.2.2-3
or a CSE.
 Local CSE, Intermediate CSE(s) and the Hosting (Editor's Note-2)
CSE are different entities.
 Local CSE shall forward the Request to an
Intermediate CSE (e.g. MN-CSE) that the Local CSE
is registered with, if it cannot communicate with the
Hosting CSE directly. An optional checking of the
Access Rights for accessing the resource and the
syntax of the Request message may be performed
prior to forwarding the Request.
 Intermediate CSE may forward the Request to
another Intermediate CSE (e.g. another MN-CSE)
that the Intermediate CSE is registered with, if it
cannot communicate with the Hosting CSE directly.
An optional checking of the Access Rights for
accessing the resource and the syntax of the
Request message can be performed prior to
forwarding the Request.
 The Intermediate CSE shall forward the request to
the Hosting CSE. An optional checking of the
Access Rights and the syntax of the Request
message can be performed prior to forwarding the
Request.
 Hosting CSE shall check the Access Rights for
accessing the resource and respond with a Success
or Failure Response.

Editor's Note-1: One-Hop case could potentially include the CSE-to-CSE communication also. The
need for such procedures is FFS.
Editor's Note-2: The multi-hop procedures addresses the scenario when the target is on a specific
remote CSE. How a flow will works when the target is distributed on multiple remote
CSEs is FFS.

1040

30 © OneM2MPartners Page 30 of 43
1041
1042 Figure 8.2.2-1: Originator accesses a resource on the Local CSE (No Hops)

31 © OneM2MPartners Page 31 of 43
1043
1044 Figure 8.2.2-2: Application accesses a resource at the Hosting CSE (One Hop)

1045

32 © OneM2MPartners Page 32 of 43
1046
1047 Figure 8.2.2-3: Originator accesses a resource at the Hosting CSE (Multi Hops)

1048

33 © OneM2MPartners Page 33 of 43
1049 9 Resource Management
1050 All entities in the oneM2M System, such as Applications, CSEs, "data", etc., are represented as "resources". A
1051 "resource structure" is specified as a representation of the "resources". Such "resources" are uniquely addressable.
1052 Procedures for accessing such resources are also specified.

1053 9.1 General Principles

1054 The following are the general principles for the design of the resource model.

1055 • The "type" of all resource shall be specified. New resource types shall be supported as the need for them is
1056 identified;

1057 • The root of the resource structure in a CSE shall be assigned an absolute address, such as <baseURI>;

1058 • The resource structure shall be kept reasonably simple. In particular:

1059 - Application Resources belonging to the local CSE shall be located directly under the baseURI
1060 resource,

1061 - Access Right Resources belonging to the local CSE shall be located directly under the baseURI
1062 resource,

1063 - Group resources belonging to the local CSE shall be located directly under the baseURI resource,

1064 - CSE resources representing a remote CSE shall be located directly under the baseURI resource,

1065 - Container Resources belonging to the local CSE shall be located under the baseURI resource or under
1066 another container resource;

1067 Editor’s Note: These above stated resource types needs to be validated.

1068 • The attributes for all resource type shall be specified;

1069 • Each resource type can have multiple instances;

1070 • All resource and associated attributes shall be uniquely addressable via their associated Universal Resource
1071 Identifiers (URI);

1072 • URI shall be used to determine the relationship among the "container" resources. This, however, does not
1073 imply any specific storage structure for the container resource. The structure of a container resource is
1074 subject to implementations.

1075 9.2 Resource Types

1076 This clause introduces the types of resources used in a CSE. A resource scheme is used for modelling the resource
1077 structure and associated relationships.

34 © OneM2MPartners Page 34 of 43
1078 Table 9.2-1: Resource types and tagging

Resource type
Editor's Note-2. Tag value Description
Editor's Note-3.

Base URI Resource: <baseURI> B Base URI resource shall be the root of the resource
structure. It shall store information about the local CSE.
All resources belonging to the local CSE shall be child
resources of the Base URI resource.
CSE Resource: <Entity> E Entity resource shall store information related to CSEs.

Editor's Note-1.
Application Resource: <Application> A Application resource shall store information about the
Applications. Application resource is created as a result
of successful registration of an Application with the local
CSE. Applications shall register with their local CSE
only.
Access Right Resource: <AccessRight> R AccessRight resource shall store a representation of the
permissions. An accessRight resource is associated
with resources that shall be accessible to entities
external to the hosting CSE. Basically, accessRight
resource controls "who" (permissionHolder) is allowed
to do "what" (permissionFlag). It can be used for
privacy protection as well.
Container Resource: <Container> C Container resource is a generic resource that shall be
used to exchange "data" between Applications and/or
CSEs. "Container" is used as a mediator that takes care
of buffering the data. The exchange of data between
Applications (e.g. an Application on an end-device and
the peer-Application on the network side) is abstracted
from the need to set up direct connections and allows
for the scenarios where both parties in the exchange are
not online at the same time.
Group Resource: <Group> G Group resource shall store information about resources
of the same type that need to be addressed as a Group.
Operations addressed to a Group resource shall be
executed in a bulk mode for all members belonging to
the Group.

Editor's Note-1": For the <Entity> resource storing information related to CSEs: Is the reference to local
CSEs or to both the local and remote CSEs. Need to be clarified.

Editor's Note-2: The type of resources included in this table is not complete yet. This is FFS.

Editor’s Note-3: As the work progresses, the resource types may change. This is FFS.

1079

1080 The resources are indicated in the following notation:

<name>: Indicates the resource name assigned during the creation of the resource. The
name may be provided by the Originator of the Request that created the
resource or by the CSE that hosts the resource (if name is not provided by the
Originator).

Attributes FFS

Editor’s Note: Attributes for the Resource Types are FFS.

1081

35 © OneM2MPartners Page 35 of 43
1082 9.2.1 Types of Virtual Resources
1083 Some resource are defined as “virtual”. Such resources are instantiated when they are only when transferred over some
1084 communication interfaces. but tThey are not stored in theto a resource structure.

1085 Some examples of virtual resources are:

Discovery Virtual resource used to describe the filter criteria for discovery purposes

Notify Virtual resource used for notification purposes.

Bulk Virtual resource used for group oriented bulk operations

1086

1087 9.3 Resource Addressing

1088 Resources shall be uniquely addressable via URI. The following are examples of addressable resources.

1089 /baseURI/Entity Instance 1

1090 /baseURI/Entity Instance n

1091 /baseURI/Application Instance 1

1092 /baseURI/Application Instance n

1093 /baseURI/Container1/Container2

1094 Resources may be associated by using a link with reference to another resource.

1095 9.4 Resource Structure

1096

1097
1098 Figure 9.4-1: Topological Resource Structure at a CSE

1099
1100 Editor's Note: The resource structure picture needs to be updated as the resource structure evolves.

36 © OneM2MPartners Page 36 of 43
1101 9.5 Resource Operations
1102 Resources shall be manipulated using the following operations:

1103 Create: a new resource is created

1104 Retrieve: the content of an existing resource addressed by the Issuer is provided back to it.

1105 Update: the content of an existing addressed resource is replaced with a new content provided by the Issuer.

1106 Delete: an existing addressed resource is deleted by the structure upon request of an Issuer.

1107 Editor's Note: Such information is already included in 8.2.2. Propose to remove this text.

1108 9.5 TBD

1109 <TBD>

1110 10. Information Flows

1111 <Text>

1112 10.1 General Concepts

1113 <Text>

1114

1115

1116

1117

1118

1119 Proforma copyright release text block

1120 This text box shall immediately follow after the heading of an element (i.e. clause or annex) containing a proforma or
1121 template which is intended to be copied by the user. Such an element shall always start on a new page.

1122 Notwithstanding the provisions of the copyright clause related to the text of the present document, OneM2M grants that
1123 users of the present document may freely reproduce the <proformatype> proforma in this {clause|annex} so that it can
1124 be used for its intended purposes and may further publish the completed <proformatype>.

37 © OneM2MPartners Page 37 of 43
1125

1126 Annex <A> (Informative): Deployment Scenarios

1127 <Text>

38 © OneM2MPartners Page 38 of 43
1128

1129 Annex <B>(Informative/Normative): Remove Informative or Normative as

1130 appropriateTitle of annex (style H9)

1131 <Text>

1132 B.1 First clause of the annex (style H1)

1133 <Text>

1134 B.1.1 First subdivided clause of the annex (style H2)

1135 <Text>

39 © OneM2MPartners Page 39 of 43
1136

1137 Annex <y>:

1138 Bibliography
1139 The annex entitled "Bibliography" is optional.

1140 It shall contain a list of standards, books, articles, or other sources on a particular subject which are not mentioned in the
1141 document itself

1142 It shall not include references mentioned in the document.

1143 Use the Heading 9 style for the title and B1+ or Normal for the text.

1144  <Publication>: "<Title>".

1145 OR

1146 <Publication>: "<Title>".

40 © OneM2MPartners Page 40 of 43
1147

1148 History
Publication history
V1.1.1 <dd-Mmm-yyyy> <Milestone>

1149

41 © OneM2MPartners Page 41 of 43
1150

1151

Draft history (to be removed on publication)

V0.0.1 27-FEB-2013 Rapporteur Input - Draft Skeleton

V0.0.2 20-APR-2013 Rapporteur Input –Draft; Including the following contributions:

1. oneM2M-ARC-2013-0255R03-Arcitecture_Description
2. oneM2M-ARC-2013-0256R01-Definitions_for_Arc_TS
3. oneM2M-ARC-2013-0253R03-Definition_to_SCX_and_SFM

V0.0.3 08-JUNE-2013 1. oneM2M-ARC-2013-0262R02-Update_to_Figure_5-1

V0.0.4 28-JUNE-2013 Includes the following contributions agreed at TP#05:

1. oneM2M-ARC-2013-0275R03-Revised_functional_architecture
2. oneM2M-ARC-2013-0280R03-Definitions_of_Reference_Points
3. oneM2M-ARC-2013-0281R02-M2M_Identifiers
4. oneM2M-ARC-2013-0285R05-Delivery_Handling_in_CSE
5. oneM2M-ARC-2013-0287R04-High_level_Application_Programming_
Interface

V0.0.5 26-JULY-2013 Includes the following contributions agreed during ARC#28 and ARC#29
1. oneM2M-ARC-2013-0307R03-Refinement_proposal_for_reference
_architecture
2. oneM2M-ARC-2013-0311R01-Definition_of_oneM2M_Node
3. oneM2M-ARC-2013-0312R01-Missing_definitions_for_WG1_work_progress

V0.0.6 23-AUGUST-2013 Includes the following contributions agreed during ARC#30 (TP#06 F2F) meeting:
1. oneM2M-ARC-2013-0315R04-Proposal_for_definition_of_specific_Nodes
2. oneM2M-ARC-2013-0316R03-flow_message_extensions
3. oneM2M-ARC-2013-0317R02-Service_Enabler
4. oneM2M-ARC-2013-0340R04-General_mechanism_for_X_and_Y_reference_points
5. oneM2M-ARC-2013-0343R02-Multiple_domains
6. oneM2M-ARC-2013-0348R02-Session-ID
7. oneM2M-ARC-2013-0354R03-Definition_of_Common_Service_Entities_Collection
8. oneM2M-ARC-2013-0357R03-CSF_Descriptions
9. oneM2M-ARC-2013-0359R02-Introducing_Resource_Structure

The following documents are included in

"oneM2M-ARC-2013-0357R03-CSF_Descriptions":
1. oneM2M-ARC-2013-0302R02-Location_CSF
2. oneM2M-ARC-2013-0318R01-oneM2M-ARC-2013-0318-
Data_Management_and_Repository_CSF
3. oneM2M-ARC-2013-0319R02-
Network_Service_Exposure_Service_execution_and_triggering_CSF
4. oneM2M-ARC-2013-0322R01-Group_Management_CSF
5. oneM2M-ARC-2013-0325R01-A_CSF_description_for_registration
6. oneM2M-ARC-2013-0328R02-A_CSF_description_for_Discovery
7. oneM2M-ARC-2013-0329R02-
Normative_Description_for_Subscription_Notification_Support_CSF
8. oneM2M-ARC-2013-0330R02-Device_management_CSF
9. oneM2M-ARC-2013-0331R01-descriptions_of_charging_CSF
10. oneM2M-ARC-2013-0334R02-description_of_session_management_CSF
11. oneM2M-ARC-2013-0335R02-CSF-ID
12. oneM2M-ARC-2013-0339R01-Service_charging_and_accounting_CSF
13. oneM2M-ARC-2013-0345R02-Security_related_CSFs

42 © OneM2MPartners Page 42 of 43
 V0.0.7 26-AUGUST-2013 Includes the following contributions agreed during ARC#31 meeting:
1. 1It was brought to attention that contribution # oneM2M-ARC-2013-0348R02-Session-
ID had not been incorporated in v0.0.6 correctly. Corrected in section 7.1.7
2. Review comments provided by Phil Jacobs via his email dated August 21, 2013

1152

1153

43 © OneM2MPartners Page 43 of 43