ETSI TR 118 517 V2.0.0 (2016-09)

oneM2M; Home Domain Abstract Information Model (oneM2M TR-0017 version 2.0.0)

DTR/oneM2M-000017

General Information

• Status: Published
• Publication Date: 15-Sep-2016
• Technical Committee: oneM2M - oneM2M
• Current Stage: 12 - Completion
• Completion Date: 16-Sep-2016

Standards Content (Sample)

ETSI TR 118 517 V2.0.0 (2016-09)






TECHNICAL REPORT
oneM2M;
Home Domain Abstract Information Model
(oneM2M TR-0017 version 2.0.0)

---------------------- Page: 1 ----------------------
oneM2M TR-0017 version 2.0.0 2 ETSI TR 118 517 V2.0.0 (2016-09)



Reference
DTR/oneM2M-000017
Keywords
IoT, M2M

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2016.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
oneM2M TR-0017 version 2.0.0 3 ETSI TR 118 517 V2.0.0 (2016-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Abbreviations . 7
4 Conventions . 7
5 Home Domain Abstract Information Model . 8
5.1 Anaysis of Abstract Information Models . 8
5.1.1 AllJoyn (AllSeen Alliance) . 8
5.1.2 HomeKit (Apple Inc.) . 8
5.1.3 SmartHome Device Template (HGI) . 9
5.1.3.1 Introduction . 9
5.1.3.2 Definitions . 11
5.1.3.3 Overview . 11
5.1.3.4 Structure . 11
5.1.3.5 "Domain" element . 12
5.1.3.6 "Device" and "SubDevice" element . 13
5.1.3.7 "Module" element(s) . 13
5.1.3.8 "ModuleClass" element(s) . 13
5.1.3.9 "Property" Elements . 14
5.1.3.10 "ModuleClass" - "DataPoint" element . 14
5.1.3.11 "ModuleClass" - "Actions" element . 14
5.1.3.12 "Module Class" - "Action" - "Args" . 15
5.1.3.13 "ModuleClass" - "Event" element . 15
5.1.3.14 "Doc" element . 15
5.1.3.15 "DataType" element . 15
5.1.3.16 "DataType" - "unitOfMeasure" . 16
5.1.3.17 "DataType" - "TypeChoice" Element . 16
5.1.3.18 "DataType" - "SimpleType" Element . 17
5.1.3.19 "DataType" - "Constraint" Element . 17
5.1.3.20 "DataType" - "Array" Element . 17
5.1.3.21 "DataType" - "StructType" Element . 17
5.1.3.22 A very simple SDT example . 18
5.1.4 ECHONET/ECHONET Lite (ECHONET Consortium) . 20
5.1.5 OIC (Open Interconnect Consortium). 21
5.2 Design Principle of Abstract Information Model . 22
5.2.1 Introduction. 22
5.2.2 Design Principle: Approach 1 . 22
5.2.3 Design Principle: Approach 2 . 23
5.2.4 Design Principle: Approach 3 . 24
5.2.5 Design Principle: Approach 4 . 25
5.3 Define Abstract and Describe Specific Abstract Information Model . 26
5.3.1 Abstract Information Model: Approach 1 . 26
5.3.1.1 Introduction . 26
5.3.1.2 Washer . 27
5.3.1.3 Refrigerator . 27
5.3.1.4 Smart Meter. 28
5.3.2 Abstract Information Model: Approach 2 . 28
5.3.2.0 Overview . 28
5.3.2.1 Washer . 30
5.3.3 Abstract Information Model: Approach 3 . 30
5.3.3.1 Introduction . 30
ETSI

---------------------- Page: 3 ----------------------
oneM2M TR-0017 version 2.0.0 4 ETSI TR 118 517 V2.0.0 (2016-09)
5.3.3.2 Device Information Model . 30
5.3.3.3 Service Information Model . 31
5.3.4 Abstract Information Model: Approach 4 . 32
5.3.4.0 Introduction . 32
5.3.4.1 ModuleClasses . 32
5.3.4.2 Device Information Model . 33
6 Representation in the oneM2M System . 33
6.1 Introduction . 33
6.2 Approach 1: Representation Using Dedicated Resource Types . 34
6.2.1 New Resource Type appliance . 34
6.2.1.0 Introduction . 34
6.2.1.1 one-level . 34
6.2.1.2 two-level . 40
6.3 Approach 2: Existing Resource Type container/contentInstance . 45
6.3.1 Introduction. 45
6.4 Comparison of potential solutions . 48
7 Conclusions . 48
History . 49

ETSI

---------------------- Page: 4 ----------------------
oneM2M TR-0017 version 2.0.0 5 ETSI TR 118 517 V2.0.0 (2016-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Partnership Project oneM2M (oneM2M).
ETSI

---------------------- Page: 5 ----------------------
oneM2M TR-0017 version 2.0.0 6 ETSI TR 118 517 V2.0.0 (2016-09)
1 Scope
The present document allows application developers to describe the status of devices as resources on oneM2M-based
platform in various ways. Thus different application developers can create different resource trees even when they build
the same kinds of applications. Moreover when handling the same kinds of devices from different vendors on M2M
platforms, application developers may create disunited resource trees without common information model.
In order to solve such issues, the present document intends to provide the common and unified APIs on one M2M
platform for the home domain by defining an abstract information model for the home domain devices such as TV,
refrigerator, air conditioner, smart meter, and lighting equipment. The definition of the abstract information model will
be based on data models that currently exist in the home domain. The home domain abstract information model does
not intend to define the interworking function between the oneM2M system and protocols of the data models from
which the abstract data model is defined.
Also, the present document intends to define how the developed abstract information model for a device could be
represented in the CSEs of the oneM2M system.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] oneM2M Drafting Rules.
NOTE: Available at http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf.
[i.2] ETSI TS 118 111: "Definitions and Acronyms (oneM2M TS-0011)".
[i.3] AllJoyn System Description version 14.06, September 26th, 2014.
[i.4] Home Appliances & Entertainment (HAE) Service Framework Project.
NOTE: Available at https://wiki.allseenalliance.org/hae.
ETSI

---------------------- Page: 6 ----------------------
oneM2M TR-0017 version 2.0.0 7 ETSI TR 118 517 V2.0.0 (2016-09)
[i.5] HomeKit Developer Site.
NOTE: Available at https://developer.apple.com/homekit/.
[i.6] Designing Accessories for iOS and OS X, WWDC14.
NOTE: Available at https://developer.apple.com/videos/wwdc/2014/.
[i.7] ETSI TS 118 104: "Service Layer Core Protocol Specification (oneM2M TS-0004)".
[i.8] ECHONET Specification Ver.2.11.
NOTE: Available at http://echonet.jp/spec_v211_en/.
[i.9] ECHONET Lite Specification Ver.1.11.
NOTE: Available at http://echonet.jp/spec_v111_lite_en/.
[i.10] ECHONET APPENDIX, Detailed Requirements for ECHONET Device Objects.
NOTE: Available at http://echonet.jp/spec_object_rf_en/.
[i.11] IEC 62394: "Service diagnostic interface for consumer electronics products and networks -
Implementation for echonet".
[i.12] ISO/IEC 24767-1: "Information technology -- Home network security -- Part 1: Security
requirements".
[i.13] ISO/IEC 24767-2: "Information technology -- Home network security -- Part 2: Internal security
services: Secure Communication Protocol for Middleware (SCPM)".
[i.14] IEC 62480: "Multimedia home network - Network interfaces for network adapter".
[i.15] ISO/IEC 14543-4-1: "Information technology -- Home electronic system (HES) architecture --
Part 4-1: Communication layers -- Application layer for network enhanced control devices of HES
Class 1".
[i.16] ISO/IEC 14543-4-2: "Information technology -- Home electronic system (HES) architecture --
Part 4-2: Communication layers -- Transport, network and general parts of data link layer for
network enhanced control devices of HES Class 1".
[i.17] IEC 62457: "Multimedia home networks - Home network communication protocol over IP for
multimedia household appliances".
[i.18] ETSI TS 118 123: "Authorization Architecture for Supporting Heterogeneous Access Control
Policies (oneM2M TS-0023)".
[i.19] ETSI TS 118 101: "Functional Architecture (oneM2M TS-0001)".
3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 118 111 [i.19] and the following apply:
IoE Internet of Everything
4 Conventions
The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in the present document are to be
interpreted as described in the oneM2M Drafting Rules [i.1].
ETSI

---------------------- Page: 7 ----------------------
oneM2M TR-0017 version 2.0.0 8 ETSI TR 118 517 V2.0.0 (2016-09)
5 Home Domain Abstract Information Model
5.1 Anaysis of Abstract Information Models
5.1.1 AllJoyn (AllSeen Alliance)
The AllJoyn system is a proximity-based, peer-to-peer communication platform that provides a framework for enabling
communication among internet of everything (IoE) devices across heterogeneous distributed systems [i.3]. Especially,
there is a specific project to develop the common way of controlling and monitoring Home Appliances & Entertainment
(HAE) devices (such as airconditioner, refrigerator, washer), regardless of device manufacturers [i.4]. In order to
achieve this issue, HAE service frame project specifies standard AllJoyn interfaces for controlling and monitoring HAE
devices as shown in figure 5.1.1-1.
Device Refrigerator Oven Washer TV
...
Washer TV
Interface
Common DoorStatus Timer Display
...
Function Function
Common Shared Device Specific
CountryOf Product Event
Resolution
IsClosed GetLocation SetTime .
Characteristic
Production Brand signal
Property Method Signal

Figure 5.1.1-1: Information Model in AllJoyn
In the AllJoyn information model, 'Device' which represents physical home appliance (such as refrigerator, oven,
washer, TV) should have 'Interface(s)' that consist of 'Characteristic(s)'.
'Characteristic' specifies pre-defined device properties(such as country of production, product brand, status of door,
display resolution), method(such as getting location, setting the timer) and signal(similar to notification). By combining
one or more pre-defined characteristic(s), a specific 'Interface' which provides a particular service(such as subscription
or control of the device) can be defined. Furthermore, the AllJoyn system categorizes the 'Interface' into common
interface, shared interface and device specific interface for more efficient management. Although the complexity is
increased as arraging into the service set, this approach enhances the resource efficiency by resusing the 'Interface'.
5.1.2 HomeKit (Apple Inc.)
HomeKit is a framework in iOS for communicating with and controlling connected accessories in a home domain
environment [i.5]. Among developments related document, HomeKit Accessory Profiles defines the information model
for some services based on the 'Charateristic' and 'Service' [i.6].
ETSI

---------------------- Page: 8 ----------------------
oneM2M TR-0017 version 2.0.0 9 ETSI TR 118 517 V2.0.0 (2016-09)
...
Device Refrigerator
Oven Light TV
IP Camera
Door
...
Se rv ice Custom
Thermostat
Light
Control
Lock
Power Model
...
Chara cteristi c Lock State temperature Custom
Brightness
State
Number

Figure 5.1.2-1: Information Model in HomeKit
As shown in figure 5.1.2-1, the chracteristic specifies pre-defined characteristics and their properties (such as power
state, brightness, lock state, model number). Based on the chracteristic, a specific service (such as door lock, light,
thermostat) can be defined one or more chracteristic(s). Especially, the 'Custom' value is considered for the un-
predefined characteristic and service. As a result, a specific device may have one or more service set(s). Compared to
the AllJoyn system approach, the characteristic set in the Homekit are equivalent to the characteristic in the AllJoyn.
The HomeKit system has moduled service sets by using characteristic set(s). It is a very similar approach with the
'Interface' in the AllJoyn system.
5.1.3 SmartHome Device Template (HGI)
5.1.3.1 Introduction
The SDT (SmartHome Device Template) is an initiative from HGI to find consensus amongst various SDOs and
industry alliances to derive a common approach for device modelling. HGI and partners have the approach to agree on a
set of automation commands following a common syntax which are sufficient to model most home appliance functions.
The key goals of the SDT are:
1) keep it simple, especially for manufacturers to contribute device information;
2) modularity for functions and device types;
3) make it easy for developers to create unified APIs;
4) be independent of underlying home-area network technologies;
5) enable extendibility of the system in place without service interruption;
6) allow a pass-through mechanism to enable use of proprietary or technology-specific functions.
The SDT approach is to define re-usable basic functions (or services) (labelled "ModuleClass" in figure 5.1.3.1-1)
which can represent the typical functions found in many home automation systems, such as "on/off", "dim a lamp",
"receive events from binary sensor", "read data from sensor", etc. Each ModuleClass is composed of a (small) number
of actions, datapoint read/write operations, or asynchronous events. For example, an "on/off" ModuleClass would
consist perhaps of just one Action, but a "ReadKeypad" Action might have a number of possible events, each with some
data value and (usually) a sequence-ID or timestamp start/stop to indicate when and how long each key was pressed.
ETSI

---------------------- Page: 9 ----------------------
oneM2M TR-0017 version 2.0.0 10 ETSI TR 118 517 V2.0.0 (2016-09)
C
B
A

Figure 5.1.3.1-1: SmartHome Device Template (XSD) for a generic device
(simplification of draft, under discussion with SDOs)
The SDT represents the device models introduced in figure 5.1.3.1-1 by using an XSD schema to allow formal checking
of compliance for XML device descriptions of specific appliances. The modularity goal in the XSD schema is
achieved with re-usable XSD fragments ("ModuleClass" in figure 5.1.3.1-1).
Complex devices or appliances can then be described by an appropriate set or collection of the agreed XSD fragments
(ModuleClasses), as indicated in figure 5.1.3.1-1, which also shows an optional DeviceInfo XSD fragment to allow
recording of static information such as device manufacturer name, device firmware version, etc.
Note that the SDT concept of ModuleClasses is similar to the HomeKit concept of "services".
HGI has discussed with many SDOs to validate the concept. Consultation with various industry fora continues, to
determine an appropriate set of commonly used ModuleClasses, which however allows extensions. SDT is designed to
take into account the list of "services" compiled by the SAREF project.
The SDT supports the use of a set of templates for generic devices or appliances (e.g. for a dimmable lamp, a basic
washing machine, etc., which would be specific instances of the "Device" object shown in figure 5.1.3.1-2) which form
the basis of APIs used by application developers. These templates can also be referenced by manufacturers creating
XML documents to describe their specific products. For example, the SDT enables specification of a generic washing
machine template, with on/off, set-wash-temperature, pause and a few other commands, which could be referenced by a
manufacturer as the schema for a XML description of a basic model washing machine. The SDT allows for vendor-
specific additional commands (ModuleClasses) to suit specific product types.
An example of how three different generic devices/appliances might be modelled using 4 different ModuleClasses is
shown in figure 5.1.3.1-2. Data values (DataPoints) which might need to be read/written during operation of the devices
are shown as the lowest grouping in the figure (DataPoints/Characteristics).

Figure 5.1.3.1-2: SmartHome Template for 3 examples of generic devices
ETSI

---------------------- Page: 10 ----------------------
oneM2M TR-0017 version 2.0.0 11 ETSI TR 118 517 V2.0.0 (2016-09)
Figure 5.1.3.4-1 showing the SDT structure in more detail is shown in clause 5.1.3.4. It is sufficiently flexible to allow
representation of e.g. the SAREF ontology or the future OneM2M ontology.
5.1.3.2 Definitions
This clause provides an overview about the SDT 3.0 definitions and element hierarchy. Terms to be described in detail
in this clause are:
Table 5.1.3.2-1: Definitions of SDT Elements
Term Definition
Domain Unique name, or "wrapper" which acts like a namespace, set by the organization creating
the SDT, allowing reference to a package of definitions for the contained ModuleClasses
and device definitions. Can be referenced when extending ModuleClasses. It has two
possible uses: to select the scope of a technology domain, or to set the scope of a use
case domain (like Home, SmartGrid, etc.).
Device Physical, addressable, identifiable appliance/sensor/actuator.
Sub-Device A device (usually one of several) which may be embedded in a Device and/or is addressed
via another Device.
ModuleClass Specification of a single service with one or more service methods, the involved
abstracted data model and related events. The expectation is that each separate service
which may be used in many kinds of Devices (like PowerON/OFF, Open/Close, etc.) will
be described by a ModuleClass which can be re-used in many Device definitions.
Module Instantiation of a ModuleClass for a specific Device or SubDevice.

5.1.3.3 Overview
Various details about recommended structure for SDTs are described in the next clauses. The key point to keep in mind
is that HGI sought a compromise between, at the one extreme, complete flexibility (which could describe any device, of
any complexity) and, at the other extreme, a rigid structure which could be 100 % validated and lead to validated
software APIs.
...