ISO/IEC 30118-9:2021
(Main)Information technology – Open Connectivity Foundation (OCF) Specification — Part 9: Core optional specification
Information technology – Open Connectivity Foundation (OCF) Specification — Part 9: Core optional specification
The OCF Core specifications are divided into a series of documents: Core specification: The Core specification document specifies the Framework, i.e., the OCF core architecture, interfaces, protocols and services to enable OCF profiles implementation for Internet of Things (IoT) usages and ecosystems. This document is mandatory for all Devices to implement. Core optional specification (this document): The Core optional specification document specifies the Framework, i.e., the OCF core architecture, interfaces, protocols and services to enable OCF profiles implementation for Internet of Things (IoT) usages and ecosystems that can optionally be implemented by any Device. Core extension specification(s): The Core extension specification(s) document(s) specifies optional OCF Core functionality that are significant in scope (e.g., Wi-Fi easy setup, Cloud).
Technologies de l'information — Specification de la Fondation pour la connectivité ouverte (Fondation OCF) — Partie 9: Spécification facultative du cœur
General Information
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 30118-9
First edition
2021-10
Information technology — Open
Connectivity Foundation (OCF)
Specification —
Part 9:
Core optional specification
Technologies de l'information — Specification de la Fondation pour la
connectivité ouverte (Fondation OCF) —
Partie 9: Spécification facultative du cœur
Reference number
ISO/IEC 30118-9:2021(E)
© ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC 30118-9:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 30118-9:2021(E)
Contents Page
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
4 Document conventions and organization . 3
4.1 Conventions . 3
4.2 Notation . 3
4.3 Data types . 4
5 Functional interactions . 4
5.1 Introduction . 4
5.2 Onboarding, provisioning and configuration . 4
5.3 Device management . 6
5.4 Scenes . 18
5.5 Rules . 22
5.6 Icons . 30
5.7 Alerts . 31
Annex A (normative) Resource Type definitions . 33
A.1 List of Resource Type definitions . 33
A.2 Device Configuration . 33
A.3 Platform Configuration . 38
A.4 Icon . 42
A.5 Maintenance . 45
A.6 Network Monitoring . 48
A.7 Scene List . 52
A.8 Scene Collection . 56
A.9 Scene Member . 62
A.10 Alert . 66
A.11 Alert Collection . 69
A.12 software update . 75
A.13 OCF Rule . 79
A.14 OCF Rule Input Collection . 84
A.15 OCF Rule Expression . 88
A.16 OCF Rule Action Collection . 91
A.17 OCF Rule Action . 96
© ISO/IEC 2021 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 30118-9:2021(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations, governmental and non-
governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described in
the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the ISO list
of patent declarations received (see www.iso.org/patents) or the IEC list of patent declarations received
(see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not constitute
an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html. In
the IEC, see www.iec.ch/understanding-standards.
This document was prepared by the Open Connectivity Foundation (OCF) (as OCF Core Optional Specification,
version 2.2.0) and drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS procedure,
by Joint Technical Committee ISO/IEC JTC 1, Information technology.
A list of all parts in the ISO/IEC 30118 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
iv © ISO/IEC 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 30118-9:2021(E)
Introduction
This document, and all the other parts associated with this document, were developed in response to
worldwide demand for smart home focused Internet of Things (IoT) devices, such as appliances, door
locks, security cameras, sensors, and actuators; these to be modelled and securely controlled, locally
and remotely, over an IP network.
While some inter-device communication existed, no universal language had been developed for the
IoT. Device makers instead had to choose between disparate frameworks, limiting their market share,
or developing across multiple ecosystems, increasing their costs. The burden then falls on end users
to determine whether the products they want are compatible with the ecosystem they bought into, or
find ways to integrate their devices into their network, and try to solve interoperability issues on their
own.
In addition to the smart home, IoT deployments in commercial environments are hampered by a lack
of security. This issue can be avoided by having a secure IoT communication framework, which this
standard solves.
The goal of these documents is then to connect the next 25 billion devices for the IoT, providing secure
and reliable device discovery and connectivity across multiple OSs and platforms. There are multiple
proposals and forums driving different approaches, but no single solution addresses the majority of
key requirements. This document and the associated parts enable industry consolidation around a
common, secure, interoperable approach.
ISO/IEC 30118 consists of eighteen parts, under the general title Information technology — Open
Connectivity Foundation (OCF) Specification. The parts fall into logical groupings as described herein:
– Core framework
– Part 1: Core Specification
– Part 2: Security Specification
– Part 13: Onboarding Tool Specification
– Bridging framework and bridges
– Part 3: Bridging Specification
– Part 6: Resource to Alljoyn Interface Mapping Specification
– Part 8: OCF Resource to oneM2M Resource Mapping Specification
– Part 14: OCF Resource to BLE Mapping Specification
– Part 15: OCF Resource to EnOcean Mapping Specification
– Part 16: OCF Resource to UPlus Mapping Specification
– Part 17: OCF Resource to Zigbee Cluster Mapping Specification
– Part 18: OCF Resource to Z-Wave Mapping Specification
– Resource and Device models
– Part 4: Resource Type Specification
– Part 5: Device Specification
– Core framework extensions
– Part 7: Wi-Fi Easy Setup Specification
– Part 9: Core Optional Specification
– OCF Cloud
– Part 10: Cloud API for Cloud Services Specification
– Part 11: Device to Cloud Services Specification
– Part 12: Cloud Security Specification
© ISO 2021 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 30118-9:2021(E)
Information technology — Open Connectivity
Foundation (OCF) Specification —
Part 9:
Core optional specification
1 Scope
The OCF Core specifications are divided into a series of documents:
– Core specification: The Core specification document specifies the Framework, i.e., the OCF core
architecture, interfaces, protocols and services to enable OCF profiles implementation for Internet
of Things (IoT) usages and ecosystems. This document is mandatory for all Devices to implement.
– Core optional specification (this document): The Core optional specification document specifies the
Framework, i.e., the OCF core architecture, interfaces, protocols and services to enable OCF
profiles implementation for Internet of Things (IoT) usages and ecosystems that can optionally be
implemented by any Device.
– Core extension specification(s): The Core extension specification(s) document(s) specifies optional
OCF Core functionality that are significant in scope (e.g., Wi-Fi easy setup, Cloud).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC DIS 20924, Information Technology – Internet of Things – Vocabulary, June 2018
https://www.iso.org/standard/69470.html
ISO/IEC 30118-1, Information technology – Open Connectivity Foundation (OCF) Specification –
Part 1: Core specification
https://www.iso.org/standard/53238.html
ISO/IEC 30118-2, Information technology – Open Connectivity Foundation (OCF) Specification –
Part 2: Security specification
https://www.iso.org/standard/74239.html
IETF RFC 3339, Date and Time on the Internet: Timestamps, July 2002
https://www.rfc-editor.org/info/rfc3339
IETF RFC 5234, Augmented BNF for Syntax Specifications: ABNF, January 2008
https://www.rfc-editor.org/info/rfc5234
IETF RFC 5424, The Syslog Protocol, March 2009
https://tools.ietf.org/html/rfc5424
IETF RFC 5646, Tags for Identifying Languages, September 2009
https://www.rfc-editor.org/info/rfc5646
IANA ifType-MIB Definitions
https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib
© ISO/IEC 2021 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC 30118-9:2021(E)
IANA Media Types Assignment, March 2017
http://www.iana.org/assignments/media-types/media-types.xhtml
OpenAPI specification, fka Swagger RESTful API Documentation Specification, Version 2.0
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 30118-1.
ISO/IEC 30118-2, and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
– ISO Online browsing platform: available at https://www.iso.org/obp
– IEC Electropedia: available at http://www.electropedia.org/
3.1.1
Alert
information provided by the Device by means of a specialised Resource Type that provides details with
regard to potential problems, issues, or Device status of interest on which action can be taken
3.1.2
Rule
Resource that implements autonomous decision logic according to a condition-action pattern
3.1.3
Rule Action
Resource that is actuated with a defined value when the Rule Result (3.1.6) holds "true"
3.1.4
Rule Expression
definition of the Rule (3.1.1) logic in terms of the defined Rule Inputs (3.1.5), and which evaluates to
a boolean Rule Result (3.1.6), for which "true" means that the Rule (3.1.1) has been triggered
3.1.5
Rule Input
Resources that contain the Properties whose values are evaluated as part of the Rule Expression
(3.1.4)
3.1.6
Rule Result
Property which reflects the result of the evaluation of the Rule Expression (3.1.4)
3.1.7
Scene
static entity that stores a set of defined Property values for a Collection of Resources
Note 1 to entry: A Scene (3.1.3) is a prescribed setting of a set of Resources with each having a predetermined value for
the Property that has to change.
3.1.8
Scene Collection
Collection that contains an enumeration of possible Scene Values (3.1.10) and the current Scene Value
(3.1.10)
Note 1 to entry: The member values of the Scene Collection (3.1.8) are Scene Members (3.1.9).
2 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 30118-9:2021(E)
3.1.9
Scene Member
Resource that contains mappings of Scene Values (3.1.10) to values of a Property in the Resource
3.1.10
Scene Value
Scene (3.1.3) enumerator representing the state in which a Resource can be
4 Document conventions and organization
4.1 Conventions
In this document a number of terms, conditions, mechanisms, sequences, parameters, events, states,
or similar terms are printed with the first letter of each word in uppercase and the rest lowercase (e.g.,
Network Architecture). Any lowercase uses of these words have the normal technical English meaning.
In this document, to be consistent with the IETF usages for RESTful operations, the RESTful operation
words CRUDN, CREATE, RETRIVE, UPDATE, DELETE, and NOTIFY will have all letters capitalized.
Any lowercase uses of these words have the normal technical English meaning.
4.2 Notation
In this document, features are described as required, recommended, allowed or DEPRECATED as
follows:
Required (or shall or mandatory)(M).
– These basic features shall be implemented to comply with Core Architecture. The phrases "shall
not", and "PROHIBITED" indicate behaviour that is prohibited, i.e. that if performed means the
implementation is not in compliance.
Recommended (or should)(S).
– These features add functionality supported by Core Architecture and should be implemented.
Recommended features take advantage of the capabilities Core Architecture, usually without
imposing major increase of complexity. Notice that for compliance testing, if a recommended
feature is implemented, it shall meet the specified requirements to be in compliance with these
guidelines. Some recommended features could become requirements in the future. The phrase
"should not" indicates behaviour that is permitted but not recommended.
Allowed (may or allowed)(O).
– These features are neither required nor recommended by Core Architecture, but if the feature is
implemented, it shall meet the specified requirements to be in compliance with these guidelines.
DEPRECATED.
– Although these features are still described in this document, they should not be implemented except
for backward compatibility. The occurrence of a deprecated feature during operation of an
implementation compliant with the current documenthas no effect on the implementation’s
operation and does not produce any error conditions. Backward compatibility may require that a
feature is implemented and functions as specified but it shall never be used by implementations
compliant with this document.
Conditionally allowed (CA).
– The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is allowed, otherwise it is not allowed.
Conditionally required (CR).
– The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is required. Otherwise the definition or behaviour is allowed as default
unless specifically defined as not allowed.
© ISO/IEC 2021 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC 30118-9:2021(E)
Strings that are to be taken literally are enclosed in "double quotes".
Words that are emphasized are printed in italic.
In all of the Property and Resource definition tables that are included throughout this document the
"Mandatory" column indicates that the item detailed is mandatory to implement; the mandating of
inclusion of the item in a Resource Payload associated with a CRUDN action is dependent on the
applicable schema for that action.
4.3 Data types
Resources are defined using data types derived from JSON values as defined in clause 4.3 in
ISO/IEC 30118-1.
5 Functional interactions
5.1 Introduction
The functional interactions between a Client and a Server are described in 5.2 through 5.7 respectively.
The functional interactions use CRUDN messages (clause 8 in ISO/IEC 30118-1) and include
Discovery, Notification, and Device management. These functions require support of core defined
Resources as defined in Table 1.
Table 1 – List of optional Core Resources
Pre-defined URI Resource Name Resource Type Related Functional Mandatory
Interaction
(none) Configuration "oic.wk.con" Device management No
(none) Configuration "oic.wk.con.p" Device management No
"/oic/mnt" Maintenance "oic.wk.mnt" Device management No
(none) Network monitoring "oic.wk.nmon" Device management No
(none) Software update "oic.wk.softwareupdate" Device management No
(none) Icon "oic.r.icon" Icons No
(none) Scene List "oic.wk.scenellist" Scenes No
(none) Scene Collection "oic.wk.scenecollection" Scenes No
(none) Scene Member "oic.wk.scenemember" Scenes No
(none) Alerts "oic.r.alert" Alerts No
(none) Alerts Collection "oic.r.alertcollection" Alerts No
5.2 Onboarding, provisioning and configuration
Onboarding and provisioning are fully defined by ISO/IEC 30118-2.
Should a Device support Client update of configurable information it shall do so via exposing an
"oic.wk.con" Core Resource (Table 2) in "/oic/res".
Table 2 – Configuration Resource
Example Resource Resource OCF Description Related
URI Type Title Type ID Interfaces Functional
("rt" value) Interaction
"/example/oi Device "oic.wk.con" "oic.if.rw" The Resource Type through which Configuration
c/con" configuration configurable information specific to
the Device is exposed.
4 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 30118-9:2021(E)
The Resource Properties exposed
in "oic.wk.con" are listed in
Table 3.
"/example/oi Platform "oic.wk.con.p" "oic.if.rw" The optional Resource Type Configuration
c/con" configuration through which configurable
information specific to the Platform
is exposed. The Properties
exposed in "oic.wk.con.p" are
listed in Table 4.
Table 3 defines the "oic.wk.con" Resource Type. Complete details are provided in annex A.2.
Table 3 – "oic.wk.con" Resource Type definition
Property Property Value type Value Unit Access Mandatory Description
title name rule mode
(Device) "n" "string" N/A N/A R, W Yes Human friendly name
Name (Common configurable by the end user (e.g.
Property of Bob's thermostat). The "n"
"/example/ Common Property of the
oic/con") oic.wk.con Core Resource and
the "n" Common Property of the
"/oic/d" Core Resource shall have
the same Value. When the "n"
Common Property Value of the
oic.wk.con Core Resource is
modified, it shall be reflected to
the "n" Common Property of
"/oic/d" Core Resource.
Location "loc" array of N/A Deg R, W No Provides location information
float (has rees where available.
two
elements,
the first is
latitude,
the second
is
longitude)
Location "locn" "string" N/A N/A R, W no Human friendly name for location
Name For example, "Living Room".
Currency "c" "string" N/A N/A R,W no Indicates the currency that is
used for any monetary
transactions
Region "r" "string" N/A N/A R,W no Free form text Indicating the
current region in which the
Device is located geographically.
Localized "ln" "array" N/A N/A R,W no Human-friendly name of the
Names Device, in one or more
languages. This Property is an
array of objects where each
object has a "language" field
(containing an IETF RFC 5646
language tag) and a "value" field
containing the Device name in
the indicated language. If this
Property and the Device Name
(n) Property are both supported,
the Device Name (n) value shall
be included in this array.
Default "dl" "language- N/A N/A R,W no The default language supported
Languag tag" by the Device, specified as an
e IETF RFC 5646 language tag. By
default, clients can treat any
string Property as being in this
language unless the Property
specifies otherwise.
© ISO/IEC 2021 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC 30118-9:2021(E)
Table 4 defines the "oic.wk.con.p" Resource Type. Complete details are provided in annex A.3.
Table 4 – "oic.wk.con.p" Resource Type definition
Property Property Value Value Unit Access Mandatory Description
title name type rule mode
Platform "mnpn" "array" N/A N/A R,W No Friendly name of the
Names Platform. This Property is
an array of objects where
each object has a
"language" field
(containing an
IETF RFC 5646 language
tag) and a "value" field
containing the platform
friendly name in the
indicated language.
For example,
[{"language":"en",
"value":"Dave’s Laptop"}]
5.3 Device management
5.3.1 Overview
Device management includes the following functions:
– Diagnostics and maintenance
– Network monitoring
5.3.2 Diagnostics and maintenance Resource Type
The Diagnostics and Maintenance Resource Type is intended to enable the resolution of issues
encountered with the Devices while operating in the field. If diagnostics and maintenance is supported
by a Device, the Core Resource "/oic/mnt" shall be supported as described in Table 5.
Table 5 – Optional diagnostics and maintenance Device management Core Resources
Pre-defined Resource Resource OCF Description Related
URI Type Title Type ID Interfaces Functional
("rt" value) Interaction
"/oic/mnt" Maintenance "oic.wk.mnt" "oic.if.rw" The Resource through which the Device
Device is maintained and can be management
used for diagnostic purposes.
The Properties exposed by
"/oic/mnt" are listed in Table 6.
Table 6 defines the "oic.wk.mnt" Resource Type. At least one of the Factory_Reset, Reboot, or last
error Properties shall be implemented. Complete details are provided in annex A.5.
Table 6 – "oic.wk.mnt" Resource Type definition
Property title Property Value Value Unit Access Mandatory Description
name type rule mode
Factory_Reset "fr" "boolean" N/A N/A R, W No When writing to this
Property:
false – No action (Default*)
true – Start Factory Reset
6 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 30118-9:2021(E)
When reading this Property,
a value of true indicates a
pending factory reset. Once
the factory reset has been
completed, the Device shall
set the value back to false.
This Property is functionally
equivalent to a transition to
a state of Hard Reset as
defined in ISO/IEC 30118-2,
clause 8.1
Reboot "rb" "boolean" N/A N/A R, W No When writing to this
Property:
false – No action (Default)
true – Start Reboot
After Reboot, this value
shall be changed back to
the default value (i.e., false)
Last error "err" "integer" HTTP N/A R No Last occurred error code,
error shall be cleared to 503
code (service unavailable), when
doing a Factory Reset or
Reboot.
All HTTP errors outside the
100, 200 or 300 range shall
be stored.
NOTE Default indicates the value of this Property as soon as the Device is rebooted or factory reset.
5.3.3 Core behaviours on Device maintenance state changes
5.3.3.1 Overview
As defined in ISO/IEC 30118-2 a Device has a state machine through which it transitions during its
operational lifetime.
ISO/IEC 30118-2 details actions on such state transitions for the Resources defined therein. This
clause defines the actions to be taken on such state transitions for the Resources and functionality
defined within this document.
The state transitions to be considered are:
– RFNOP to Soft Reset
– RFNOP to Hard Reset
– RFNOP to RFPRO
– RFPRO to RFNOP
Table 7 provides a summary of the actions to be taken in each case for functions defined in the
ISO/IEC 30118-2 and this document, other extensions to these documents may define further
behaviours.
Table 7 – Actions on Device state change
Soft reset Hard reset RFNOP -> RFPRO RFPRO -> RFNOP
SVR As per As per As per ISO/IEC 30118- As per ISO/IEC 30118-
ISO/IEC 30118-2 ISO/IEC 30118-2 2 clause 8.3 2 clause 8.4
clause 8.5 clause 8.1
Mandatory Core No change Reset to defined No change No change
Resources defaults, see clause
5.3.3.3.3
© ISO/IEC 2021 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC 30118-9:2021(E)
Optional Core No change Reset to defined No change No change
Resources defaults, see clause
5.3.3.3.4
Vertical No change Reset to defined No change No change
Resources defaults; see clause
5.3.3.3
Created No change Deleted No change No change
Resources
Observe No change Canceled; see clause No change Re-evaluate ACL; see
Transactions 5.3.3.2 clause 5.3.3.2
OCF Cloud No change See clause Error! No change No change
Reference source
not found.
5.3.3.2 Handling of Observe transactions
On a transition to hard reset all active Observe transactions shall be cancelled by the Server by sending
a "Service Unavailable" response on each active Observe transaction.
On a state transition that allows for modification of the access controls that exist against a Resource
(such as from RFPRO to RFNOP) it is possible that the access controls themselves as defined within
the ISO/IEC 30118-2 are changed such that the original RETRIEVE operation that established the
Observe would not have been allowed. In such instances the Server shall cancel the Observe by
sending a "Service Unavailable" response on the Observe transaction.
5.3.3.3 Reset of Resource Properties to defined defaults
5.3.3.3.1 Overview
On a hard or factory reset Resource Properties are reset to default values. These are commonly
referred to as manufacturer defaults however it is not possible in all instances to revert to such values
as they may not be known or be practicable.
The default values to be applied for the mandatory and optional Core Resources, pl
...
INTERNATIONAL ISO/IEC
STANDARD 30118-9
First edition
Information technology — Open
Connectivity Foundation (OCF) —
Part 9:
Core optional specification
PROOF/ÉPREUVE
Reference number
ISO/IEC 30118-9:2021(E)
©
ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC 30118-9:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 30118-9:2021(E)
Contents
Foreword . iv
Introduction . v
Scope. 1
Normative references . 1
Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
Document conventions and organization . 3
4.1 Conventions . 3
4.2 Notation . 3
4.3 Data types . 4
Functional interactions . 4
5.1 Introduction . 4
5.2 Onboarding, provisioning and configuration . 4
5.3 Device management . 6
5.4 Scenes . 18
5.5 Rules . 22
5.6 Icons . 30
5.7 Alerts . 31
A.1 List of Resource Type definitions . 33
A.2 Device Configuration . 33
A.3 Platform Configuration . 38
A.4 Icon . 42
A.5 Maintenance . 45
A.6 Network Monitoring . 48
A.7 Scene List . 52
A.8 Scene Collection . 56
A.9 Scene Member . 62
A.10 Alert . 66
A.11 Alert Collection . 69
A.12 software update . 75
A.13 OCF Rule . 79
A.14 OCF Rule Input Collection . 84
A.15 OCF Rule Expression . 88
A.16 OCF Rule Action Collection . 91
A.17 OCF Rule Action . 96
© ISO/IEC 2021 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 30118-9:2021(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations, governmental and non-
governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described in
the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the ISO list
of patent declarations received (see www.iso.org/patents) or the IEC list of patent declarations received
(see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not constitute
an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html. In
the IEC, see www.iec.ch/understanding-standards.
This document was prepared by the Open Connectivity Foundation (OCF) (as OCF Wi-Fi Easy Setup
Specification, version 2.2.0) and drafted in accordance with its editorial rules. It was adopted, under the JTC 1
PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology.
A list of all parts in the ISO/IEC 30118 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2021 – All rights reserved iv
---------------------- Page: 4 ----------------------
ISO/IEC 30118-9:2021(E)
Introduction
This document, and all the other parts associated with this document, were developed in response to
worldwide demand for smart home focused Internet of Things (IoT) devices, such as appliances, door
locks, security cameras, sensors, and actuators; these to be modelled and securely controlled, locally
and remotely, over an IP network.
While some inter-device communication existed, no universal language had been developed for the
IoT. Device makers instead had to choose between disparate frameworks, limiting their market share,
or developing across multiple ecosystems, increasing their costs. The burden then falls on end users
to determine whether the products they want are compatible with the ecosystem they bought into, or
find ways to integrate their devices into their network, and try to solve interoperability issues on their
own.
In addition to the smart home, IoT deployments in commercial environments are hampered by a lack
of security. This issue can be avoided by having a secure IoT communication framework, which this
standard solves.
The goal of these documents is then to connect the next 25 billion devices for the IoT, providing secure
and reliable device discovery and connectivity across multiple OSs and platforms. There are multiple
proposals and forums driving different approaches, but no single solution addresses th e majority of
key requirements. This document and the associated parts enable industry consolidation around a
common, secure, interoperable approach.
ISO/IEC 30118 consists of eighteen parts, under the general title Information technology — Open
Connectivity Foundation (OCF) Specification. The parts fall into logical groupings as described herein:
– Core framework
– Part 1: Core Specification
– Part 2: Security Specification
– Part 13: Onboarding Tool Specification
– Bridging framework and bridges
– Part 3: Bridging Specification
– Part 6: Resource to Alljoyn Interface Mapping Specification
– Part 8: OCF Resource to oneM2M Resource Mapping Specification
– Part 14: OCF Resource to BLE Mapping Specification
– Part 15: OCF Resource to EnOcean Mapping Specification
– Part 16: OCF Resource to UPlus Mapping Specification
– Part 17: OCF Resource to Zigbee Cluster Mapping Specification
– Part 18: OCF Resource to Z-Wave Mapping Specification
– Resource and Device models
– Part 4: Resource Type Specification
– Part 5: Device Specification
– Core framework extensions
– Part 7: Wi-Fi Easy Setup Specification
– Part 9: Core Optional Specification
– OCF Cloud
– Part 10: Cloud API for Cloud Services Specification
– Part 11: Device to Cloud Services Specification
– Part 12: Cloud Security Specification
v © ISO 2021 – All rights reserved
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 30118-9:2021(E)
Information Technology — Open Connectivity
Foundation (OCF) Specification —
Part 9:
Core optional specification
1 Scope
The OCF Core specifications are divided into a series of documents:
– Core specification: The Core specification document specifies the Fram ework, i.e., the OCF core
architecture, interfaces, protocols and services to enable OCF profiles implementation for Internet
of Things (IoT) usages and ecosystems. This document is mandatory for all Devices to implement.
– Core optional specification (this document): The Core optional specification document specifies the
Framework, i.e., the OCF core architecture, interfaces, protocols and services to enable OCF
profiles implementation for Internet of Things (IoT) usages and ecosystems that can optionally be
implemented by any Device.
– Core extension specification(s): The Core extension specification(s) document(s) specifies optional
OCF Core functionality that are significant in scope (e.g., Wi-Fi easy setup, Cloud).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC DIS 20924, Information Technology – Internet of Things – Vocabulary, June 2018
https://www.iso.org/standard/69470.html
ISO/IEC 30118-1, Information technology – Open Connectivity Foundation (OCF) Specification –
Part 1: Core specification
https://www.iso.org/standard/53238.html
ISO/IEC 30118-2, Information technology – Open Connectivity Foundation (OCF) Specification –
Part 2: Security specification
https://www.iso.org/standard/74239.html
IETF RFC 3339, Date and Time on the Internet: Timestamps, July 2002
https://www.rfc-editor.org/info/rfc3339
IETF RFC 5234, Augmented BNF for Syntax Specifications: ABNF, January 2008
https://www.rfc-editor.org/info/rfc5234
IETF RFC 5424, The Syslog Protocol, March 2009
https://tools.ietf.org/html/rfc5424
IETF RFC 5646, Tags for Identifying Languages, September 2009
https://www.rfc-editor.org/info/rfc5646
IANA ifType-MIB Definitions
https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib
© ISO/IEC 2021 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC 30118-9:2021(E)
IANA Media Types Assignment, March 2017
http://www.iana.org/assignments/media-types/media-types.xhtml
OpenAPI specification, fka Swagger RESTful API Documentation Specification, Version 2.0
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 30118-1.
ISO/IEC 30118-2, and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
– ISO Online browsing platform: available at https://www.iso.org/obp.
– IEC Electropedia: available at http://www.electropedia.org/.
3.1.1
Alert
information provided by the Device by means of a specialised Resource Type that provides details with
regard to potential problems, issues, or Device status of interest on which action can be taken
3.1.2
Rule
Resource that implements autonomous decision logic according to a condition-action pattern
3.1.3
Rule Action
Resource that is actuated with a defined value when the Rule Result (3.1.6) holds "true"
3.1.4
Rule Expression
definition of the Rule (3.1.1) logic in terms of the defined Rule Inputs (3.1.5), and which evaluates to
a boolean Rule Result (3.1.6), for which "true" means that the Rule (3.1.1) has been triggered
3.1.5
Rule Input
Resources that contain the Properties whose values are evaluated as part of the Rule Expression
(3.1.4)
3.1.6
Rule Result
Property which reflects the result of the evaluation of the Rule Expression (3.1.4)
3.1.7
Scene
static entity that stores a set of defined Property values for a Collection of Resources
Note 1 to entry: A Scene (3.1.3) is a prescribed setting of a set of Resources with each having a predetermined value for
the Property that has to change.
3.1.8
Scene Collection
Collection that contains an enumeration of possible Scene Values (3.1.10) and the current Scene Value
(3.1.10)
Note 1 to entry: The member values of the Scene Collection (3.1.8) are Scene Members (3.1.9).
2 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 30118-9:2021(E)
3.1.9
Scene Member
Resource that contains mappings of Scene Values (3.1.10) to values of a Property in the Resource
3.1.10
Scene Value
Scene (3.1.3) enumerator representing the state in which a Resource can be
4 Document conventions and organization
4.1 Conventions
In this document a number of terms, conditions, mechanisms, sequences, parameters, events, states,
or similar terms are printed with the first letter of each word in uppercase and the rest lowercase (e.g.,
Network Architecture). Any lowercase uses of these words have the normal technical English meaning.
In this document, to be consistent with the IETF usages for RESTful operations, the RESTful operation
words CRUDN, CREATE, RETRIVE, UPDATE, DELETE, and NOTIFY will have all letters capitalized.
Any lowercase uses of these words have the normal technical English meaning.
4.2 Notation
In this document, features are described as required, recommended, allowed or DEPRECATED as
follows:
Required (or shall or mandatory)(M).
– These basic features shall be implemented to comply with Core Architecture. The phrases "shall
not", and "PROHIBITED" indicate behaviour that is prohibited, i.e. that if performed means the
implementation is not in compliance.
Recommended (or should)(S).
– These features add functionality supported by Core Architecture and should be implemented.
Recommended features take advantage of the capabilities Core Architecture, usually without
imposing major increase of complexity. Notice that for compliance testing, if a recommended
feature is implemented, it shall meet the specified requirements to be in compliance with these
guidelines. Some recommended features could become requirements in the future. The phrase
"should not" indicates behaviour that is permitted but not recommended.
Allowed (may or allowed)(O).
– These features are neither required nor recommended by Core Architecture, but if the feature is
implemented, it shall meet the specified requirements to be in compliance with these guidelines.
DEPRECATED.
– Although these features are still described in this document, they should not be implemented except
for backward compatibility. The occurrence of a deprecated feature during operation of an
implementation compliant with the current documenthas no effect on the implementation’s
operation and does not produce any error conditions. Backward compatibility may require that a
feature is implemented and functions as specified but it shall never be used by implementations
compliant with this document.
Conditionally allowed (CA).
– The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is allowed, otherwise it is not allowed.
Conditionally required (CR).
– The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is required. Otherwise the definition or behaviour is allowed as default
unless specifically defined as not allowed.
© ISO/IEC 2021 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC 30118-9:2021(E)
Strings that are to be taken literally are enclosed in "double quotes".
Words that are emphasized are printed in italic.
In all of the Property and Resource definition tables that are included throughout this document the
"Mandatory" column indicates that the item detailed is mandatory to implement; the mandating of
inclusion of the item in a Resource Payload associated with a CRUDN action is dependent on the
applicable schema for that action.
4.3 Data types
Resources are defined using data types derived from JSON values as defined in clause 4.3 in
ISO/IEC 30118-1.
5 Functional interactions
5.1 Introduction
The functional interactions between a Client and a Server are described in 5.2 through 5.7 respectively.
The functional interactions use CRUDN messages (clause 8 in ISO/IEC 30118-1) and include
Discovery, Notification, and Device management. These functions require support of core defined
Resources as defined in Table 1.
Table 1 – List of optional Core Resources
Pre-defined URI Resource Name Resource Type Related Functional Mandatory
Interaction
(none) Configuration "oic.wk.con" Device management No
(none) Configuration "oic.wk.con.p" Device management No
"/oic/mnt" Maintenance "oic.wk.mnt" Device management No
(none) Network monitoring "oic.wk.nmon" Device management No
(none) Software update "oic.wk.softwareupdate" Device management No
(none) Icon "oic.r.icon" Icons No
(none) Scene List "oic.wk.scenellist" Scenes No
(none) Scene Collection "oic.wk.scenecollection" Scenes No
(none) Scene Member "oic.wk.scenemember" Scenes No
(none) Alerts "oic.r.alert" Alerts No
(none) Alerts Collection "oic.r.alertcollection" Alerts No
5.2 Onboarding, provisioning and configuration
Onboarding and provisioning are fully defined by ISO/IEC 30118-2.
Should a Device support Client update of configurable information it shall do so via exposing an
"oic.wk.con" Core Resource (Table 2) in "/oic/res".
Table 2 – Configuration Resource
Example Resource Resource OCF Description Related
URI Type Title Type ID Interfaces Functional
("rt" value) Interaction
"/example/oi Device "oic.wk.con" "oic.if.rw" The Resource Type through which Configuration
c/con" configuration configurable information specific to
the Device is exposed.
4 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 30118-9:2021(E)
The Resource Properties exposed
in "oic.wk.con" are listed in
Table 3.
"/example/oi Platform "oic.wk.con.p" "oic.if.rw" The optional Resource Type Configuration
c/con" configuration through which configurable
information specific to the Platform
is exposed. The Properties
exposed in "oic.wk.con.p" are
listed in Table 4.
Table 3 defines the "oic.wk.con" Resource Type. Complete details are provided in annex A.2.
Table 3 – "oic.wk.con" Resource Type definition
Property Property Value type Value Unit Access Mandatory Description
title name rule mode
(Device) "n" "string" N/A N/A R, W Yes Human friendly name
Name (Common configurable by the end user (e.g.
Property of Bob's thermostat). The "n"
"/example/ Common Property of the
oic/con") oic.wk.con Core Resource and
the "n" Common Property of the
"/oic/d" Core Resource shall have
the same Value. When the "n"
Common Property Value of the
oic.wk.con Core Resource is
modified, it shall be reflected to
the "n" Common Property of
"/oic/d" Core Resource.
Location "loc" array of N/A Deg R, W No Provides location information
float (has rees where available.
two
elements,
the first is
latitude,
the second
is
longitude)
Location "locn" "string" N/A N/A R, W no Human friendly name for location
Name For example, "Living Room".
Currency "c" "string" N/A N/A R,W no Indicates the currency that is
used for any monetary
transactions
Region "r" "string" N/A N/A R,W no Free form text Indicating the
current region in which the
Device is located geographically.
Localized "ln" "array" N/A N/A R,W no Human-friendly name of the
Names Device, in one or more
languages. This Property is an
array of objects where each
object has a "language" field
(containing an IETF RFC 5646
language tag) and a "value" field
containing the Device name in
the indicated language. If this
Property and the Device Name
(n) Property are both supported,
the Device Name (n) value shall
be included in this array.
Default "dl" "language- N/A N/A R,W no The default language supported
Languag tag" by the Device, specified as an
e IETF RFC 5646 language tag. By
default, clients can treat any
string Property as being in this
language unless the Property
specifies otherwise.
© ISO/IEC 2021 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC 30118-9:2021(E)
Table 4 defines the "oic.wk.con.p" Resource Type. Complete details are provided in annex A.3.
Table 4 – "oic.wk.con.p" Resource Type definition
Property Property Value Value Unit Access Mandatory Description
title name type rule mode
Platform "mnpn" "array" N/A N/A R,W No Friendly name of the
Names Platform. This Property is
an array of objects where
each object has a
"language" field
(containing an
IETF RFC 5646 language
tag) and a "value" field
containing the platform
friendly name in the
indicated language.
For example,
[{"language":"en",
"value":"Dave’s Laptop"}]
5.3 Device management
5.3.1 Overview
Device management includes the following functions:
– Diagnostics and maintenance
– Network monitoring
5.3.2 Diagnostics and maintenance Resource Type
The Diagnostics and Maintenance Resource Type is intended to enable the resolution of issues
encountered with the Devices while operating in the field. If diagnostics and maintenance is supported
by a Device, the Core Resource "/oic/mnt" shall be supported as described in Table 5.
Table 5 – Optional diagnostics and maintenance Device management Core Resources
Pre-defined Resource Resource OCF Description Related
URI Type Title Type ID Interfaces Functional
("rt" value) Interaction
"/oic/mnt" Maintenance "oic.wk.mnt" "oic.if.rw" The Resource through which the Device
Device is maintained and can be management
used for diagnostic purposes.
The Properties exposed by
"/oic/mnt" are listed in Table 6.
Table 6 defines the "oic.wk.mnt" Resource Type. At least one of the Factory_Reset, Reboot, or last
error Properties shall be implemented. Complete details are provided in annex A.5.
Table 6 – "oic.wk.mnt" Resource Type definition
Property title Property Value Value Unit Access Mandatory Description
name type rule mode
Factory_Reset "fr" "boolean" N/A N/A R, W No When writing to this
Property:
false – No action (Default*)
true – Start Factory Reset
6 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 30118-9:2021(E)
When reading this Property,
a value of true indicates a
pending factory reset. Once
the factory reset has been
completed, the Device shall
set the value back to false.
This Property is functionally
equivalent to a transition to
a state of Hard Reset as
defined in ISO/IEC 30118-2,
clause 8.1
Reboot "rb" "boolean" N/A N/A R, W No When writing to this
Property:
false – No action (Default)
true – Start Reboot
After Reboot, this value
shall be changed back to
the default value (i.e., false)
Last error "err" "integer" HTTP N/A R No Last occurred error code,
error shall be cleared to 503
code (service unavailable), when
doing a Factory Reset or
Reboot.
All HTTP errors outside the
100, 200 or 300 range shall
be stored.
NOTE Default indicates the value of this Property as soon as the Device is rebooted or factory reset.
5.3.3 Core behaviours on Device maintenance state changes
5.3.3.1 Overview
As defined in ISO/IEC 30118-2 a Device has a state machine through which it transitions during its
operational lifetime.
ISO/IEC 30118-2 details actions on such state transitions for the Resources defined therein. This
clause defines the actions to be taken on such state transitions for the Resources and functionality
defined within this document.
The state transitions to be considered are:
– RFNOP to Soft Reset
– RFNOP to Hard Reset
– RFNOP to RFPRO
– RFPRO to RFNOP
Table 7 provides a summary of the actions to be taken in each case for functions defined in the
ISO/IEC 30118-2 and this document, other extensions to these documents may define further
behaviours.
Table 7 – Actions on Device state change
Soft reset Hard reset RFNOP -> RFPRO RFPRO -> RFNOP
SVR As per As per As per ISO/IEC 30118- As per ISO/IEC 30118-
ISO/IEC 30118-2 ISO/IEC 30118-2 2 clause 8.3 2 clause 8.4
clause 8.5 clause 8.1
Mandatory Core No change Reset to defined No change No change
Resources defaults, see clause
5.3.3.3.3
© ISO/IEC 2021 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC 30118-9:2021(E)
Optional Core No change Reset to defined No change No change
Resources defaults, see clause
5.3.3.3.4
Vertical No change Reset to defined No change No change
Resources defaults; see clause
5.3.3.3
Created No change Deleted No change No change
Resources
Observe No change Canceled; see clause No change Re-evaluate ACL; see
Transactions 5.3.3.2 clause 5.3.3.2
OCF Cloud No change See clause Error! No change No change
Reference source
not found.
5.3.3.2 Handling of Observe transactions
On a transition to hard reset all active Observe transactions shall be cancelled by the Server by sending
a "Service Unavailable" response on each active Observe transaction.
On a state transition that allows for modification of the access controls that exist against a Resource
(such as from RFPRO to RFNOP) it is possible that the access controls themselves as defined within
the ISO/IEC 30118-2 are changed such that the original RETRIEVE operation that established the
Observe would not have been allowed. In such instances the Server s hall cancel the Observe by
sending a "Service Unavailable" response on the Observe transaction.
5.3.3.3 Reset of Resource Properties to defined defaults
5.3.3.3.1 Overview
On a hard or factory reset Resource Properties are reset to default values. These are commonly
referred to as manufacturer defaults however it is not possible in all instances to revert to such values
as they may not be known or be practicable.
The default values to be applied for the mandatory and optional Core Resources, plus any Vertical
Resources are defined in clauses 5.3.3.3.2 through 5.3.3.3.4 respectively.
5.3.3.3.2 Defaults for Vertical Resources
Default values for any Vertical Resources exposed by a Device are up to the implementation.
5.3.3.3.3 Defaults for mandatory Core Resurces
Table 8 and Table 9 capture default values that shall be set for mandatory Properties of the mandatory
Core Resources where those Resources contain Properties that can be changed by a Client. This
excludes "/oic/res" as that has no mutable Properties.
Table 8 – Defaul
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.