ISO/IEC 18012-4:2025

ISO/IEC 18012-4
Edition 1.0 2025-07
INTERNATIONAL
STANDARD
Information technology - Home electronic system (HES) - Guidelines for product
interoperability -
Part 4: Event encoding
ICS 35.200  ISBN 978-2-8327-0551-3

ISO/IEC 18012-4: 2025-07(en)
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
publications previews, graphical symbols and the glossary. With
The advanced search enables to find IEC publications by a
variety of criteria (reference number, text, technical a subscription you will always have access to up to date content
committee, …). It also gives information on projects, replaced tailored to your needs.
and withdrawn publications.
Electropedia - www.electropedia.org
The world's leading online dictionary on electrotechnology,
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or need
further assistance, please contact the Customer Service
Centre: sales@iec.ch.
CONTENTS
FOREWORD. 3
INTRODUCTION . 5
0.1 Overview . 5
0.2 Relation to existing work . 5
0.3 Lexicon and event encoding . 6
1 Scope . 8
2 Normative references . 8
3 Terms, definitions and abbreviated terms . 8
3.1 Terms and definitions . 8
3.2 Abbreviated terms . 10
4 Conformance requirements . 10
5 HES common language message exchange (HES-CLME) . 11
5.1 HES gateway system . 11
5.2 HES – common language internal protocol (HES-CLIP) . 12
5.2.1 HES-CLIP summary . 12
5.2.2 Requirements for the IP network . 13
5.2.3 Discovery requirements for all devices . 14
5.2.4 Requirements for lower layer communications for all devices . 14
5.2.5 Packet structure . 15
5.2.6 Operations and communication methods . 17
5.2.7 Overall CoAP model . 17
5.2.8 Client requirements . 19
5.2.9 Server requirements . 23
5.3 HES – common language direct PDU exchange (HES-CLDPE) . 28
5.3.1 Overview . 28
5.3.2 HES – common language direct PDU exchange (HES-CLDPE/G) . 28
Annex A (normative) Packet construction . 31
A.1 Packet construction overview . 31
A.2 Packet type: Lexicon representation (‘lx’) . 32
A.2.1 General . 32
A.2.2 Lexicon type: Lexicon representation (‘ob’) . 33
A.2.3 Lexicon type: Actions (‘ac’) . 34
A.3 Packet type: Other types of packet . 34
Annex B (informative) Example of packet exchange . 35
B.1 Example setup . 35
B.2 Example operation . 36
B.3 Time flow diagram and PDU construction for example . 37
Bibliography . 39

Figure 1 – ISO/IEC 18012-4 within the core interoperability and HES gateway
standards . 7
Figure 2 – Communications for the HES gateway system . 12
Figure 3 – Communications paths for HES-CLIP . 13
Figure 4 – Request and response model for HES-CLIP . 18
Figure 5 – Publish and subscribe process for HES-CLIP . 19
Figure 6 – Update interactiveData (incoming) . 26
Figure A.1 – Diagram of optional blocks within packet . 31
Figure A.2 – Addressing lists . 32
Figure A.3 – User object packet . 33
Figure B.1 – Switch and light example . 35
Figure B.2 – Binding map storage . 36

Information technology – Home electronic system (HES) –
Guidelines for product interoperability –
Part 4: Event encoding
FOREWORD
1) 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.
2) The formal decisions or agreements of IEC and ISO on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested IEC and ISO National bodies.
3) IEC and ISO documents have the form of recommendations for international use and are accepted by IEC and
ISO National bodies in that sense. While all reasonable efforts are made to ensure that the technical content of
IEC and ISO documents is accurate, IEC and ISO cannot be held responsible for the way in which they are used
or for any misinterpretation by any end user.
4) In order to promote international uniformity, IEC and ISO National bodies undertake to apply IEC and ISO
documents transparently to the maximum extent possible in their national and regional publications. Any
divergence between any IEC and ISO document and the corresponding national or regional publication shall be
clearly indicated in the latter.
5) IEC and ISO do not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC and ISO marks of conformity. IEC and ISO are not
responsible for any services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this document.
7) No liability shall attach to IEC and ISO or their directors, employees, servants or agents including individual
experts and members of its technical committees and IEC and ISO National bodies for any personal injury,
property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including
legal fees) and expenses arising out of the publication, use of, or reliance upon, this ISO/IEC document or any
other IEC and ISO documents.
8) Attention is drawn to the Normative references cited in this document. Use of the referenced publications is
indispensable for the correct application of this document.
9) IEC and ISO draw attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC and ISO take no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, IEC and ISO had not received notice of
(a) patent(s), which may be required to implement this document. However, implementers are cautioned that this
may not represent the latest information, which may be obtained from the patent database available at
https://patents.iec.ch and www.iso.org/patents. IEC and ISO shall not be held responsible for identifying any or
all such patent rights.
ISO/IEC 18012-4 has been prepared by subcommittee 25: Interconnection of information
technology equipment, of ISO/IEC joint technical committee 1: Information technology. It is an
International Standard.
The text of this International Standard is based on the following documents:
Draft Report on voting
JTC1-SC25/3270/CDV JTC1-SC25/3312/RVC

Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1, and the ISO/IEC Directives, JTC 1 Supplement
available at www.iec.ch/members_experts/refdocs and www.iso.org/directives.
A list of all parts in the ISO/IEC 18012 series, published under the general title Information
technology – Home Electronic System (HES) – Guidelines for product interoperability, can be
found on the IEC and ISO websites.
The use of formatting with bold italics is used throughout this document for data formats as
specified in ISO/IEC 18012-3.
INTRODUCTION
0.1 Overview
The Home Electronic System (HES) is a set of standards that supports communication, control,
and monitoring applications for homes and buildings. However, homes and buildings present a
heterogeneous and evolving networked environment, where many of these networks and
applications (including some that are based on HES standards) are not directly interoperable
with each other. HES standards achieve interoperability through the ISO/IEC 15045 series to
support functional interworking among the dissimilar home devices, applications, protocols, and
networks found in this environment. The ISO/IEC 15045 series and ISO/IEC 18012 series were
created to render all HES protocols interoperable.
The HES gateway enables an open and adaptable market for incompatible products by
specifying a standardized modular system intended to provide interoperability among the
diversity of networks found in homes and buildings built by a variety of manufacturers. The HES
interoperability process does not require modification of the various networks, applications, or
protocols that use it. Appropriate interworking functions translate network messages through
interface modules to a common lexicon expression that is then exchanged using a private
internal network bus protocol using modules that can be built by a variety of manufacturers. A
protected application platform using a bus protocol supports an expanding array of services for
both the applications and the network.
In summary, the ISO/IEC 15045 series specifies a standardized, modular, dedicated, private,
internal network system that includes:
• interfaces (i.e. interface modules) for communications and semantic translation among
dissimilar home area networks (HANs), and between a HAN and external wide area
networks (WANs),
• a platform for supporting a variety of application services (i.e. service modules), and
• a secure communication path among these modular elements with access restricted to the
appropriate elements in order to protect data, safety and privacy.
Interworking is achieved with a translation process by which a message between devices on
two networks that use different protocols (including different application languages) is first
converted into a common HES (internal) linguistic expression and then back into an equivalent
message for the other network. This conversion is accomplished by an interworking function
(IWF) residing in interface modules for each network. These messages are initiated by changes-
of-state relating to objects associated with devices connected to networks, and are known as
events. The HES common language message exchange (HES-CLME) event messages employ
a standardized syntax and semantic expressions defined by the HES lexicon specified in
ISO/IEC 18012-3. The format of the messages (i.e. the message protocol data unit – PDU) is
defined in this document).
0.2 Relation to existing work
The HES gateway system is specified in ISO/IEC 15045-1. Several structural configurations of
the HES gateway system are specified in ISO/IEC 15045-4-1. All classes use the HES
interoperability system specified above. However, in some that use physically separated HES
gateway modules, communication among modular elements is provided by a dedicated private
internet serial bus (based on Ethernet, see RFC 1918) that utilizes a set of protocols specified
in ISO/IEC 15045-2, which is now known as common language message exchange (HES-
CLME).
ISO/IEC 18012-1 introduces the necessity for an interoperability standard among home system
applications to ensure that applications interoperate in a safe, reliable, predictable and
consistent manner. The interworking function (IWF) is specified in ISO/IEC 18012-2.
The message content (protocol data unit or PDU) is defined in ISO/IEC 18012-3 and in this
document. All HES gateway structural class configurations use the same interworking functions,
including lexicon, and event encoding.
0.3 Lexicon and event encoding
ISO/IEC 18012-3 specifies the standardized HES application objects, functions (actions), and
variables, as well as their expression (symbolic encoding) and their semantic meaning and their
syntactic usage. These are the elements to construct IWFs for each specific network. Because
of the dynamic heterogeneous nature of the home and building networking environment, it is
intended that these elements, including the IWFs for each network, be maintained in a
standardized online metadata registry to allow for future expansion while maintaining semantic
interoperability. As the HES lexicon is expanded, there will be coordination with the appropriate
trade or standards organizations to ensure the semantic meanings cover the range of
applications and systems of those industries.
In addition, standardized test procedures, plugfests, and technical guidance reports are
anticipated in the future to prove completeness and ensure interoperability among the range of
applications and systems.
This document specifies the specific format of the PDUs for various events to be utilized in
serial bus data packet exchange (e.g. HES-CLIP) or direct API exchanges (e.g. HES-CLDPE)
within a gateway. The format provides fast reliable message exchanges with low complexity
requirements.
Figure 1 shows the core interoperability and ISO/IEC 15045 series of standards and where this
document fits into the series.
Figure 1 – ISO/IEC 18012-4 within the core interoperability
and HES gateway standards
1 Scope
This document specifies an event exchange format that defines the encoding of individual
events in the interoperability domain. This event format is used to encode events for exchange
across the “event bus” within the interoperability domain.
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 18012-3, Information technology - Home Electronic System (HES) - Guidelines for
product interoperability - Part 3: Lexicon
IETF RFC 0768, User Datagram Protocol
IETF RFC 1918, Address Allocation for Private Internets
IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax
IETF RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files
IETF RFC 6762, Multicast DNS
IETF RFC 6763, DNS-Based Service Discovery
IETF RFC 7252, The Constrained Application Protocol (CoAP)
IETF RFC 8085, UDP Usage Guidelines
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1.1
comma-separated values
CSV
sequence of values that are separated by commas and records that are separated by carriage
returns or line feeds or both as specified in RFC 4180
3.1.2
constrained application protocol
CoAP
transfer protocol for use with nodes with limited capability and on networks with limited capacity
or that would limit impact on the networks used as specified in RFC 7252
3.1.3
data reference address
complete address of an object including the hierarchical address that references data which the
object contains (instead of the name)
3.1.4
DNS-based service discovery
DNS-SD
discovery of services through the domain name system as specified in RFC 6763
3.1.5
DNS-SD TXT records
format of records using the domain name system service discovery that enables additional data
to be discovered
3.1.6
event
change of state relating to an object
Note 1 to entry: Objects include user, remote, binding map, interface, and service objects.
[SOURCE: ISO/IEC 18012-3:2025, 3.1.7]
3.1.7
hierarchical address
address of an object represented as a subordinate to other objects
3.1.8
home electronic system
HES
control and sensing system for homes and buildings based on home electronic system (HES)
ISO/IEC standards
Note 1 to entry: The referenced ISO/IEC standards normally include HES in the title of each standard.
[SOURCE: ISO/IEC 15045-3-1:2024, 3.1.2]
3.1.9
home electronic system common language internal protocol
HES-CLIP
protocol for messaging among physical HES gateway modules
Note 1 to entry: This protocol is based on Ethernet lower Open Systems Interconnection layers and Internet Protocol
on the middle layers.
3.1.10
idempotent
operation that can be invoked multiple times with the same effect as when invoked once
3.1.11
multicast DNS
mDNS
domain name system look ups without server as specified in RFC 6762
3.1.12
object reference code
code that references the specific name within an object
[SOURCE: ISO/IEC 18012-3:2025, 3.1.16]
3.1.13
private internet
network using Internet Protocol addressing within a premises as specified in RFC 1918
3.1.14
protocol data unit
PDU
unit of data exchanged between peer entities
3.1.15
safe
not having any side-effects such as changing data contents
3.1.16
universal asynchronous receiver-transmitter
UART
hardware that is used for serial communication
3.1.17
uniform resource identifier
URI
compact sequence of characters to identify objects as specified in RFC 3986
3.1.18
user datagram protocol
UDP
unacknowledged datagram as specified in RFC 0768 and RFC 8085
Note 1 to entry: UDP is intended for packet transfers with a minimum of overhead, especially for real-time streaming
services.
3.2 Abbreviated terms
CoAP constrained application protocol
CSV comma-separated values
DNS domain name system
DNS-SD DNS-based service discovery
mDNS multicast DNS
UART universal asynchronous receiver-transmitter
UDP user datagram protocol
URI uniform resource identifier
4 Conformance requirements
An HES gateway module conforming to this document shall implement either 5.2 (HES-CLIP)
or 5.3 (HES-CLDPE) that aligns with the HES-CLME method used.
5 HES common language message exchange (HES-CLME)
5.1 HES gateway system
The HES gateway system is comprised of a set of communicating computing elements, known
as HES gateway modules, that exchange short messages for interconnection, coordination, and
control of devices connected to home and building networks. When this exchange mechanism
is handled internally in the gateway, this exchange is generally denoted as common language
message exchange (HES-CLME). This modular structure is defined in ISO/IEC 15045-2. These
HES gateway modules operate by the exchange of short messages primarily comprised of a
protocol data unit (PDU). This document specifies these PDUs, first in the context of the general
case where the HES gateway modules are exchanging messages using Ethernet and a protocol
known as the home electronic system common language internal protocol (HES-CLIP).
Secondly, this document specifies the same PDUs in the context of an abbreviated case known
as common language direct PDU exchange (HES-CLDPE) by direct shared memory access or
other methods appropriate to efficient integrated circuit design.
The HES gateway system is an event-driven system, whereby actions are typically initiated by
events internal or external to the gateway, communicated over the HES-CLIP or other form of
internal “event bus”, and then forwarded to designated external devices. The top level protocol
employed by this HES-CLME includes a publish and subscribe-based exchange or transfer
whereby typically external devices (e.g. sensors) and their associated interface modules send
event notifications to subscribing internal service modules. The routing of messages is under
the control of a “binding map” associated with particular services resident within the gateway
platform. The primary purpose of this document is to define how these events are encoded in
the PDU.
As specified in ISO/IEC 15045-4-1, the HES gateway system allows home area networks
(HANs) supporting local users, devices and services, and external wide area networks (WANs)
supporting remote users, devices and services to communicate and translate between each
other, while providing privacy, security and safety, and supporting a platform for application
services.
As specified in ISO/IEC 18012-3 and in ISO/IEC 15045-3-1, the binding map service is the
core of every HES gateway. It directs the messages, including packets as defined in Annex A,
from one module (HAN interface module, WAN interface module, service module) to another
module using the HES common language message exchange (HES-CLME). An important
element for privacy, security and safety is that HAN interface modules and WAN interface
modules do not communicate directly to each other, but instead each communicates to the
binding map service.
The diagram in Figure 2 shows the HES gateway system from a communications point of view.
___________
1 There can be multiple binding map services in one HES gateway system. The specifications for dealing with
multiple binding map service will be developed in the future.
Figure 2 – Communications for the HES gateway system
Within the HES-CLME family of protocols, there are two main techniques that are specified for
different types of implementation, but result in the same overall operation. The first technique,
HES-CLIP (common language internal protocol), uses the widely adopted Ethernet protocol
(ISO/IEC/IEEE 8802-3 series) as a private internet, which allows communications among
independent modular gateway products. The second technique, HES-CLDPE (common
language direct PDU exchange) provides a family of protocols and signalling that support
operation between modular logical elements within a single gateway product.
5.2 HES – common language internal protocol (HES-CLIP)
5.2.1 HES-CLIP summary
HES-CLIP (common language internal protocol) is the underlying communications protocol for
the complex modular gateway system (see ISO/IEC 15045-4-1). It uses a strictly defined serial
Internet Protocol (IP) based on Ethernet as a private internet (see RFC 1918) to support
interoperable operation between independent modular products from different manufacturers.
The diagram in Figure 3 shows the communication paths that use HES-CLIP.
Figure 3 – Communications paths for HES-CLIP
5.2.2 Requirements for the IP network
HES-CLIP operates on the foundation of an underlying private IP network supporting
communications between the HES gateway modules. Such HES-CLIP IP network shall fulfil the
following requirements.
– All communications of the IP network shall only use IPV4.
– The IP network shall be a standalone network or shall be built into one of the HES gateway
products.
– The entire IP network for HES gateway module communications shall use only a wired
medium (e.g. twisted-pair wires, fibre optics, backplane conductors) and shall remain within
the constraints of the premises – maximizing the privacy and security of the
communications.
– Wireless connections or outside network connections, e.g. Internet (IEV 732-07-01), that
are present on any attached device on the IP network shall not be used.
– IP addressing allocation (usually performed in a router) shall ensure that unique IP
addresses are provided for each attached HES gateway module, either through automatic
IP allocation methods (such as DHCP) or manual, and shall follow IANA reservation rules
for private internets as outlined in RFC 1918.
– All HES gateway modular products shall use internationally standardized and commonly
used connectors such as RJ45.
– The HES-CLIP IP network shall enable communications using IEEE 802.3i (supplement to
ISO/IEC/IEEE 8802-3) and later additions to the ISO/IEC/IEEE 8802-3 series, and meet the
requirements of IEC 61588.
5.2.3 Discovery requirements for all devices
A discovery process that allows for HES gateway modules to discover each other and to
discover resources within the modules is required for each device.
The Multicast DNS (mDNS) protocol of RFC 6762 shall be used to allow for rapid discovery of
the IP addressing of HES gateway modules connected to the IP network without a conventional
. The “Continuous Multicast DNS Querying” (see Section 5.2 in RFC 6762) shall
DNS server
be used to allow for multiple results to be processed. “One-Shot Multicast DNS Queries” (see
Section 5.1 in RFC 6762) is not sufficient.
To exchange key discover-type information during the HES gateway module discovery process,
the DNS-Based Service Discovery (DNS-SD) protocol as specified in RFC 6763, and in
particular the DNS-SD TXT records (see Section 6 in RFC 6763), shall be also used for every
device.
The service name of “_hes-clip._udp” shall be used.
The information to exchange shall be from the tables for “Pre-Market Discovery Configuration
Data” for HAN interface modules, WAN interface modules and service modules in
ISO/IEC 18012-3. The key and value pairs are made up of the transmitted code as the key
(“Trans Code" – object address not used) and values from the table.
For example, the key and value pair for HAN interface modules is ‘mt=hi’; ‘mt’ to represent
moduleType and ‘hi’ for the HAN interface.
Type of module (‘mt’) Trans Descriptive name
code
HAN interface module ‘hi’ hanInterfaceModule
WAN interface module ‘wi’ wanInterfaceModule
Service modules ‘sm’ serviceModule
Internal process ‘it’ internalProcess

For service modules, an additional key and value pair of the serviceModuleType is sent.
For example, the additional key and value pair for the identification service module is ‘st=id’;
‘st’ to represent the serviceModuleType and ‘id’ for the identification service module (values
listed in the service domain table in ISO/IEC 18012-3).
The devices shall place the results of their discoveries to fill the complete “Post-Market
discovery configurationData” table as shown in ISO/IEC 18012-3 for the discovery object for
the type of HES gateway module.
5.2.4 Requirements for lower layer communications for all devices
The following are requirements for all devices connecting to the HES-CLIP network.
No device shall interrupt or prevent the intended HES-CLIP communications from occurring,
nor shall it modify packets.
___________
RFC 6762; Multicast DNS
RFC 6763, 7, Service Names
Packets for HES gateway purposes between devices shall be exchanged using the User
Datagram Protocol (UDP) as specified in RFC 0768 and RFC 8085, and shall follow the
Constrained Application Protocol (CoAP) specified in RFC 7252. Other packet exchanges than
CoAP are allowed over the HES-CLIP network as long as they do not interfere with or introduce
risk in the HES gateway communications. These protocols provide fast performance with
flexibility while reducing overhead and complexity for devices.
The IP address mechanism is designed to direct a message to a specific device so multiple
devices with unique port numbers share one public IP address. This is done by the network
address translation (NAT) function in a router. The router is assigned one public IP address and
routes packets to local IP addresses based on a port ID accompanying the public ID using the
network address and port translation (NAPT) function.
Similarly, port number assignments on the local network are used for specific network
applications. Normally, the CoAP specification uses UDP port 5683 as default. The HES
gateway (ISO/IEC 15045 series and ISO/IEC 18012 series), shall use port 8807 (hes-clip)
instead for outgoing and incoming traffic, which has been assigned by IANA for HES gateway
internal communications. There shall be no outgoing traffic on port 8807 except as specified in
HES-CLIP. All incoming traffic on port 8807 not adhering to HES-CLIP shall be disregarded.
These measures enhance the reliability of the communications from interference of unwanted
messages.
, and therefore the CoAP block-wise transfer
All messages are designed to fit into one packet
functionality is not required. To ensure interoperability among transmitters and receivers, and
to reduce complexity for implementations while allowing for a wide range of applications to be
supported, all CoAP messages are limited to 1 024 bytes (see Figure 7 of RFC 7252). To clarify,
transmitters shall not send more than 1 024 bytes per CoAP message, and receivers shall be
able to handle up to and including 1 024 bytes per CoAP message .
For ensuring reliable exchanges, tokens and only confirmable messages will be used.
The specific operations and parameters of CoAP, as specified within 5.2.4 have been optimized
for use in the HES gateway resulting in a simplified and streamlined implementation of CoAP.
This means the software and hardware complexity for specific implementations designed for
the HES gateway are reduced. Standard CoAP implementations will work as well.
5.2.5 Packet structure
5.2.5.1 Uniform Resource Identifier
As specified in the CoAP specification, the packet structure used for communications between
HES gateway modules shall follow the Uniform Resource Identifier (URI) specifications
(RFC 3986).
There are four main components (see Section 3 of RFC 3986):
– scheme
– authority
– path
– query
___________
4 Ethernet packets have a typical limit of approximately 1 500 bytes.
5 RFC 7959, Block-Wise Transfers in the Constrained Application Protocol (CoAP).
6 RFC 7252, Section 4.6 mentions size of 1 024 bytes.
5.2.5.2 Scheme
The scheme shall use the word ‘coap’.
5.2.5.3 Authority
The authority shall use IP address of the destination HES gateway module and port; for
example: ‘192.168.1.12:8807’.
5.2.5.4 Path
The path contains the representation of the object, as specified in Annex A.
The separator as discussed in Annex A and documented throughout this document and
ISO/IEC 18012-3 shall be a ‘/’ which maps into path for the CoAP protocol. The path is
.
transported in CoAP using the “Uri-Path” option 11
5.2.5.5 Query
The use of query, as specified within the text of this document, is the process that allows extra
information to be sent along with the packets, either relating to the metaData of the objects (as
contained in ISO/IEC 18012-3) or relating to the attached network communications link. Query
is transported in CoAP using the “Uri-Query” option 15 .
The following list includes the possible types of query relating to ISO/IEC 18012-3 that shall be
used.
'ap': addrPoint; specifies whether noted addresses point to addressing information or point
to data as shown in address and data types in ISO/IEC 18012-3.
'cc': cursorCoordinateInfo; cursor coordinates (column, row) corresponding to the position
of the referenced values as shown in currentValue metaData in ISO/IEC 18012-3.
‘ci’: credInfo; credential information (certifications, keys, passwords, tokens) which
accompanies messages as shown in authorization and authentication service,
credentials, in ISO/IEC 18012-3.
‘da’: multiple data points; either metaData or interactiveData as shown in ISO/IEC 18012-3.
‘di’: deviceIndex; index reference to destination device as shown in deviceList of “outputs”
table in the binding map service in ISO/IEC 18012-3.
‘ei’: encryptIndex; index to encryption algorithm (payload is encrypted) which accompanies
messages as shown in cryptographic ciphers, in ISO/IEC 18012-3.
‘mi’: moduleRefIndex; index reference to module as shown in the binding map service in
ISO/IEC 18012-3.
‘mt’: moduleType; type of module as shown in the binding map service in ISO/IEC 18012-3.
‘ni’: netRefIndexes; index for Indexed list of arrays as shown in the binding map service in
ISO/IEC 18012-3.
‘un’: userName; string corresponding to the user name as shown in the binding map service
in ISO/IEC 18012-3.
___________
RFC 7252, Section 5.10 and 5.10.1
RFC 7252, Section 5.10 and 5.10.1
The following list includes the possible types of query relating to the attached communications
link.
‘ch’: channel used in the attached network communications link.
‘rs’: radio signal strength indicator (RSSI) of the attached network communications link.
‘sn’: signal-to-noise ratio (SNR) of the attached network communications link.
5.2.6 Operations and communication methods
There are four basic operations that are commonly used with data systems, often called CRUD.
– Create: create new information.
– Read: read information (in HES-CLIP, “retrieve” is more relevant, so that term will be used
instead of “read”).
– Update: update existing information.
– Delete: delete information.
There is not always a direct mapping of communication systems to these operations. The
standard communications methods of CoAP roughly translate to CRUD as follows:
• post
• get
• put
• delete
5.2.7 Overall CoAP model
CoAP uses a request and response model . To read and retrieve information or to update
information, a client sends a request message to a server, which responds with the information
or status or both.
For the HES gateway, the binding map service operates as the client, while the other modules
(HAN interface module, WAN interface module, or service modules) operate as servers. For
example, a binding map (client) inquires the HAN interface module (server) about the present
status of a light from the attached HAN using the request and response model.
Similarly, the binding map (still acting as a client) uses the same model to update an interface
module to turn on a light, for example, by sending a request for the update to occur. The server
responds with the success (or not) of performing the update. The diagram in Figure 4 shows
the request and response model for the HES-CLIP.
___________
RFC 7252, Section 2.2
Figure 4 – Request and response model for HES-CLIP
In Figure 4, the binding map service (client) sends a CoAP Request message to the interface
module or service module (server). The server responds with the requested information with a
Response message with the requested information or status.
In some situations, there can be extraneous packets because of constant polling, as the binding
map service tries to track the status of changing conditions in an interface module.
A solution to this issue is solved through the “observe” option , where a resource in a server
is monitored and only state changes are sent back to the client (operating as a publish and
subscribe service). The diagram in Figure 5 shows the observe process for the HES-CLIP.
___________
RFC 7641, Observing Resources in the Constrained Application Protocol (CoAP).
Figure 5 – Publish and subscribe process for HES-CLIP
In Figure 5, the binding map service (client) sends a CoAP Observe message (CoAP request
with the “observe” option) to the interface module or service module (server). This results in the
server replying with the current state of the resource. The server monitors for changes in the
resource (button push, temperature change, etc.), and when a change occurs the server sends
a response with the new changed state to the client.
A diagram of an example for the time flow and for PDU construction is shown in Annex B.
At this time, the triggers or thresholds for a changed state are determined by the server.
In certain circumstances (which have yet to be defined), service modules also act as clients.
5.2.8 Client requirements
5.2.8.1 CRUD client data system operations
Subclause 5.2.8 specifies the requirements for clients to handle the basic CRUD data system
operations. These include the binding map service and other service modules that include client
capability.
5.2.8.2 Retrieve
5.2.8.2.1 Retrieve – general; client requirements
A client that retrieves information from a server shall meet the following general requirements.
In response to an event, the client shall send a message with the request and response model
specified in 5.2.7 using the following CoAP aspects to retrieve information from another device:
– “get” method (see Section 5.8.1 of RFC 7252),
– confirmable message request (CON) (see Section 2.2 of RFC 7252),
– a token of four to eight bytes (see Section 5.3.1 of RFC 7252), and
– the default values as listed for transmission parameters (see Table 2, Section 4.8 of
RFC 7252).
The client should consider this operation as executed by the server to be safe (3.1.15) and
idempotent (3.1.10).
The client shall be able to handle the reception of the following response codes sent back from
:
the server
– valid update: “2.05 Content”;
– user not authenticated: “4.01 Unauthorized”;
– data or lexicon does not exist: “4.04 Not Found”;
– method not allowed on data: “4.05 Method Not Allowed”.
5.2.8.2.2 Retrieve data within object; client requirements
A client that retrieves data of an HES lexicon object (addrPoint of ‘pd’ as specified in
ISO/IEC 18012-3), for example checking whether a light is on or off, shall meet the general
retrieve requirements as specified in 5.2.8.2.1.
In addition, the address corresponding to the data or table for the object shall be placed in the
CoAP “Uri-Path” option (see Section 5.10 of RFC 7252) in accordance with Annex A, and there
shall be no CoAP payload. For example, to retrieve the current value of light (lighting domain)
the “Uri-Path” would be: ‘/lx/ob/uo/li/ll/da/
...