ISO/IEC 30118-16:2021
(Main)Information technology — Open Connectivity Foundation (OCF) Specification — Part 16: OCF resource to UPlus mapping specification
Information technology — Open Connectivity Foundation (OCF) Specification — Part 16: OCF resource to UPlus mapping specification
This document provides detailed mapping information between UPlus (U+) and OCF defined Resources.
Technologies de l'information — Specification de la Fondation pour la connectivité ouverte (Fondation OCF) — Partie 16: Spécification du mapping entre les ressources OCF et UPlus
General Information
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 30118-16
First edition
2021-10
Information technology — Open
Connectivity Foundation (OCF)
Specification —
Part 16:
OCF resource to UPlus mapping
specification
Technologies de l'information — Specification de la Fondation pour la
connectivité ouverte (Fondation OCF) —
Partie 16: Spécification du mapping entre les ressources OCF et UPlus
Reference number
ISO/IEC 30118-16:2021(E)
© ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC 30118-16: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-16:2021(E)
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions symbols and abbreviations . 1
4 Document conventions and organization . 2
4.1 Conventions . 2
4.2 Notation . 2
5 Theory of operation . 3
5.1 Interworking approach . 3
5.2 Mapping syntax . 3
5.2.1 Introduction . 3
5.2.2 General . 3
5.2.3 Value assignment . 3
5.2.4 Property naming . 3
5.2.5 Range . 3
5.2.6 Arrays . 3
5.2.7 Default mapping . 4
5.2.8 Conditional mapping . 4
5.2.9 Method invocation . 4
6 U+ translation . 4
6.1 Operational scenarios . 4
6.1.1 Introduction . 4
6.1.2 Use case for U+ bridging . 5
6.2 Requirements specific to U+ translator . 5
6.2.1 General . 5
6.2.2 Requirements specific to U+ . 5
6.2.3 Exposing U+ servers to OCF clients . 5
7 Device type mapping . 11
7.1 Introduction . 11
7.2 U+ device types to OCF device types . 11
8 Resource to U+ property equivalence . 11
8.1 Introduction . 11
8.2 U+ property to OCF resources . 11
9 Detailed mapping APIs . 12
9.1 Introduction . 12
9.2 Air conditioner mapping . 12
9.2.1 Derived model . 12
9.2.2 Property definition . 12
9.2.3 Derived model definition . 13
9.3 Air purifier mapping . 14
9.3.1 Derived model . 14
9.3.2 Property definition . 14
9.3.3 Derived model definition . 14
9.4 Water heater mapping . 15
© ISO/IEC 2021 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 30118-16:2021(E)
9.4.1 Derived model . 15
9.4.2 Property definition . 15
9.4.3 Derived model definition . 16
iv © ISO/IEC 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 30118-16: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 Resource to UPlus Mapping,
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 v
---------------------- Page: 5 ----------------------
ISO/IEC 30118-16: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
vi © ISO/IEC 2021 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC 30118-16:2021(E)
– 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/IEC 2021 – All rights reserved vii
---------------------- Page: 7 ----------------------
INTERNATIONAL STANDARD ISO/IEC 30118-16:2021(E)
Information technology — Open Connectivity
Foundation (OCF) Specification —
Part 16:
OCF resource to UPlus mapping specification
1 Scope
This document provides detailed mapping information between UPlus (U+) and OCF defined
Resources.
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 30118-1 Information technology – Open Connectivity Foundation (OCF) Specification -- Part 1:
Core specification
https://www.iso.org/standard/53238.html
Latest version available at: https://openconnectivity.org/specs/OCF_Core_Specification.pdf
ISO/IEC 30118-2 Information technology – Open Connectivity Foundation (OCF) Specification – Part 2:
Security specification
https://www.iso.org/standard/74239.html
Latest version available at: https://openconnectivity.org/specs/OCF_Security_Specification.pdf
ISO/IEC 30118-3 Information technology – Open Connectivity Foundation (OCF) Specification – Part 3:
Bridging specification
https://www.iso.org/standard/74240.html
Latest version available at: https://openconnectivity.org/specs/OCF_Bridging_Specification.pdf
Derived Models for Interoperability between IoT Ecosystems, Stevens & Merriam, March 2016
https://www.iab.org/wp-content/IAB-uploads/2016/03/OCF-Derived-Models-for-Interoperability-
Between-IoT-Ecosystems_v2-examples.pdf
3 Terms, definitions symbols and abbreviations
For the purposes of this document, the terms and definitions given in ISO/IEC 30118-1,
ISO/IEC 30118-2, and ISO/IEC 30118-3 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/
© ISO/IEC 2021 – All rights reserved 1
---------------------- Page: 8 ----------------------
ISO/IEC 30118-16:2021(E)
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).
These basic features shall be implemented to comply with the Mapping Specification. The phrases
"shall not", and "PROHIBITED" indicate behavior that is prohibited, i.e. that if performed means the
implementation is not in compliance.
Recommended (or should).
These features add functionality supported by the Mapping Specification and should be
implemented. Recommended features take advantage of the capabilities the Mapping Specification,
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 behavior that is permitted but not recommended.
Allowed (or allowed).
These features are neither required nor recommended by the Mapping Specification, but if the
feature is implemented, it shall meet the specified requirements to be in compliance with these
guidelines.
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.
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 document has 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.
2 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 30118-16:2021(E)
Strings that are to be taken literally are enclosed in "double quotes".
Words that are emphasized are printed in italic.
5 Theory of operation
5.1 Interworking approach
The interworking between UPlus (U+) and OCF defined Resources is modelled using the derived model
syntax described in Derived Models for Interoperability between IoT Ecosystems.
5.2 Mapping syntax
5.2.1 Introduction
Within the defined syntax for derived modelling used by this document there are two blocks that define
the actual Property-Property equivalence or mapping. These blocks are identified by the keywords "x-
to-ocf" and "x-from-ocf". Derived Models for Interoperability between IoT Ecosystems does not define
a rigid syntax for these blocks; they are free form string arrays that contain pseudo-coded mapping
logic.
Within this document we apply the rules in defined in clause 5.2 to these blocks to ensure consistency
and re-usability and extensibility of the mapping logic that is defined.
5.2.2 General
All statements are terminated with a carriage return.
5.2.3 Value assignment
The equals sign (=) is used to assign one value to another. The assignee is on the left of the operator;
the value being assigned on the right.
5.2.4 Property naming
All Property names are identical to the name used by the original model; for example, from the OCF
Temperature Resource the Property name "temperature" is used whereas when referred to the derived
ecosystem then the semantically equivalent Property name is used.
The name of the OCF defined Property is prepended by the ecosystem designator "ocf" to avoid
ambiguity (e.g. "ocf.step")
5.2.5 Range
The range on the OCF side is fixed.
5.2.6 Arrays
An array element is indicated by the use of square brackets "[]" with the index of the element contained
therein, e.g. range [1]. All arrays start at an index of 0.
© ISO/IEC 2021 – All rights reserved 3
---------------------- Page: 10 ----------------------
Bridging
Function
ISO/IEC 30118-16:2021(E)
5.2.7 Default mapping
There are cases where the specified mapping is not possible as one or more of the Properties being
mapped is optional in the source model. In all such instances a default mapping is provided. (e.g.
"transitiontime = 1").
5.2.8 Conditional mapping
When a mapping is dependent on the meeting of other conditions then the syntax:
If "condition", then "mapping".
is applied.
E.g. if onoff = false, then ocf.value = false
5.2.9 Method invocation
The invocation of a command from the derived ecosystem as part of the mapping from an OCF
Resource is indicated by the use if a double colon "::" delimiter between the applicable resource,
service, interface or other construct identifier and the command name. The command name always
includes trailing parentheses which would include any parameters should they be passed.
6 U+ translation
6.1 Operational scenarios
6.1.1 Introduction
The goal is to make Bridged U+ Servers appear to OCF Clients as if they were native OCF Servers.
"Deep translation" between specific U+ properties and OCF resources is specified in clause 9.
Figure 1 shows an overview of OCF U+ Bridge Platform and its general topology. The U+ Translator
supports asymmetric bridging. It exposes U+ Servers to OCF Clients. Each Bridged U+ Server is
represented as a Virtual OCF Server.
Bridge Platform
UPlus Bridge
Virtual
Virtual
OCF Bridged Bridged
OCF Uplus
OCF
Protocol Protocol
Client UPlus UPlus Server
Server
Client
Figure 1 – OCF U+ Bridge Platform and Components
4 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 30118-16:2021(E)
6.1.2 Use case for U+ bridging
Figure 2 shows a use case for U+ bridging. U+ washer air conditioner is installed in the user’s house.
The user uses OCF Client application on the smartphone to control the washer. OCF U+ Bridge
Platform can reside in different physical platforms, for example, the smartphone, the washer or the
gateway device.
Any connectivity Any connectivity that
that U+ supports OCF supports
OCF U+
U+ Device OCF Device
Bridge
(server) (client)
Platform
Figure 2 – U+ Bridging Use Case
6.2 Requirements specific to U+ translator
6.2.1 General
OCF U+ Bridge Platform shall satisfy the normative requirements from ISO/IEC 30118-3.
6.2.2 Requirements specific to U+
This document refers to version 5.0.0 or higher of U+ SDK.
6.2.3 Exposing U+ servers to OCF clients
6.2.3.1 General
Table 1 shows translation rule between U+ and OCF data model. One U+ Device Type is mapped to
one OCF Device Type or one OCF Composite Device. One or more U+ Properties are mapped to one
OCF Resource Type.
Table 1 – Translation Rule between U+ and OCF Data Model
From U+ mapping count To OCF mapping count
U+ Device Type 1 OCF Device Type 1
OCF Resource 1
U+ Property n
OCF Property n
Table 2 shows an example of the translation rule, which maps U+ air conditioner to OCF air conditioner.
– U+ Property "onOffStatus" is mapped to OCF Resource Property "value" which belongs to OCF
Resource "oic.r.switch.binary".
© ISO/IEC 2021 – All rights reserved 5
---------------------- Page: 12 ----------------------
ISO/IEC 30118-16:2021(E)
– U+ Property "targetTemperature" is mapped to OCF Resource Property "temperature" and "units"
combined which both belong to OCF Resource "oic.r.temperature".
– U+ Property "indoorTemperature", "windDirectionVertical", "windDirectionHorizontal" and
"windSpeed" together are mapped to OCF Resource Property "supportedDirections", "direction",
"speed" and "automode" combined which all belong to OCF Resource "oic.r.airflow".
– U+ Property "operationMode" and "healthMode" together are mapped to OCF Resource Property
"supportedModes" and "modes" combined which both belong to OCF Resource "oic.r.mode".
Table 2 – Example of Translation between U+ and OCF Data Model
From U+ Air Conditioner To OCF Air Conditioner
U+ Property OCF Resource OCF Resource Property
"onOffStatus" "oic.r.switch.binary" "value"
"temperature"
"targetTemperature" "oic.r.temperature"
"units"
"indoorTemperature" "supportedDirections"
"windDirectionVertical" "direction"
"oic.r.airflow"
"windDirectionHorizontal" "speed"
"windSpeed" "automode"
"operationMode" "supportedModes"
"oic.r.mode"
"healthMode" "modes"
6.2.3.2 Deep translation for U+ property
All U+ devices are well defined. Table 3 is the mapping between U+ devices and their properties and
OCF Devices and Resources. Table 3 includes a full list of U+ devices to be mapped to OCF. Table 4,
Table 5, and Table 6 define the mapping between OCF core Resources and U+ properties.
Table 3 – Mapping between U+ device and property and OCF device and resource
U+ Device U+ Property OCF Resource Type OCF Device OCF Device Type ("rt")
Name
Air Conditioner "onOffStatus" "oic.r.switch.binary" Air Conditioner "oic.d.airconditioner"
"targetTemperature" "oic.r.temperature"
"windSpeed" "oic.r.selectablelevels"
"operationMode" "oic.r.mode"
Water Heater "onOffStatus" oic.r.switch.binary Water Heater "oic.d.waterheater"
"oic.r.temperature"
"targetTemperature"
Air Purifier "onOffStatus" "oic.r.switch.binary" Air Purifier "oic.d.airpurifier"
"mode" "oic.r.operational.state"
"windSpeed" "oic.r.selectablelevels"
Table 4 shows the mapping between the properties of "oic.wk.d" Resource Type (see ISO/IEC 30118-1)
and the properties of U+ device.
6 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 30118-16:2021(E)
Table 4 – "oic.wk.d" Resource Type definition
To OCF OCF OCF Description OCF From U+ U+ Description U+
Property title Property Mand Property Mand
name atory value atory
(Device) "n" Human friendly name Yes "deviceId" An unique ID of the Device Yes
Name defined by the vendor.
In the presence of "n"
Property of "/oic/con",
both have the same
Property Value. When
"n" Property Value of
"/oic/con" is modified, it
shall be reflected to "n"
Property Value of
"/oic/d".
Spec Version "icv" Spec version of the core Yes (none) Translator returns its own No
specification to which value.
this Device is
implemented. The
syntax is
"ocf...<
sub-version>” where
,
are the
major, minor and sub-
version numbers of the
specification
respectively. The string
value shall be set to the
version of the Core
Specification on which
the implementation is
built (e.g. "ocf.2.0.6).
Device UUID "di" Unique identifier for Yes (none) As defined in No
Device. This value shall ISO/IEC 30118-2
be the same value (i.e.
mirror) as the
doxm.deviceuuid
Property as defined in
ISO/IEC 30118-2.
Data Model "dmv" Spec version of the Yes "specVersi Data model version of the Yes
Version Resource Specification on" Device
to which this Device
data model is
implemented; if
implemented against a
Vertical specific Device
specification(s), then
the Spec version of the
vertical specification
this Device model is
implemented to.
Permanent "piid" A unique and immutable Yes (none) Translator returns its own No
Immutable ID Device identifier. A value.
Client can detect that a
single Device supports
multiple communication
protocols if it discovers
that the Device uses a
single Permanent
Immutable ID value for
all the protocols it
supports. Handling
privacy-sensitivity for
the "piid" Property, refer
to ISO/IEC 30118-2
© ISO/IEC 2021 – All rights reserved 7
---------------------- Page: 14 ----------------------
ISO/IEC 30118-16:2021(E)
To OCF OCF OCF Description OCF From U+ U+ Description U+
Property title Property Mand Property Mand
name atory value atory
Localized "Id" Detailed description of No (none) (none) No
Descriptions the 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 description
in the indicated
language.
Software "sv" Version of the Device No "swver" Software version of the Yes
Version software. Device
Manufacturer "dmn" Name of manufacturer No "manufactu The value of property Yes
Name of the Device, in one or rerName" "manufacturerName"
more languages. This indicates the name of
property is an array of manufacturer.
objects where each
object has a "language"
field (containing an
IETF RFC 5646
language tag) and a
"value" field containing
the manufacturer name
in the indicated
language.
Model "dmno" Model number as No "modelNum The value of property Yes
Number designated by ber" "modelNumber" indicates the
manufacturer. model number of the Device.
Table 5 shows the mapping between the properties of "oic.wk.p" Resource Type (see ISO/IEC 30118-1)
and the properties of U+ device.
Table 5 – "oic.wk.p" Resource Type definition
To OCF OCF OCF Description OCF From U+ U+ Description U+
Property title Property Mand Property Mand
name atory value atory
Platform ID "pi" Unique identifier for the Yes (none) Translator generates a UUID No
as "pi" value.
physical platform
(UIUID); this shall be a
UUID in accordance
with
IETF RFC 4122. It is
recommended that the
UUID be created using
the random generation
scheme (version 4
UUID) specific in the
RFC. Handling privacy-
sensitivity for the "pi"
Property, refer to
ISO/IEC 30118-2
Manufacturer "mnmn" Name of manufacturer Yes "manufactu The value of property Yes
Name rerName" "manufact
...
INTERNATIONAL ISO/IEC
STANDARD 30118-16
First edition
Information technology — Open
Connectivity Foundation (OCF) —
Part 16:
OCF resource to UPlus mapping
specification
PROOF/ÉPREUVE
Reference number
ISO/IEC 30118-16:2021(E)
©
ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC 30118-16: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-16:2021(E)
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions symbols and abbreviations . 1
4 Document conventions and organization . 2
4.1 Conventions . 2
4.2 Notation . 2
5 Theory of operation . 3
5.1 Interworking approach . 3
5.2 Mapping syntax . 3
5.2.1 Introduction . 3
5.2.2 General . 3
5.2.3 Value assignment . 3
5.2.4 Property naming . 3
5.2.5 Range . 3
5.2.6 Arrays . 3
5.2.7 Default mapping . 4
5.2.8 Conditional mapping . 4
5.2.9 Method invocation . 4
6 U+ translation . 4
6.1 Operational scenarios . 4
6.1.1 Introduction . 4
6.1.2 Use case for U+ bridging . 5
6.2 Requirements specific to U+ translator . 5
6.2.1 General . 5
6.2.2 Requirements specific to U+ . 5
6.2.3 Exposing U+ servers to OCF clients . 5
7 Device type mapping . 11
7.1 Introduction . 11
7.2 U+ device types to OCF device types . 11
8 Resource to U+ property equivalence . 11
8.1 Introduction . 11
8.2 U+ property to OCF resources . 11
9 Detailed mapping APIs . 12
9.1 Introduction . 12
9.2 Air conditioner mapping . 12
9.2.1 Derived model . 12
9.2.2 Property definition . 12
9.2.3 Derived model definition . 13
9.3 Air purifier mapping . 14
9.3.1 Derived model . 14
9.3.2 Property definition . 14
9.3.3 Derived model definition . 14
9.4 Water heater mapping . 15
© ISO/IEC 2021 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 30118-16:2021(E)
9.4.1 Derived model . 15
9.4.2 Property definition . 15
9.4.3 Derived model definition . 16
iv © ISO/IEC 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 30118-16: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 Resource to UPlus Mapping,
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 v
---------------------- Page: 5 ----------------------
ISO/IEC 30118-16: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
vi © ISO/IEC 2021 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC 30118-16:2021(E)
– 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/IEC 2021 – All rights reserved vii
---------------------- Page: 7 ----------------------
INTERNATIONAL STANDARD ISO/IEC 30118-16:2021(E)
Information technology — Open Connectivity
Foundation (OCF) —
Part 16:
OCF resource to UPlus mapping specification
1 Scope
This document provides detailed mapping information between UPlus (U+) and OCF defined
Resources.
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 30118-1 Information technology – Open Connectivity Foundation (OCF) Specification -- Part 1:
Core specification
https://www.iso.org/standard/53238.html
Latest version available at: https://openconnectivity.org/specs/OCF_Core_Specification.pdf
ISO/IEC 30118-2 Information technology – Open Connectivity Foundation (OCF) Specification – Part 2:
Security specification
https://www.iso.org/standard/74239.html
Latest version available at: https://openconnectivity.org/specs/OCF_Security_Specification.pdf
ISO/IEC 30118-3 Information technology – Open Connectivity Foundation (OCF) Specification – Part 3:
Bridging specification
https://www.iso.org/standard/74240.html
Latest version available at: https://openconnectivity.org/specs/OCF_Bridging_Specification.pdf
Derived Models for Interoperability between IoT Ecosystems, Stevens & Merriam, March 2016
https://www.iab.org/wp-content/IAB-uploads/2016/03/OCF-Derived-Models-for-Interoperability-
Between-IoT-Ecosystems_v2-examples.pdf
3 Terms, definitions symbols and abbreviations
For the purposes of this document, the terms and definitions given in ISO/IEC 30118-1,
ISO/IEC 30118-2, and ISO/IEC 30118-3 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/
© ISO/IEC 2021 – All rights reserved 1
---------------------- Page: 8 ----------------------
ISO/IEC 30118-16:2021(E)
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).
These basic features shall be implemented to comply with the Mapping Specification. The phrases
"shall not", and "PROHIBITED" indicate behavior that is prohibited, i.e. that if performed means the
implementation is not in compliance.
Recommended (or should).
These features add functionality supported by the Mapping Specification and should be
implemented. Recommended features take advantage of the capabilities the Mapping Specification,
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 behavior that is permitted but not recommended.
Allowed (or allowed).
These features are neither required nor recommended by the Mapping Specification, but if the
feature is implemented, it shall meet the specified requirements to be in compliance with these
guidelines.
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.
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 document has 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.
2 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 30118-16:2021(E)
Strings that are to be taken literally are enclosed in "double quotes".
Words that are emphasized are printed in italic.
5 Theory of operation
5.1 Interworking approach
The interworking between UPlus (U+) and OCF defined Resources is modelled using the derived model
syntax described in Derived Models for Interoperability between IoT Ecosystems.
5.2 Mapping syntax
5.2.1 Introduction
Within the defined syntax for derived modelling used by this document there are two blocks that define
the actual Property-Property equivalence or mapping. These blocks are identified by the keywords "x-
to-ocf" and "x-from-ocf". Derived Models for Interoperability between IoT Ecosystems does not define
a rigid syntax for these blocks; they are free form string arrays that contain pseudo-coded mapping
logic.
Within this document we apply the rules in defined in clause 5.2 to these blocks to ensure consistency
and re-usability and extensibility of the mapping logic that is defined.
5.2.2 General
All statements are terminated with a carriage return.
5.2.3 Value assignment
The equals sign (=) is used to assign one value to another. The assignee is on the left of the operator;
the value being assigned on the right.
5.2.4 Property naming
All Property names are identical to the name used by the original model; for example, from the OCF
Temperature Resource the Property name "temperature" is used whereas when referred to the derived
ecosystem then the semantically equivalent Property name is used.
The name of the OCF defined Property is prepended by the ecosystem designator "ocf" to avoid
ambiguity (e.g. "ocf.step")
5.2.5 Range
The range on the OCF side is fixed.
5.2.6 Arrays
An array element is indicated by the use of square brackets "[]" with the index of the element contained
therein, e.g. range [1]. All arrays start at an index of 0.
© ISO/IEC 2021 – All rights reserved 3
---------------------- Page: 10 ----------------------
Bridging
Function
ISO/IEC 30118-16:2021(E)
5.2.7 Default mapping
There are cases where the specified mapping is not possible as one or more of the Properties being
mapped is optional in the source model. In all such instances a default mapping is provided. (e.g.
"transitiontime = 1").
5.2.8 Conditional mapping
When a mapping is dependent on the meeting of other conditions then the syntax:
If "condition", then "mapping".
is applied.
E.g. if onoff = false, then ocf.value = false
5.2.9 Method invocation
The invocation of a command from the derived ecosystem as part of the mapping from an OCF
Resource is indicated by the use if a double colon "::" delimiter between the applicable resource,
service, interface or other construct identifier and the command name. The command name always
includes trailing parentheses which would include any parameters should they be passed.
6 U+ translation
6.1 Operational scenarios
6.1.1 Introduction
The goal is to make Bridged U+ Servers appear to OCF Clients as if they were native OCF Servers.
"Deep translation" between specific U+ properties and OCF resources is specified in clause 9.
Figure 1 shows an overview of OCF U+ Bridge Platform and its general topology. The U+ Translator
supports asymmetric bridging. It exposes U+ Servers to OCF Clients. Each Bridged U+ Server is
represented as a Virtual OCF Server.
Bridge Platform
UPlus Bridge
Virtual
Virtual
OCF Bridged Bridged
OCF Uplus
OCF
Protocol Protocol
Client UPlus UPlus Server
Server
Client
Figure 1 – OCF U+ Bridge Platform and Components
4 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 30118-16:2021(E)
6.1.2 Use case for U+ bridging
Figure 2 shows a use case for U+ bridging. U+ washer air conditioner is installed in the user’s house.
The user uses OCF Client application on the smartphone to control the washer. OCF U+ Bridge
Platform can reside in different physical platforms, for example, the smartphone, the washer or the
gateway device.
Any connectivity Any connectivity that
that U+ supports OCF supports
OCF U+
U+ Device OCF Device
Bridge
(server) (client)
Platform
Figure 2 – U+ Bridging Use Case
6.2 Requirements specific to U+ translator
6.2.1 General
OCF U+ Bridge Platform shall satisfy the normative requirements from ISO/IEC 30118-3.
6.2.2 Requirements specific to U+
This document refers to version 5.0.0 or higher of U+ SDK.
6.2.3 Exposing U+ servers to OCF clients
6.2.3.1 General
Table 1 shows translation rule between U+ and OCF data model. One U+ Device Type is mapped to
one OCF Device Type or one OCF Composite Device. One or more U+ Properties are mapped to one
OCF Resource Type.
Table 1 – Translation Rule between U+ and OCF Data Model
From U+ mapping count To OCF mapping count
U+ Device Type 1 OCF Device Type 1
OCF Resource 1
U+ Property n
OCF Property n
Table 2 shows an example of the translation rule, which maps U+ air conditioner to OCF air conditioner.
– U+ Property "onOffStatus" is mapped to OCF Resource Property "value" which belongs to OCF
Resource "oic.r.switch.binary".
© ISO/IEC 2021 – All rights reserved 5
---------------------- Page: 12 ----------------------
ISO/IEC 30118-16:2021(E)
– U+ Property "targetTemperature" is mapped to OCF Resource Property "temperature" and "units"
combined which both belong to OCF Resource "oic.r.temperature".
– U+ Property "indoorTemperature", "windDirectionVertical", "windDirectionHorizontal" and
"windSpeed" together are mapped to OCF Resource Property "supportedDirections", "direction",
"speed" and "automode" combined which all belong to OCF Resource "oic.r.airflow".
– U+ Property "operationMode" and "healthMode" together are mapped to OCF Resource Property
"supportedModes" and "modes" combined which both belong to OCF Resource "oic.r.mode".
Table 2 – Example of Translation between U+ and OCF Data Model
From U+ Air Conditioner To OCF Air Conditioner
U+ Property OCF Resource OCF Resource Property
"onOffStatus" "oic.r.switch.binary" "value"
"temperature"
"targetTemperature" "oic.r.temperature"
"units"
"indoorTemperature" "supportedDirections"
"windDirectionVertical" "direction"
"oic.r.airflow"
"windDirectionHorizontal" "speed"
"windSpeed" "automode"
"operationMode" "supportedModes"
"oic.r.mode"
"healthMode" "modes"
6.2.3.2 Deep translation for U+ property
All U+ devices are well defined. Table 3 is the mapping between U+ devices and their properties and
OCF Devices and Resources. Table 3 includes a full list of U+ devices to be mapped to OCF. Table 4,
Table 5, and Table 6 define the mapping between OCF core Resources and U+ properties.
Table 3 – Mapping between U+ device and property and OCF device and resource
U+ Device U+ Property OCF Resource Type OCF Device OCF Device Type ("rt")
Name
Air Conditioner "onOffStatus" "oic.r.switch.binary" Air Conditioner "oic.d.airconditioner"
"targetTemperature" "oic.r.temperature"
"windSpeed" "oic.r.selectablelevels"
"operationMode" "oic.r.mode"
Water Heater "onOffStatus" oic.r.switch.binary Water Heater "oic.d.waterheater"
"oic.r.temperature"
"targetTemperature"
Air Purifier "onOffStatus" "oic.r.switch.binary" Air Purifier "oic.d.airpurifier"
"mode" "oic.r.operational.state"
"windSpeed" "oic.r.selectablelevels"
Table 4 shows the mapping between the properties of "oic.wk.d" Resource Type (see ISO/IEC 30118-1)
and the properties of U+ device.
6 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 30118-16:2021(E)
Table 4 – "oic.wk.d" Resource Type definition
To OCF OCF OCF Description OCF From U+ U+ Description U+
Property title Property Mand Property Mand
name atory value atory
(Device) "n" Human friendly name Yes "deviceId" An unique ID of the Device Yes
Name defined by the vendor.
In the presence of "n"
Property of "/oic/con",
both have the same
Property Value. When
"n" Property Value of
"/oic/con" is modified, it
shall be reflected to "n"
Property Value of
"/oic/d".
Spec Version "icv" Spec version of the core Yes (none) Translator returns its own No
specification to which value.
this Device is
implemented. The
syntax is
"ocf...<
sub-version>” where
,
are the
major, minor and sub-
version numbers of the
specification
respectively. The string
value shall be set to the
version of the Core
Specification on which
the implementation is
built (e.g. "ocf.2.0.6).
Device UUID "di" Unique identifier for Yes (none) As defined in No
Device. This value shall ISO/IEC 30118-2
be the same value (i.e.
mirror) as the
doxm.deviceuuid
Property as defined in
ISO/IEC 30118-2.
Data Model "dmv" Spec version of the Yes "specVersi Data model version of the Yes
Version Resource Specification on" Device
to which this Device
data model is
implemented; if
implemented against a
Vertical specific Device
specification(s), then
the Spec version of the
vertical specification
this Device model is
implemented to.
Permanent "piid" A unique and immutable Yes (none) Translator returns its own No
Immutable ID Device identifier. A value.
Client can detect that a
single Device supports
multiple communication
protocols if it discovers
that the Device uses a
single Permanent
Immutable ID value for
all the protocols it
supports. Handling
privacy-sensitivity for
the "piid" Property, refer
to ISO/IEC 30118-2
© ISO/IEC 2021 – All rights reserved 7
---------------------- Page: 14 ----------------------
ISO/IEC 30118-16:2021(E)
To OCF OCF OCF Description OCF From U+ U+ Description U+
Property title Property Mand Property Mand
name atory value atory
Localized "Id" Detailed description of No (none) (none) No
Descriptions the 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 description
in the indicated
language.
Software "sv" Version of the Device No "swver" Software version of the Yes
Version software. Device
Manufacturer "dmn" Name of manufacturer No "manufactu The value of property Yes
Name of the Device, in one or rerName" "manufacturerName"
more languages. This indicates the name of
property is an array of manufacturer.
objects where each
object has a "language"
field (containing an
IETF RFC 5646
language tag) and a
"value" field containing
the manufacturer name
in the indicated
language.
Model "dmno" Model number as No "modelNum The value of property Yes
Number designated by ber" "modelNumber" indicates the
manufacturer. model number of the Device.
Table 5 shows the mapping between the properties of "oic.wk.p" Resource Type (see ISO/IEC 30118-1)
and the properties of U+ device.
Table 5 – "oic.wk.p" Resource Type definition
To OCF OCF OCF Description OCF From U+ U+ Description U+
Property title Property Mand Property Mand
name atory value atory
Platform ID "pi" Unique identifier for the Yes (none) Translator generates a UUID No
as "pi" value.
physical platform
(UIUID); this shall be a
UUID in accordance
with
IETF RFC 4122. It is
recommended that the
UUID be created using
the random generation
scheme (version 4
UUID) specific in the
RFC. Handling privacy-
sensitivity for the "pi"
Property, refer to
ISO/IEC 30118-2
Manufacturer "mnmn" Name of manufacturer Yes "manufactu The value of property Yes
Name rerName" "manufacturerName"
indicates the name of
manufacturer.
Model "mnmo" Model number as No "modelNum The value of property Yes
Number designated by ber" "modelNumber" indicates the
manufacturer model nu
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.