ISO/IEC 17811-2:2015

Information technology - Device control and management - Part 2: Specification of Device Control and Management Protocol

ISO/IEC 17811-2:2015 provides the specification of Device Control and Management Protocol (DCMP), which is an application-layer protocol used to control and manage the various devices. DCMP supports the device and network status information retrieval, device initialization, firmware and software update, file transmission, and so on. This part of ISO/IEC 17811 specifies the protocol operations and message structure of DCMP. The network security is out of scope in this part of ISO/IEC 17811. However, the security services can be necessary according to applications of DCMP. DCMP can suffer from many network specific threats. To countermeasure those threats, some security mechanism can be deployed.

Technologies de l'information — Commande et gestion de périphériques — Partie 2: Spécifications du protocole de commande et gestion de périphériques

General Information

• Status: Published
• Publication Date: 25-Feb-2015
• ICS: 35.100.70 - Application layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Current Stage: 9060 - Close of review
• Completion Date: 02-Dec-2030

Overview

ISO/IEC 17811-2:2015 specifies the Device Control and Management Protocol (DCMP), an application-layer protocol for controlling and managing diverse networked devices. Part of the ISO/IEC 17811 family, this standard defines DCMP protocol operations, message structure, payload formats and parameter details used for device discovery, status retrieval, firmware/software updates, file transfer, registration, event notification and other management services. The specification assumes reliable delivery is provided by the companion RMDP protocol (Reliable Message Delivery Protocol).

Key topics and technical requirements

• Protocol operations: defined operations include Device Discovery, Device Advertisement, Device Information Retrieval, Device Control, Event Notification and Subscription, Get File Information, File Download/Upload, Apply, Device Registration and Service Registration.
• Message structure: DCMP message formats, payload messages and error types are specified; Annexes include unit/device type codes and XML schema examples for payload messages.
• Interaction with RMDP: DCMP operates over RMDP for reliable message delivery and uses RMDP to map device identifiers to network addresses (IP/port).
• Administrative concepts: Definitions and roles such as Device Management Server (DMS), administrative domain and device identifiers are included.
• Security: Network security mechanisms are explicitly out of scope for Part 2; however, the standard acknowledges that DCMP deployments may require security services and recommends applying appropriate protection against network-specific threats.
• Intellectual property: The document notes a claimed patent relevant to the DCMP message structure (patent holder: ETRI) and directs implementers to patent databases for details.

Practical applications and who uses it

ISO/IEC 17811-2:2015 and the DCMP specification are practical for:

• Device manufacturers implementing standardized remote control and management interfaces (firmware/software update, device initialization).
• IoT solution providers and system integrators building interoperable device management systems.
• Developers of Device Management Servers (DMS) and gateway/RMDP implementations that require reliable mapping and delivery of DCMP messages.
• Network and operations teams implementing large-scale device provisioning, monitoring, file distribution and event-driven management.
• Standards engineers ensuring interoperability across heterogeneous device fleets.

Benefits include standardized device discovery, consistent file transfer and update procedures, and a defined message model that aids integration between devices and management servers.

Related standards

• ISO/IEC 17811-1 - Device Control and Management: Architecture (context, concepts, and service scenarios)
• ISO/IEC 17811-3 - Reliable Message Delivery Protocol (RMDP) (interworking and reliable delivery used by DCMP)

Keywords: ISO/IEC 17811-2:2015, Device Control and Management Protocol, DCMP, device management, device discovery, firmware update, file transfer, RMDP, DMS, IoT device control.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 17811-2
First edition
2015-02-15
Information technology — Device
control and management —
Part 2:
Specification of Device Control and
Management Protocol
Technologies de l’information — Commande et gestion de
périphériques —
Partie 2: Spécifications du protocole de commande et gestion de
périphériques
Reference number
©
ISO/IEC 2015
© ISO/IEC 2015
All rights reserved. Unless otherwise specified, 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
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2015 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Terms and definitions . 1
3 Abbreviation . 2
4 Overview . 2
5 Protocol Operation . 4
5.1 Device Discovery . 4
5.2 Device Advertisement . 5
5.3 Device Information Retrieval. 5
5.4 Device Control . 5
5.5 Event Notification . 6
5.6 Event Subscription . 6
5.7 Get File Information . 7
5.8 File Download . 7
5.9 File Upload . 8
5.10 Apply . 9
5.11 Device Registration . 9
5.12 Service Registration .10
6 Messages .10
6.1 DCMP Message Structure .10
6.2 Messages according to the Operations .12
6.3 Error Types of DCMP .13
6.4 Payload Messages .15
Annex A (normative) Unit Types and Codes .50
Annex B (normative) Device Types .51
Annex C (informative) XML Schema and Example of DCMP Payload Message .52
Bibliography .130
© ISO/IEC 2015 – All rights reserved iii

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. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT), see the following URL: Foreword — Supplementary information.
ISO/IEC 17811-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology SC 6,
Telecommunications and information exchange between systems.
iv © ISO/IEC 2015 – All rights reserved

Introduction
This International Standard provides the architecture for device control and management (DCM).
DCM can support the various control and management services, regardless of the network protocols
or interfaces. DCM is composed of two protocols; device control and management protocol (DCMP) and
reliable message delivery protocol (RMDP).
This International Standard, ISO/IEC 17811, consists of the following parts:
— Part 1: Architecture
— Part 2: Specification of Device Control and Management Protocol
— Part 3: Specification of Reliable Message Delivery Protocol
ISO/IEC 17811-1 describes the architecture of DCM, which includes definition, general concept,
requirements, design principles, service scenarios for device management control, and management.
ISO/IEC 17811-2 specifies the Device Control and Management Protocol (DCMP), which includes the
functional entities, protocol operations, message structure, and detailed parameter format associated
with DCMP.
ISO/IEC 17811-3 specifies the Reliable Message Delivery Protocol (RMDP), which includes the
interworking with DCMP, protocol operations, and message structure associated with RMDP.
The International Organization for Standardization (ISO) and International Electrotechnical Commission
(IEC) draws attention to the fact that it is claimed that compliance with this International Standard may
involve the use of a patent concerning the message structure of DCMP given in Clause 7.
ISO and IEC take no position concerning the evidence, validity, and scope of this patent right.
The holder of this patent right has assured the ISO and IEC that he is willing to negotiate licences either
free of charge or under reasonable and non-discriminatory terms and conditions with applicants
throughout the world. In this respect, the statement of the holder of this patent right is registered with
ISO and IEC. Information may be obtained from:
Patent Holder: Electronics and Telecommunications Research Institute (ETRI)
Address: 138 Gajeongno, Yuseong-gu, Daejeon, 305-700, Korea
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights other than those identified above. ISO and IEC shall not be held responsible for identifying
any or all such patent rights.
ISO (www.iso.org/patents) and IEC (http://patents.iec.ch) maintain on-line databases of patents relevant
to their standards. Users are encouraged to consult the databases for the most up to date information
concerning patents.
© ISO/IEC 2015 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 17811-2:2015(E)
Information technology — Device control and
management —
Part 2:
Specification of Device Control and Management Protocol
1 Scope
This part of ISO/IEC 17811 provides the specification of Device Control and Management Protocol
(DCMP), which is an application-layer protocol used to control and manage the various devices.
DCMP supports the device and network status information retrieval, device initialization, firmware
and software update, file transmission, and so on. This part of ISO/IEC 17811 specifies the protocol
operations and message structure of DCMP.
The network security is out of scope in this part of ISO/IEC 17811. However, the security services can be
necessary according to applications of DCMP. DCMP can suffer from many network specific threats. To
countermeasure those threats, some security mechanism can be deployed.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
device control and management
DCM
purposed to control and manage the various smart devices
Note 1 to entry: For this purpose, DCM is composed of the two protocols; Device Control and Management Protocol
(DCMP) and Reliable Message Delivery Protocol (RMDP).
[SOURCE: ISO/IEC 17811-1]
2.2
device control and management protocol
DCMP
used to perform various management operations which are categorized into information retrieval,
control, diagnostic, and debugging
[SOURCE: ISO/IEC 17811-1]
2.3
reliable message delivery protocol
RMDP
used to provide uniform and reliable message delivery among devices regardless of the underlying
network protocols or interfaces
[SOURCE: ISO/IEC 17811-1]
2.4
administrative domain
represents a network area where a single administrator can configure and manage a network with the
same policy
[SOURCE: ISO/IEC 17811-1]
© ISO/IEC 2015 – All rights reserved 1

2.5
device management server
DMS
used to keep track of the various device information and also to manage the devices in an administration
domain
Note 1 to entry: There may be one DMS in an administrative domain, if needed.
[SOURCE: ISO/IEC 17811-1]
3 Abbreviation
The following abbreviations are used in this document.
DCMP Device Control and Management Protocol
DCM Device Management Architecture and Protocol
DMS Device Management Server
RMDP Reliable Message Delivery Protocol
NTP Network Time Protocol
UUID Universally Unique Identifier
UPnP Universal Plug and Play
4 Overview
The DCMP is a protocol used to control and manage a variety of smart devices in the network. The DCMP
messages are exchanged between different devices or between device and DMS.
The DCMP operates over RMDP for reliable message delivery. In the networking perspective, RMDP
provides one or more devices with an interface to the network. That is, a group of devices are connected
to an RMDP node via an internal API interface or a network, and the RMDP performs the reliable delivery
of DCMP messages to the different RMDP nodes which are also connected to other devices. For this
purpose, RMDP maintains the mapping information between DCM device identifier and physical network
identifier such as IP address and port number. After RMDP retrieves the target node information, DCMP
messages can be exchanged over RMDP.
Figure 1 gives a general example of DCM operations between a device and DMS. Those operations are
divided into RMDP initialization, DCMP initialization, and management service.
2 © ISO/IEC 2015 – All rights reserved

Figure 1 — DCM Operations
The RMDP manages the mapping information between the device identifier and physical network
identifier. For an advertisement of the physical network identifier information in the RMDP initialization
phase, a “NODE_ADVERTISEMENT” and “NODE_DISCOVERY_REQUEST/RESPONSE” messages are
broadcast by the RMDP. To advertise the device identifier information, an OBJECT_ADVERTISEMENT
message is then broadcast by the RMDP. The physical address information of the DMS can be added in
the RMDP module of a device using the API of RMDP. The RMDP module of the device sends a NODE_
ADVERTISEMENT message using a broadcast to the other devices connected in the local network, but
the RMDP module of the device uses a unicast when sending the NODE_ADVERTISEMENT message to
the DMS. The RMDP module of the DMS can manage the physical address information of the device
using the socket information, that is, the IP address and port information of the access point (AP) or
router. In the DCMP initialization phase, the DCMP modules of DMS and device can retrieve the basic
information of the concerned devices (e.g. device name, device ID and device type) by using the “DEVICE_
ADVERTISEMENT” and “DEVICE_DISCOVERY_REQUEST/RESPONSE” messages. In these processes,
the DCMP module asks its RMDP module with the device ID of the target (corresponding) device by
using a DCMP message, and then the RMDP module will transmit the received DCMP message to the
target RMDP module of the target device. In the management service phase, a device can register its
basic information (e.g., model name, model number and serial number) on the DMS server by using the
“DEVICE_REGISTRATION_REQUEST/RESPONSE” message of DCMP.
The protocol operations of DCMP are classified as follows:
— Device Discovery;
— Device Advertisement;
© ISO/IEC 2015 – All rights reserved 3

— Device Information Retrieval;
— Device Control;
— Event Notification;
— Event Subscription;
— Get File Information;
— File Download;
— File Upload;
— Apply;
— Device Registration; and
— Service Registration.
5 Protocol Operation
5.1 Device Discovery
For device discovery, a DEVICE_DISCOVERY_REQUEST and DEVICE_DISCOVERY_RESPONSE messages
are exchanged between devices, as shown in Figure 2. A source device broadcasts a DEVICE_DISCOVERY_
REQUEST message to the target devices. In response to the DEVICE_DISCOVERY_REQUEST message, all
devices which fit into the requested information shall respond with a DEVICE_DISCOVERY_RESPONSE
message.
Figure 2 — Device Discovery Operation
The device discovery operation is performed with a two-message transaction. This operation requires
a request message at source and a response message at the destination. When a response message
is not received within a specific time interval, the source may cancel the transaction or re-issue the
transaction.
4 © ISO/IEC 2015 – All rights reserved

5.2 Device Advertisement
The device advertisement operation can be used to inform device’s plug-in or plug-out, as shown in
Figure 3. The associated device advertisement transaction is one-way transaction. This means that only
one message is required to finish a transaction, and any response message is not required.
Figure 3 — Device Advertisement Operation
5.3 Device Information Retrieval
The device information retrieval operation can be used when a device needs to know the various device
information such as device ID, device name, device property, device status and so on. The volume of the
device information is various and depends on the type of device and its capability. To accommodate
different level of devices, we may categorize the relevant information into device basic information,
device configuration, and system and network information. The basic information represents the fixed
information for all devices, whereas the other information is variable for each device.
The operation of device information retrieval is composed of two-message transaction, as shown in
Figure 4. This operation requires a request message at source and a response message at destination.
When a response message is not received within a specific time interval, the source may cancel the
transaction or re-issue the transaction.
Figure 4 — Device Information Retrieval Operation
5.4 Device Control
Device control is used to perform device specific operations. For device control, a source device
shall provide the control code and parameters associated with the device control operation. When a
© ISO/IEC 2015 – All rights reserved 5

target device receives a DEVICE_CONTROL_REQUEST message, it checks if it the message contains a
valid control code for the device and if the control code can be supported. If so, it executes the control
operation requested and returns the result to the source device with a DEVICE_CONTROL_RESPONSE
message, as shown in Figure 5.
The operation of device control is performed with a two-message transaction. This operation requires a
request message at source and a response message at the destination. When a response message is not
received within a specific time interval, the source device may cancel the transaction or re-issue the
transaction.
Figure 5 — Device Control Operation
5.5 Event Notification
When an event occurs in a device, the event can be reported to the interested devices by EVENT_
NOTIFICATION message, as shown in Figure 6. Event notification transaction is one-way transaction.
This means that only one message is required to finish a transaction, and any response message is not
required.
Figure 6 — Event Notification Operation
5.6 Event Subscription
When an event occurs in a device, the event can be reported to all devices in a network. However, whenever
an event is broadcast to all devices in network, the event messages are overwhelmed in the network.
So, the event information shall be reported to only the interested devices. For this purpose, the event
handling related operations include event notification as well as the associated event subscription/un-
subscription operations. This is helpful to reduce traffic overhead within a local network.
6 © ISO/IEC 2015 – All rights reserved

The operation of event subscription is a two-message transaction, as shown in Figure 7. This operation
requires a request message at source and a response message at destination. When a response message
is not received within a specific time interval, the source may cancel the transaction or re-issue the
transaction.
Figure 7 — Event Subscription Operation
5.7 Get File Information
The file upload and download capability is the essential functions for device management, since the
software or firmware update requires the updated file to be transferred to the target device. Sometimes
it is useful to send quite a large size of message instead of using a simple message transfer. So, the file
upload/download operation is defined as a part of common device operations. The processing of the
files is various in a large system. So, we classify each file by a file type and provide this information with
the file.
The operation of ‘get file information’ is a two-message transaction, as shown in Figure 8. This operation
requires a request message at source and a response message at destination. When a response message
is not received within a specific time interval, the source device may cancel the transaction or re-issue
the transaction.
Figure 8 — Get File Information Operation
5.8 File Download
The file download capability is an essential function for device management since the software or
firmware update requires the updated file to be transferred to the target device. Sometimes it is useful
to send quite a large size of message instead of using a simple message transfer. So, file upload/download
operation is defined as a part of common device operations.
© ISO/IEC 2015 – All rights reserved 7

The file download transaction can be used to get some file in a remote device and totally the three
messages are required, as shown in Figure 9. First, a source device requests the file download by using
a GET_FILE_REQUEST message. Then, a destination device decides if the request is accepted or rejected.
When the request is accepted, the destination device shall respond with a GET_FILE_RESPONSE message
containing a SUCCESS indication code. However, if the destination device rejects the file transfer, the ‘get
file’ transaction is terminated.
After finishing the file transfer, the destination device sends a GET_FILE_RESULT message with a
SUCCESS indication code. When a file transfer is aborted by some reasons, the destination device sends
the GET_FILE_RESULT message with an appropriate error code.
Figure 9 — File Download Operation
5.9 File Upload
The file upload capability is an essential function for device management since the software or firmware
update requires the updated file to be transferred to the target device. Sometimes it is useful to send
quite a large size of message instead of using a simple message transfer. So, file upload/download
operation is defined as a part of common device operations.
The file upload transaction can be used to send some file from the source device to the target device
and totally the three messages are required, as shown in Figure 10. First, a source device requests the
file upload by using a PUT_FILE_REQUEST message. Then, a destination device decides if the request is
accepted or rejected. When the request is accepted, the destination device shall respond with a PUT_
FILE_RESPONSE message containing a SUCCESS indication code. However, if the destination device
rejects the file transfer, a ‘put file’ transaction is terminated.
After finishing the file transfer, the source device sends a PUT_FILE_RESULT message with a SUCCESS
indication code. When a file transfer is aborted by some reasons, the source device sends the PUT_FILE_
RESULT message with an associated error code.
8 © ISO/IEC 2015 – All rights reserved

Figure 10 — File Upload Operation
5.10 Apply
Apply transaction can be used to request a critical control action to a device and get the result, as shown
in Figure 11. A source device requests an APPLY_REQUEST message specifying the requested operation
such as firmware update, reboot, configuration, etc. Then a destination device decides if the request will
be accepted or rejected. When the requested operation is accepted, then the device immediately replies
with an APPLY_RESPONSE message and performs the requested action. When the requested action is
finished, then an apply result message is sent back to the source device.
Figure 11 — Apply Operation
5.11 Device Registration
Device registration message can be used when a device wants to register its own information to the
DMS. The operation of device registration is a two-message transaction, as shown in Figure 12. This
operation requires a request message at source and a response message at destination. When a response
message is not received within a specific time interval, the source device may cancel the transaction or
re-issue the transaction.
© ISO/IEC 2015 – All rights reserved 9

Figure 12 — Device Registration Operation
5.12 Service Registration
Service registration message can be used when a source device wants to register the service-specific
information with the DMS. The operation of service registration is a two-message transaction, as shown
in Figure 13. This operation requires a request message at source and a response message at destination.
When a response message is not received within a specific time interval, the source may cancel the
transaction or re-issue the transaction.
Figure 13 — Service Registration Operation
6 Messages
6.1 DCMP Message Structure
Basically DCMP message is composed of header and payload. Message header includes the information
about ‘Start signal’, ‘Source device ID’, ‘Target device ID’, ‘Message Type’ and so on. Especially ‘Message
Type’ defines the various functions, which can be provided by DCMP and the payload message is
determined according to the ‘Message Type’. Figure 14 and Table 1 shows the more details about header
message structure of DCMP.
10 © ISO/IEC 2015 – All rights reserved

Figure 14 — DCMP Message Header Structure
Table 1 — Description of DCMP Message Header Structure
Field Name Size (Byte) Description
—  Protocol Version
Version 1
—  0x01
—  Urgent flag
Flag 1
—  Emergency: 0x01/Normal: 0x00
—  Describes Payload Type (removes table)
0x01 Binary
Payload Type 1
0x02 XML
0x03 ~ 0xFF Reserved
© ISO/IEC 2015 – All rights reserved 11

Table 1 (continued)
Field Name Size (Byte) Description
—  Describes Encoding Type
0x01 ASCII
0x02 UNICODE
Encoding Type 1
0x03 UTF-8
0x04 UTF-16
0x05 ~ 0xFF Reserved
Length 4 —  Message Size (Including Header)
—  Source Device ID
Source ID 16 —  Random generation using the UUID
—  Can be Installed when a device is manufactured
Destination ID 16 —  Destination device ID (UUID)
Message Type 2 —  Message type Code for the DCMP operations
—  Transaction Identifier
TransactionID 8 —  The value will be NTP timestamp
—  time_t 8bytes
Optional Header/
16 —  Reserved
DATA
6.2 Messages according to the Operations
Major operations, which can be provided by DCMP, are Information (ex: device properties and status)
providing, remote device control, remote maintenance and device self-organization. These operations
can be classified by ‘Message Type’ and more details about ‘Message Type’ are shown in Table 2.
In case that the REQUEST message is transmitted and the corresponding RESPONSE message is not
returned within an appropriate time, the indication that the REQUEST was not successful will be
delivered to the user without retransmission. The receiver who received the REQUEST shall respond if
the transaction ID is valid.
Transaction ID in RESPONSE message will be same to the transaction ID of the corresponding REQUEST
message.
Table 2 — DCMP Message and Message type
Message
Operation Message Description
Type
DEVICE_DISCOVERY_REQUEST 0x1111
Device Discovery —  Device Searching
DEVICE_DISCOVERY_RESPONSE 0x1112
Device Advertise-
DEVICE_ADVERTISEMENT 0x1121 —  Plug in/out
ment
DEVICE_INFO_REQUEST 0x2011 —  Device Description
Device Info
DEVICE_INFO_RESPONSE 0x2012 —  Device/Network State
DEVICE_CONTROL_REQUEST 0x2111
Device Control —  Device Control
DEVICE_CONTROL_RESPONSE 0x2112
12 © ISO/IEC 2015 – All rights reserved

Table 2 (continued)
Message
Operation Message Description
Type
—  Report the changes of
device status
(Device/Network)
Event EVENT_NOTIFICATION 0x2FF1
—  SENSOR Data
—  User defined Event
EVENT_SUBSCRIPTION_REQUEST 0x2F11
—  Event Subscription/
Event Subscription
Cancelation
EVENT_SUBSCRIPTION_RESPONSE 0x2F12
GET_FILEINFO_REQUEST 0x2211
Get File Info —  File Info. Request
GET_FILEINFO_RESPONSE 0x2212
GET_FILE_REQUEST 0x2221
—  Get file Request/
Response
Get File GET_FILE_RESPONSE 0x2222
—  Transaction Result
GET_FILE_RESULT 0x2223
PUT_FILE_REQUEST 0x2231
—  Put file Request/
Response
Put File PUT_FILE_RESPONSE 0x2232
—  Transaction Result
PUT_FILE_RESULT 0x2233
APPLY_REQUST 0x2311
Update, Rollback, Execution of
Apply APPLY_RESPONSE 0x2312 FILE (Firmware, Configuration,
etc.)
APPLY_RESULT 0x2313
DEVICE_REGISTRATION_REQUEST 0x3111
Device Registration Device Registration (or Cancel)
DEVICE_REGISTRATION_RESPONSE 0x3112
SERVICE_REGISTRATION_REQUEST 0x3121
Service Registra- User Registration/
tion Delete/Add
SERVICE_REGISTRATION_RESPONSE 0x3122
User Defined Trans- 0x8000 ~
USER Defined Operation User defined transaction
action 0xFFFF
6.3 Error Types of DCMP
DCMP defines various error codes, which can be occurred during the message operation or specific
service. Error codes can be classified into three types; ‘Common Error’, ‘Device Specific Error’ and ‘User
Defined Error’. More details of each error type are listed below and the description of error codes is
shown in Table 3.
Common Error
— Using the value from 0x0000 to 0x0FFF
— Common Error defines 4 different types of error
— Message Error: errors of message header and payload
— Transaction Error: transaction-related errors
— File transmission Error: errors that occurred in file transmission
— Apply Error: errors that occurred in apply action
Device Specific Error
— Using the value from 0x1000 to 0xEFFF
© ISO/IEC 2015 – All rights reserved 13

— DCM defines device specific errors according to the device type.
User Defined Error
— Using the value from 0xF000 to 0xFFFF
— Defines user defined errors
Table 3 — Error Types
Error Type (Hex) Description
0000 Success
0100 Header Error
0100 Header Start Message Error
0101 Header Version Message Error
0102 Header Length Message Error
0103 Header Source ID Error
0104 Header Destination ID Error
0105 Header OP Code Error
0000 ~ 09FF
0106 Header TransactionID Error
(Message Error)
0107 Header CRC Error
0108 Header End Message Error
0200 Payload Error
0201 No Payload
0202 Whole Payload data can’t be received
Payload size Mismatch between the received data and the
0000 ~ 0FFF 0203
size which is described in the Header
(Common Error)
0204 Payload Syntax Error
0000 Success
0A01 Other operation is running
0AXX
0A02 Transaction is stopped
(Transaction
Error)
0A03 Deadlock
0A04 Transaction Time over
0000 Success
0B01 Command not implemented
0B02 Bad sequence of commands
0B03 Syntax error, command unrecognized
0BXX
0B04 User not logged in
(File transmis-
sion Error)
0B05 Need account for storing files
0B06 File unavailable (e.g., file not found, no access)
0B07 Storage allocation exceeded
0B08 Illegal file name
14 © ISO/IEC 2015 – All rights reserved

Table 3 — (continued)
Error Type (Hex) Description
0000 ~ 0FFF 0BXX 0B09 Service not available
(Common Error) (File transmis- 0B0A Need account for login
sion Error)
0B0B Can’t open data connection
0B0C Connection closed, transfer aborted
0B0D File unavailable (e.g., file busy)
0B0E Local error in processing
0B0F Insufficient storage space in system
0B10 Service ready in (n) minutes
0B11 Data connection already open, transfer starting
0B12 Data connection open, no transfer in progress
0B13 Closing data connection
0CXX 0000 Success
(Apply Error) 0C01 Apply trying
0C02 Apply request is ordered but Apply action can’t be executed
0C03 Another apply operation is running
0C0A No apply operation to be performed
0C0B Can’t receive any apply file
0C0C Apply file is broken
0D00 ~ 0FFF Reserved
F000 ~ FFFF Device Specific Error Code
1000 ~ EFFF User defined Error code
6.4 Payload Messages
6.4.1 Related subclause for each DCMP message structure
DCMP message is composed of header and payload. The payload data is described according to the
Message Type in the header. Table 4 shows the related subclauses for each DCMP message structure.
Table 4 — Related Subclause for each Message Payload Structure
Operation Message Related Subclause
DEVICE_DISCOVERY_REQUEST subclause 6.4.2
Device Discovery
DEVICE_DISCOVERY_RESPONSE subclause 6.4.3
Device Advertise-
DEVICE_ADVERTISEMENT subclause 6.4.4
ment
DEVICE_INFO_REQUEST subclause 6.4.5
Device Info
DEVICE_INFO_RESPONSE subclause 6.4.6
DEVICE_CONTROL_REQUEST subclause 6.4.7
Device Control
DEVICE_CONTROL_RESPONSE subclause 6.4.8
Event EVENT_NOTIFICATION subclause 6.4.9
EVENT_SUBSCRIPTION_REQUEST subclause 6.4.10
Event Subscription
EVENT_SUBSCRIPTION_RESPONSE subclause 6.4.11
© ISO/IEC 2015 – All rights reserved 15

Table 4 (continued)
Operation Message Related Subclause
GET_FILEINFO_REQUEST subclause 6.4.12
Get File Info
GET_FILEINFO_RESPONSE subclause 6.4.13
GET_FILE_REQUEST subclause 6.4.14
Get File GET_FILE_RESPONSE subclause 6.4.15
GET_FILE_RESULT subclause 6.4.16
PUT_FILE_REQUEST subclause 6.4.17
Put File PUT_FILE_RESPONSE subclause 6.4.18
PUT_FILE_RESULT subclause 6.4.19
APPLY_REQUST subclause 6.4.20
Apply APPLY_RESPONSE subclause 6.4.21
APPLY_RESULT subclause 6.4.22
DEVICE_REGISTRATION_REQUEST subclause 6.4.23
Device Registration
DEVICE_REGISTRATION_RESPONSE subclause 6.4.24
SERVICE_REGISTRATION_REQUEST subclause 6.4.25
Service Registration
SERVICE_REGISTRATION_RESPONSE subclause 6.4.26
6.4.2 DEVICE_DISCOVERY_REQUEST
— This message can be used when a device or service needs to know which devices are connected in the
network. Device discovery request can be performed with specific conditions (i.e. DiscoveryReqType)
such as device identifier, device type or device name.
— If ‘DeviceName’ or ‘DeviceID’ is selected for the discovery request condition, ‘StrTypeReq’ (20 Bytes
string) would be described and ‘DeviceType’ is selected, ‘HexTypeReq’ (2 Bytes Hex code) would be
described respectively.
— If discovery condition is ‘All’, ‘StrTypeReq’ and ‘HexTypeReq’ field shall not be described either.
— The payload message structure is shown in Figure 15 and Table 5.
Figure 15 — DEVICE_DISCOVERY_REQUEST Message Structure
16 © ISO/IEC 2015 – All rights reserved

Table 5 — Description of DEVICE_DISCOVERY_REQUEST Message Structure
Field Name Field Size Description
Describes one of the following
—  All
16 Bytes
DiscoveryReqType —  DeviceID
(Char[16])
—  DeviceType
—  DeviceName
16 Bytes
Describes device name or device ID according to the Discov-
StrTypeReq
eryRequestType
(Char[16])
2 Bytes
HexTypeReq Describes device type according to the DiscoveryRequestType
(uint16_t)
6.4.3 DEVICE_DISCOVERY_RESPONSE
— This message is a response message for the DEVICE_DISCOVERY_REQUEST.
— Result: Describes whether discovery request message is reached to the destination well or not. If an
error occurred, error code is described as shown in the Table 3.
— DeviceList : Describes device list including the information of ‘Number of Devices’, ‘Device ID’,
‘Device Type’, ‘Device Name’, ‘Device Subname’ and ‘Device Capability’
— Each device has ‘device type’ according to its function. However, some devices have multi-functions
and these devices can be expressed by combination of ‘device type’ (ex: Printer + Scanner).
‘DeviceCapabilityList’ describes a list of ‘device type’.
— The payload message structure is shown in Figure 16 and Table 6.
Figure 16 — DEVICE_DISCOVERY_RESPONSE Message Structure
Table 6 — Description of DEVICE_DISCOVERY_RESPONSE Message Structure
Field Name Field Size Description
2 Bytes
Result Result code (Table 3)
(uint16_t)
2 Bytes
DeviceType Device Type (Annex B)
(uint16_t)
16 Bytes
DeviceID Device ID
(Char[16])
16 Bytes
DeviceName Device Name
(Char[16])
© ISO/IEC 2015 – All rights reserved 17

Table 6 (continued)
Field Name Field Size Description
16 Bytes Device Sub name
DeviceSubName
(Char[16]) Describes in case of need
2 Bytes
numofcapability Number of Capability M
(uint16_t)
st
DeviceCapability 2 Bytes (uint16_t) 1 Device Type (Annex B)
… … …
th
DeviceCapability 2 Bytes (uint16_t) M Device Type (Annex B)
6.4.4 DEVICE_ADVERTISEMENT
— This message is used to inform the device’s plug-in or plug-out.
— This message structure is similar to the DEVICE_DISCOVERY_RESPONSE, but ‘AdType’ is added to
distinguish between start(in) signal and end(out) signal.
Figure 17 — DEVICE_ADVERTISEMENT Message Structure
Table 7 — Description of DEVICE_ADVERTISEMENT Message Structure
Field Name Field Size Description
Describes one of the following
16 Bytes
AdType —  Start
(Char[16])
—  End
2 Bytes
DeviceType Device Type (Annex B)
(uint16_t)
16 Bytes
DeviceID Device ID
(Char[16])
16 Bytes
DeviceName Device Name
(Char[16])
16 Bytes
DeviceSubName Describes Device Sub name in case of need
(Char[16])
2 Bytes
numofcapability Number of Capability M
(uint16_t)
st
DeviceCapability 2 Bytes (uint16_t) 1 Device Type (Annex B)
… … …
th
DeviceCapability 2 Bytes (uint16_t) M Device Type (Annex B)
6.4.5 DEVICE_INFO_REQUEST
18 © ISO/IEC 2015 – All rights reserved

— A DEVICE_INFORMATION_REQUEST message is used when a device needs to know the system and
network information of the other devices.
— In order to request device information, ‘DeviceInfoReqType’ shall be described and this request
type is divided into three types;
— BasicInfo: Basic information including the ‘Device ID’, ‘Device Type’ and etc.
— FunctionList: Function list, which can be supported by device.
— DeviceProperty:
— CommonProperty: General information such as manufacture, version and so on.
— ConfigProperty: Information about the setting parameters.
— StatusProperty: Dynamic information such as CPU, memory or network usage.
— DeviceSpecificProperty: Device specific properties, which are defined according to the
device type.
— ‘FullDescription’ (includes above three types), ‘CommonProperty’, ‘ConfigProperty’, ‘StatusProperty’
and ‘DeviceSpecificProperty’ can be used for the ‘DeviceInfoReqType’ respectively.
— The payload message structure is shown in Figure 18 and Table 8.
Figure 18 — DEVICE_INFO_REQUEST Message Structure
Table 8 — Description of DEVICE_INFO_REQUEST Message Structure
Field Name Field Size Description
Describes one of the following
—  FullDescription
—  BasicInfo
—  FunctionList
32 Bytes
DeviceInfoReqType —  DeviceProperty
(Char[32])
—  CommonProperty
—  ConfigProperty
—  StausProperty
—  DeviceSpecificProperty
6.4.6 DEVICE_INFO_RESPONSE
— This message is a response message for the DEVICE_INFO_REQUEST.
— The response information can be classified into ‘FullDescription’, ‘BasicInfo’, ‘FunctionList’,
‘DeviceProperty’, ‘CommonProperty’, ‘ConfigProperty’, ‘StatusProperty’, and
‘DeviceSpecificProperty’ according to the request type.
© ISO/IEC 2015 – All rights reserved 19

6.4.6.1 When ‘DeviceInfoReqType’ is ‘BasicInfo’
— ‘BasicInfo’ describes device basic information such as ‘Number of Devices’, ‘Device ID’, ‘Device Type’,
‘Device Name’ and ‘Device Capability’
Figure 19 — DEVICE_INFO_RESPONSE Message Structure
Table 9 — Description of DEVICE_INFO_RESPONSE Message Structure (When
‘DeviceInfoReqType’ is ‘BasicInfo’)
Field Name Field Size Description
2 Bytes
Result Error Code (Table 3)
(uint16_t)
2 Bytes
numofdevice Number of device
(uint16_t)
2 Bytes
DeviceType Device Type (Annex B)
(uint16_t)
16 Bytes
DeviceID Device ID
(Char[16])
16 Bytes
DeviceName Device Name
(Char[16])
16 Bytes
DeviceSubName Describes Device Sub name in case of need
(Char[16])
2 Bytes
numofcapability Number of Capability M
(uint16_t)
DeviceCapability 2 Bytes (uint16_t) 1st Device Type (Annex B)
… … …
th
DeviceCapability 2 Bytes (uint16_t) M Device Type (Annex B)
6.4.6.2 When ‘DeviceInfoReqType’ is ‘FunctionList’
— ‘FunctionList’ describes a list of function, which can be supported by a certain device.
— Function ID: is defined according to each device type.
— FunctionCategory: let the service knows whether this message is for the control (needs response) or
event (don’t need response).
20 © ISO/IEC 2015 – All rights reserved

— ‘InputList’ is the input parameters needed in a certain device control. This information includes
input size, id, name and so on.
— Input: describes the single input parameter information
— Inputs: describes list of ‘Input’s.
— ‘OutputList’ is the response parameters including the event data. This information includes output
size, id, name and so on.
— Output: describes the single output parameter information
— Outputs: describes list of ‘Output’s.
— Data: describes data value with data name, value unit, minimum data value, maximum data value
and so on
Figure 20 — DEVICE_INFO_RESPONSE Message Structure
Table 10-1 — Description of DEVICE_INFO_RESPONSE Message Structure (When
‘DeviceInfoReqType’ is ‘FunctionList’)
Field Name Field Size Description
2 Bytes
Result Error Code (Table 3)
(uint16_t)
2 Bytes
numofdevice Number of device
(uint16_t)
2 Bytes
numoffunction Number of Function (N)
(uint16_t)
16 Bytes
DeviceID Device ID (UUID)
(Char[16])
© ISO/IEC 2015 – All rights reserved 21

Table 10(
...