ISO/IEC 15067-3-31:2024

Information technology - Home Electronic System (HES) application model - Part 3-31: Protocol of energy management agents for demand-response energy management and interactions among these agents

This document specifies a protocol for energy management agents (EMAs) to facilitate communications among these agents for demand response (DR) energy management applications. The EMA protocol (EMAP) provides a logical connection among EMAs in community housing such as an apartment building or a campus of houses or apartment buildings. This document also specifies interaction procedures and message formats for DR energy management as introduced in ISO/IEC 15067-3-3. The EMAP supports interactions among EMAs at OSI (Open System Interconnection) layer 7 with a message transfer protocol. An EMA can be embedded in devices such as a thermostat, a smart appliance, or other consumer products. The choice of interconnection depends on the system and the network topology, which can be arranged in a mesh or hierarchical tree structure. An intermediate EMA may relay messages sent between EMAs.

Titre manque — Partie 3-31: Titre manque

General Information

• Status: Published
• Publication Date: 21-Mar-2024
• ICS: 35.200 - Interface and interconnection equipment
• Technical Committee: ISO/IEC JTC 1/SC 25 - Interconnection of information technology equipment
• Drafting Committee: ISO/IEC JTC 1/SC 25 - Interconnection of information technology equipment
• Current Stage: 6060 - International Standard published
• Start Date: 22-Mar-2024
• Due Date: 19-Sep-2025
• Completion Date: 22-Mar-2024

Overview

ISO/IEC 15067-3-31:2024 defines the Energy Management Agent Protocol (EMAP) for Home Electronic System (HES) application models. The standard specifies interaction procedures and message formats that enable energy management agents (EMAs) to communicate for demand-response (DR) energy management in residential communities (e.g., apartment buildings, campus housing). EMAP operates at OSI layer 7 using a message transfer protocol and supports mesh, hierarchical tree, point-to-point, or hybrid topologies. EMAs can be embedded in devices such as smart thermostats, smart appliances, or other consumer products; intermediaries may relay messages between EMAs.

Key topics and technical requirements

• Protocol scope and architecture
  • Logical connections among EMAs for community-level DR and local coordination.
  • Support for mesh and hierarchical topologies; intermediate EMA relaying.
• Service procedures and message formats
  • Core service families: RegisterParty, Event (push/pull), Report (register/request/send/cancel), Opt (create/cancel), and Poll.
  • Two-step service procedures and defined interaction diagrams for consistent implementation.
• Transport and data encoding
  • Guidance on using CoAP (Constrained Application Protocol) as a transport layer and specification of service endpoint URIs, methods and response codes.
  • JSON schemas and message payload formats are provided (see Annex B) to ensure interoperable data exchange.
• Operational modes
  • Support for opt-change mechanisms and queue-based polling to manage asynchronous interactions.
• Security
  • A dedicated section describes security considerations for message exchange and agent authentication (implementation-focused, not prescriptive cryptographic algorithms).

Applications and practical value

• Enables interoperable demand-response orchestration across devices in residential communities for:
  • Peak load reduction, coordinated load shedding and energy flexibility.
  • Community-level scheduling and appliance-level responses to DR signals.
  • Integration of distributed energy resources and smart building controls.
• Practical use cases:
  • Building automation vendors implementing EMA firmware.
  • Utilities and DR service providers coordinating aggregated residential loads.
  • System integrators and platform developers building HES solutions for multi-unit dwellings or campus deployments.

Who should use this standard

• Device manufacturers (thermostats, smart appliances)
• Firmware and embedded systems engineers
• Utility/DR program architects and aggregators
• Home automation platform developers and integrators
• Standards and interoperability test labs

Related standards

• ISO/IEC 15067-3-3 (introduces DR energy management concepts referenced by EMAP)
• Other parts of the ISO/IEC 15067 HES application model series

Keywords: ISO/IEC 15067-3-31, EMAP, energy management agents, demand response, HES, CoAP, JSON schema, smart thermostat, residential energy management.

Standards Content (Sample)

ISO/IEC 15067-3-31
Edition 1.0 2024-03
INTERNATIONAL
STANDARD
colour
inside
Information technology – Home Electronic System (HES) application model –
Part 3-31: Protocol of energy management agents for demand-response energy
management and interactions among these agents

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 ISO/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.: [phone]
3, rue de Varembé [e-mail]
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 - webstore.iec.ch/advsearchform IEC Products & Services Portal - products.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews, graphical symbols and the glossary.
committee, …). It also gives information on projects, replaced With a subscription you will always have access to up to date
and withdrawn publications. content tailored to your needs.

IEC Just Published - webstore.iec.ch/justpublished
Electropedia - www.electropedia.org
Stay up to date on all new IEC publications. Just Published
The world's leading online dictionary on electrotechnology,
details all new publications released. Available online and once
containing more than 22 500 terminological entries in English
a month by email.
and French, with equivalent terms in 25 additional languages.

Also known as the International Electrotechnical Vocabulary
IEC Customer Service Centre - webstore.iec.ch/csc
(IEV) online.
If you wish to give us your feedback on this publication or need

further assistance, please contact the Customer Service
Centre: [e-mail].
ISO/IEC 15067-3-31
Edition 1.0 2024-03
INTERNATIONAL
STANDARD
colour
inside
Information technology – Home Electronic System (HES) application model –

Part 3-31: Protocol of energy management agents for demand-response energy

management and interactions among these agents

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 35.200 ISBN 978-2-8322-8357-8

– 2 – ISO/IEC 15067-3-31:2024
© ISO/IEC 2024
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
2 Normative references . 8
3 Terms, definitions and abbreviated terms . 9
3.1 Terms and definitions . 9
3.2 Abbreviated terms . 9
4 Conformance . 10
5 Energy management agent architecture for home or residential community . 10
5.1 Overview. 10
5.2 EMA protocol . 11
6 EMAP service procedure and message format . 13
6.1 Overview. 13
6.2 RegisterParty . 14
6.2.1 Overview . 14
6.2.2 Query registration . 15
6.2.3 Create registration . 15
6.2.4 Cancel registration . 15
6.2.5 Request reregistration . 16
6.2.6 Message formats for RegisterParty . 16
6.3 Event . 20
6.3.1 Overview . 20
6.3.2 Push . 20
6.3.3 Pull . 21
6.3.4 Message formats for event . 21
6.4 Report. 23
6.4.1 Overview . 23
6.4.2 Register report. 23
6.4.3 Request report . 24
6.4.4 Send report . 24
6.4.5 Cancel report . 25
6.4.6 Message formats for report . 25
6.5 Opt . 29
6.5.1 Overview . 29
6.5.2 Create opt . 29
6.5.3 Cancel opt . 29
6.5.4 Message formats for opt . 30
6.6 Poll . 32
7 Transport protocol . 36
7.1 CoAP . 36
7.1.1 General . 36
7.1.2 Push and pull implementation . 36
7.1.3 Service endpoint URIs . 36
7.1.4 CoAP methods. 37
7.1.5 Failure conditions . 37
7.1.6 CoAP response codes . 37

© ISO/IEC 2024
8 Security . 38
Annex A (informative) EMAP opt-change . 39
A.1 Opt-change example message . 39
A.2 Items for opt-change mode . 41
Annex B (informative) JSON schema . 43
B.1 JSON . 43
B.2 JSON schema . 43
Bibliography . 45

Figure 1 – Example of an energy management system in a residential area . 10
Figure 2 – A hierarchical EMAP application model in a residential area . 11
Figure 3 – A point-to-point EMAP application model in a residential area . 12
Figure 4 – A hybrid EMAP application model in a residential area . 12
Figure 5 – Two-step service procedures of EMAP . 14
Figure 6 – Interaction diagram: Query registration . 15
Figure 7 – Interaction diagram: Create registration . 15
Figure 8 – Interaction diagram: Cancel registration . 16
Figure 9 – Interaction diagram: Request reregistration – Push operation . 16
Figure 10 – emapQueryRegistration simplified message format . 16
Figure 11 – emapCreatedPartyRegistration simplified message format . 17
Figure 12 – emapCreatePartyRegistration simplified message format . 18
Figure 13 – emapCancelPartyRegistration simplified message format . 18
Figure 14 – emapCanceledPartyRegistration simplified message format . 18
Figure 15 – emapRequestReregistration simplified message format . 19
Figure 16 – emapResponse message format . 19
Figure 17 – Event interaction diagram – Push operation . 20
Figure 18 – Event interaction diagram – Pull operation . 21
Figure 19 – emapRequestEvent simplified message format. 21
Figure 20 – emapPoll simplified message format . 22
Figure 21 – emapDistributeEvent simplified message format. 22
Figure 22 – emapCreatedEvent simplified message format . 23
Figure 23 – Interaction diagram: Register report – Push operation . 24
Figure 24 – Interaction diagram: Request report – Push operation . 24
Figure 25 – Interaction diagram: Send report – Push operation . 25
Figure 26 – Interaction diagram: Cancel report – Push operation . 25
Figure 27 – emapRegisterReport simplified message format . 26
Figure 28 – emapRegisteredReport simplified message format . 26
Figure 29 – emapCreateReport simplified message format . 27
Figure 30 – emapCreatedReport simplified message format . 27
Figure 31 – emapUpdateReport simplified message format . 27
Figure 32 – emapUpdatedReport simplified message format . 28
Figure 33 – emapCancelReport simplified message format . 28
Figure 34 – emapCanceledReport simplified message format . 29
Figure 35 – Interaction diagram: Create opt . 29

– 4 – ISO/IEC 15067-3-31:2024
© ISO/IEC 2024
Figure 36 – Interaction diagram: Cancel opt . 30
Figure 37 – emapCreateOpt simplified message format . 30
Figure 38 – emapCreatedOpt simplified message format . 31
Figure 39 – emapCancelOpt simplified message format . 31
Figure 40 – emapCanceledOpt simplified message format . 32
Figure 41 – Interaction diagram: Poll (nothing in queue) . 33
Figure 42 – Interaction diagram: Poll (emapCancelPartyRegistration reply) . 33
Figure 43 – Interaction diagram: Poll (emapRequestReregistration reply) . 33
Figure 44 – Interaction diagram: Poll (emapDistributeEvent reply) . 34
Figure 45 – Interaction diagram: Poll (emapRegisterReport reply) . 34
Figure 46 – Interaction diagram: Poll (emapCreateReport reply) . 34
Figure 47 – Interaction diagram: Poll (emapUpdateReport reply) . 35
Figure 48 – Interaction diagram: Poll (emapCancelReport reply) . 35
Figure A.1 – Example of opt-change in CreatePartyRegistration message . 39
Figure A.2 – Example of opt-change in CreateOpt message. 40
Figure A.3 – Example of opt-change in DistributeEvent message . 41

Table A.1 – Elements for opt-change mode . 42

© ISO/IEC 2024
INFORMATION TECHNOLOGY –
HOME ELECTRONIC SYSTEM (HES) APPLICATION MODEL –

Part 3-31: Protocol of energy management agents for demand-response
energy management and interactions among these agents

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 15067-3-31 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/3205/FDIS JTC1-SC25/3219/RVD

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.

– 6 – ISO/IEC 15067-3-31:2024
© ISO/IEC 2024
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 of the ISO/IEC 15067 series, published under the general title Information
technology – Home Electronic System (HES) application model, can be found on the IEC and
ISO websites.
IMPORTANT – The "colour inside" logo on the cover page of this document indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.

© ISO/IEC 2024
INTRODUCTION
This document specifies a protocol to facilitate communications among interacting energy
management agents (EMAs) for energy management applications. This document specifies a
message format and sequences of message exchanges in a protocol called the EMA protocol
(EMAP) to enable logical interactions among EMAs.
EMAP includes messages that enable demand response (DR) in community housing such as
an apartment building or a campus of houses or apartment buildings, as introduced in
ISO/IEC 15067-3-3. ISO/IEC 15067-3-3 was created because utilities throughout the world are
investing heavily in smart grid infrastructures to ensure a reliable supply of electricity and to
accommodate DR technologies for residential homes and apartment buildings. DR programmes
are being offered to residential consumers for energy conservation and for energy management
to align demand for power with available supplies according to customer preferences for
appliance usage and budget constraints. An interacting EMA extends the capability of a single
EMA to allocate energy among houses efficiently in a community and among appliances within
houses, and to accommodate a choice of external energy sources or local energy sources or
both linked to an EMA. External sources can be public utilities or distributed energy resources
(DERs) in other homes, possibly purchased using transactive energy. Local sources can include
renewable power generators and storage devices at the customer premises linked to an EMA.
Consumer devices linked to an EMA can participate in energy management programmes such
as DR and can interconnect logically via an EMA with local DER equipment such as generators
(wind and solar) and energy storage devices.
This document facilitates utility-based DR programmes, but does not mandate such
programmes. Consumers may choose to provide electricity using DER locally with a house, an
apartment complex, a community, or a microgrid without any connection to a public utility. This
document also applies to non-utility DR programmes that are based within the apartment
complex operating as a microgrid.
Typical smart energy services can include integrated energy management for multiple energy
systems, energy sharing and trading within the community, energy information sharing for more
efficient energy usage, etc. These energy services offer benefits in electrical energy
management in a house, a residential community or a building consisting of multiple apartments.
The intent of EMAP is to accommodate flexible and efficient energy management systems over
a broad range of EMA deployments. This document has been developed to promote
interoperability among products from different manufacturers. EMAP enables automated
demand-response services in a house, a residential community or a building consisting of
multiple apartments for co-ordinating and allocating energy consumption and generation among
multiple EMAs in different locations. The co-ordination among EMAs offers improved energy
management and overall efficiency. Each EMA enables the allocation of energy among
appliances and switching energy sources from grid to local generation or storage according to
consumer preferences.
This document specifies message formats for DR, pricing, and DER communications to manage
customer energy resources, including load, generation, and storage in a home, building and
apartment complex. Communication messages specified in this document for the DR command
set support direct load control, time-of-use (TOU), critical-peak-pricing (CPP), real-time pricing
(RTP), peak time rebates, various types of block rates, transactive energy, and a range of opt-
in, opt-out and service modifications. This document can interact with IEC 62746-10-1, which
specifies message and application-layer protocol profiles relevant for systems connected to an
external DR service provider. Unlike IEC 62746-10-1, EMAP can support bi-directional
exchange of DR events between EMAs for co-operative energy management according to the
customer’s budget by using the opt commands in a hierarchical or point-to-point architecture.
If a logical hierarchical tree structure has been installed, EMAP messages (e.g. report, opt) may
be transferred with aggregation or disaggregation through intermediate EMAs. In addition, the
messages (e.g. DR command, report) specified in this document may be relayed across
intermediate EMAs. The aggregation/disaggregation or relay mode is optionally provided.

– 8 – ISO/IEC 15067-3-31:2024
© ISO/IEC 2024
INFORMATION TECHNOLOGY –
HOME ELECTRONIC SYSTEM (HES) APPLICATION MODEL –

Part 3-31: Protocol of energy management agents for demand-response
energy management and interactions among these agents

1 Scope
This document specifies a protocol for energy management agents (EMAs) to facilitate
communications among these agents for demand response (DR) energy management
applications. The EMA protocol (EMAP) provides a logical connection among EMAs in
community housing such as an apartment building or a campus of houses or apartment
buildings. This document also specifies interaction procedures and message formats for DR
energy management as introduced in ISO/IEC 15067-3-3. The EMAP supports interactions
among EMAs at OSI (Open System Interconnection) layer 7 with a message transfer protocol.
An EMA can be embedded in devices such as a thermostat, a smart appliance, or other
consumer products. The choice of interconnection depends on the system and the network
topology, which can be arranged in a mesh or hierarchical tree structure. An intermediate EMA
may relay messages sent between EMAs.
NOTE 1 The application message set that uses the EMAP OSI layer 7 is not part of the protocol specification in this
document. It is part of the EMA above OSI layer 7. The application message set can use the ISO/IEC 14543 series,
ISO/IEC 10192-3, the IEC 62541 series and the ISO/IEC 30118 series.
NOTE 2 This document facilitates utility-based DR programmes, but does not mandate such programmes.
Consumers can choose to provide electricity using DER locally with a house, an apartment complex, a community,
or a microgrid without any connection to a public utility.
NOTE 3 In a residential microgrid, data such as DR messages and price signals can be issued by an energy
management system or an EMA for scheduling, forecasting functions, etc. to optimize energy consumption or
generation without relying on a public utility.
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 15067-3:2012, Information technology – Home Electronic System (HES) application
model – Part 3: Model of a demand-response energy management system for HES
ISO/IEC 15067-3-3:2019, Information technology – Home Electronic System (HES) application
model – Part 3-3: Model of a system of interacting energy management agents (EMAs) for
demand-response energy management
IETF RFC 7252, The Constrained Application Protocol (CoAP), edited by Z. Shelby et al., June
2014, available at: https://tools.ietf.org/rfc/rfc7252.txt [viewed 2023-05-31]

© ISO/IEC 2024
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 15067-3:2012,
ISO/IEC 15067-3-3:2019 and the following 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
client EMA
cEMA
energy management agent (EMA) that acts as a client to another EMA
[SOURCE ISO/IEC 15067-3-3:2019, 3.1.1]
3.1.2
EMA protocol
EMAP
protocol to facilitate communications among interacting energy management agents (EMAs) for
energy management applications
3.1.3
transaction
smallest unit of a work process consisting of an exchange between two or more participants or
systems
[SOURCE ISO 15489-1:2016, 3.18]
3.1.4
server EMA
sEMA
energy management agent (EMA) that acts as a server to other EMAs
[SOURCE ISO/IEC 15067-3-3:2019, 3.1.7]
3.2 Abbreviated terms
cEMA client EMA
CoAP constrained application protocol
DER distributed energy resources
DR demand response
DTLS datagram transport layer security
EMA energy management agent
EMAP EMA protocol
HAN home area network
HTTP hypertext transfer protocol
JSON javascript object notation
OSI open system interconnection
sEMA server EMA
UDP user datagram protocol
– 10 – ISO/IEC 15067-3-31:2024
© ISO/IEC 2024
4 Conformance
Implementations of a protocol among EMAs shall conform to protocol procedures and message
formats specified in Clauses 6 and 7.
5 Energy management agent architecture for home or residential community
5.1 Overview
Figure 1 shows an example of a physical energy management system in a community that
includes multiple private residential homes and common spaces. The configuration shown in
Figure 1 consists of multiple interacting EMAs in the home, which are specified in
ISO/IEC 15067-3-3.
In some cases, one or more EMAs may be physically located in a home. For an apartment
complex, there may be an EMA in each apartment, in the common area of each building, and
in the management office of the complex. An EMA may be embedded in devices such as a
thermostat, a smart appliance, or other consumer products.

NOTE 1 Adapted from Figure 1 of ISO/IEC 15067-3-3:2019 to clarify the functions of the EMAs.
NOTE 2 The home area networks (HANs) are shown with dashed line in black and the power line is shown in solid
green.
NOTE 3 The shapes are explained in 5.2 of ISO/IEC 15067-3-3:2019.
Figure 1 – Example of an energy management system in a residential area

© ISO/IEC 2024
The EMA applies complex algorithms to exchange energy-related data among EMAs and
devices. Such energy-related data may include energy consumption targets, cost of energy,
usage data, energy allocation to appliances, distributed energy resources (DERs), and EMA
locations and rolls within the community.
The EMAP supports interactions among EMAs at OSI layer 7 including application messages
and data. The interactions provide the capability of a system with a single EMA to allocate
energy among houses efficiently in a community and among appliances within houses, and to
accommodate a choice of external energy sources or local energy sources or both linked to the
EMA. External sources may be public utilities or other suppliers. Local sources may include
local power generators and storage devices linked to the EMA. Consumer devices managed by
the EMA can also participate in energy management programmes such as DR and can
interconnect with the EMA including DERs, local generators (wind and solar) and energy
storage devices.
NOTE The application message data and encoding for exchange can use the ISO/IEC 14543 series,
ISO/IEC 10192-3, the IEC 62541 series and the ISO/IEC 30118 series.
The logical network arrangement of EMAs shall consist of a mesh or hierarchical tree structure.
If a hierarchical tree topology is chosen for the interconnection among EMAs, the EMAP
messages may be transferred without modification through an intermediate EMA. In addition,
application layer messages as specified in the ISO/IEC 14543 series, ISO/IEC 10192-3, the
IEC 62541 series and the ISO/IEC 30118 series may be passed across intermediate EMAs for
service integration.
5.2 EMA protocol
The EMAP shall provide a logical interaction among EMAs. The EMAP enables energy
management applications that co-operate and co-ordinate among EMAs. The EMAP specifies
an application-layer protocol that includes protocol procedures and message formats specified
in Clause 6. The EMAP specifies the protocol syntax, semantics, message formats, message
sequences, etc. to ensure interoperability over a broad range of EMA deployments shown in
Figure 2 to Figure 4. It also specifies a communication mechanism through which application
messages may be passed among EMAs. Figure 2 shows a hierarchical EMAP application model
in a residential area. Figure 3 shows a point-to-point EMAP application model. Figure 4 shows a
hybrid EMAP application model. In these figures a product designed as an EMA can be an sEMA
as well as a cEMA. In Figure 2, Figure 3 and Figure 4, arrows are logical connections and red
arrows indicate HAN networks.
To support DR load control in a hierarchical situation, the sEMA shall send DR event or price
signals to the cEMAs. If a cEMA accepts the DR event, then it subscribes to the DR event.
Moreover, the cEMA adjusts the DR event within the available range to avoid penalties while
performing the DR event. The cEMA can update the DR event if the cEMA is unable to limit the
energy consumption under the subscribed control.

Figure 2 – A hierarchical EMAP application model in a residential area

– 12 – ISO/IEC 15067-3-31:2024
© ISO/IEC 2024
Figure 3 – A point-to-point EMAP application model in a residential area
This document specifies the protocol between EMAs in the point-to-point and hierarchical EMA
configurations. Alternative configurations of an EMA framework architecture could be
considered in a different standard.

Figure 4 – A hybrid EMAP application model in a residential area
Clause 6 specifies a set of message exchanges for performing various functions and operations.
Clause 7 contains a set of transport mechanisms for implementing the services. The transport
mechanisms rely upon RFC 7252 "Constrained Application Protocol (CoAP)" and RFC 7159
"JavaScript object notation (JSON) Data Interchange format".
CoAP is a specialized Internet application protocol for devices with limited processing capability,
as specified in RFC 7252. It enables EMA devices to communicate with the Internet using
similar protocols. CoAP is designed for use between devices on the same constrained network
(e.g. low-power wireless home networks), between devices and general nodes on the Internet,
and between devices on different constrained networks both joined by an internet.
JSON is a public file format as specified in RFC 7159 that uses human-readable text to transmit
data objects consisting of attribute–value pairs and array data types (or any other serializable
value). It is a very common data format used for asynchronous browser–server communication.

© ISO/IEC 2024
Clause 6 specifies the following services:
1) RegisterParty: This service identifies a sEMA and a cEMA in advance of interactions using
registration procedures.
2) Event: This service is used to call for service parameters and event information under a
transaction. The service parameters and event information distinguish different types of
events: reliability events, emergency events, price events, regulation events and possibly
other types in the future.
3) Report: The report service enables feedback to the server in order to provide periodic or
one-time information on the state of a resource.
4) Opt: The opt-in service and opt-out service enable the creation and termination of DR events
generated by the service provider. The opt-change service overrides the availability
schedule and addresses short-term changes in availability.
6 EMAP service procedure and message format
6.1 Overview
Clause 6 specifies protocol procedures and message formats to ensure interoperability among
various implementations of EMAs. The application message set and data model (or schema)
will be specified in other standards. Figure 5 illustrates a two-step service procedure in the
EMAP, which consists of the RegisterParty service and the event or report or opt service. The
RegisterParty service identifies an sEMA and a cEMA in advance of interactions using
registration procedures. After completion of party registration, the event or report or opt service
is used to call for event information, the state of a resource, and changes in events, respectively.
In the service procedure the sEMA and cEMA shall communicate using CoAP, as defined in
IETF RFC 7252, in either push mode (where the sEMA initiates communication) or in a pull
mode (the cEMA requests information from the sEMA to begin a series of message exchanges).
The sequence diagrams shown in Clause 6 are for a push interaction pattern. In a pull mode
the cEMA shall periodically poll the sEMA using Poll to provide the sEMA an opportunity to
cancel the registration or request the cEMA to reregister. Refer to 6.6 for sample sequence
diagrams of the pull interaction pattern.
These services use the CoAP connect process and subscription process between the sEMA
and the cEMA. CoAP is a service layer protocol that is intended for use in resource-constrained
internet devices, such as wireless sensor network nodes. CoAP is designed to translate easily
to hypertext transfer protocol (HTTP) for simplified integration with the web, while also meeting
specialized requirements such as multicast support, very low overhead, and simplicity.
The details of how these interactions are performed within the context of a specific transport
mechanism are specified in Clause 7.
All application-level error conditions shall be conveyed through the status code element of the
CoAP response payload. Refer to 7.1.6 for error conditions.

– 14 – ISO/IEC 15067-3-31:2024
© ISO/IEC 2024
Figure 5 – Two-step service procedures of EMAP
The procedures shall employ JSON messaging over the CoAP transport mechanisms, with an
example shown in Annex B. The message format is specified according to each protocol
procedure between the sEMA and the cEMA in Clause 6.
Note that the application message sets used in this document are specified in the JSON schema
file. The schema file will be specified in other standards.
The signal types and parameters for DERs are extended in both the event and report services.
6.2 RegisterParty
6.2.1 Overview
RegisterParty service uses in-band registration of cEMAs with sEMA. The following registration
procedures are supported:
1) Query registration: a process to request registration information related to a DR event.
2) Create registration: a process to proceed with the actual registration to create the session
for the communication based on the information from the query registration procedure.
3) Cancel registration: a process to terminate the registration that was created by the create
registration procedure.
4) Request reregistration: a process to request registration again when registration information
is lost under unexpected circumstances.
A cEMA initiates the query registration procedure to request registration information including
all the profiles and transport names related to a DR event. Then, active registration is created
by the cEMA with the create registration procedure. The sEMA or cEMA can cancel an active
registration with the cancel registration procedure that was created from the create registration
procedure. If the sEMA registration information changes, the sEMA can request registration
again using request reregistration procedure when registration information is lost under
unexpected circumstances.
© ISO/IEC 2024
6.2.2 Query registration
The query registration procedure begins with the cEMA requesting registration information
related to a DR event (see 6.2.6.1) as shown in Figure 6. This query operation can be
implemented using any of the supported transports. However, the cEMA shall be configured
out-of-band with the address of the sEMA in order to initiate the query. The response to the
query is the emapCreatedPartyRegistration (see 6.2.6.2). This payload contains information on
all the profiles and transports supported by the sEMA in addition to any supported extensions
to the profile. The information received by the cEMA can be used to determine the best
configuration to use when formally registering as defined in the schema file.
NOTE Out-of-band configuration can be done by pre-programming or manual insertion during setup or by a
discovery protocol.
Figure 6 – Interaction diagram: Query registration
6.2.3 Create registration
Active registration shall be initiated by the cEMA with the emapCreatePartyRegistration (see
6.2.6.3) including registrationID as shown in Figure 7. The sEMA responds with an
emapCreatedPartyRegistration containing all the profiles and transports supported by the sEMA,
IDs, and other registration-related information (see 6.2.6.2). The registrationID in its response
payload is used for subsequent operations pertaining to this registration instance. Based on the
information including profiles and transport names, the cEMA has decided to create the session
for communicating with the sEMA, in addition to other registration-related information.
If the cEMA registration information already exists, the cEMA can override the registration at
any time using the emapCreatePartyRegistration payload referencing the current registrationID.

Figure 7 – Interaction diagram: Create registration
6.2.4 Cancel registration
The sEMA or cEMA shall cancel an active registration using the emapCancelPartyRegistration
payload, referencing the registrationID. The other party responds with an
emapCanceledPartyRegistration payload. This use case, depicted in Figure 8, shows how one
party can perform cancel registration from the other party.
The same registrationID will be maintained until one of the parties cancels the registration.

– 16 – ISO/IEC 15067-3-31:2024
© ISO/IEC 2024
Figure 8 – Interaction diagram: Cancel registration
6.2.5 Request reregistration
If the sEMA registration information changes, the sEMA shall request registration again when
registration information is lost under unexpected circumstances. The sEMA requests this
change using the emapRequestReregistration (see 6.2.6.6) as shown in Figure 9. The response
to this request is an emapResponse (see 6.2.6.7) as acknowledgement followed by an
asynchronous create registration request from the cEMA.
If the cEMA registration information changes, the cEMA shall reregister the change at any time
using the emapCreatePartyRegistration referencing the current registrationID as described in
6.2.3. The same registrationID will be maintained across re-registrations until one of the parties
cancels the registration.
Figure 9 – Interaction diagram: Request reregistration – Push operation
6.2.6 Message formats for RegisterParty
6.2.6.1 emapQueryRegistration
Figure 10 describes the message format of emapQueryRegistration
...