ISO 19080:2016

Intelligent transport systems — Communications access for land mobiles (CALM) — CoAP facility

ISO 19080:2016 describes the CoAP facilities between two or more ITS stations communicating over the global internet communication network. It is assumed that the reader is familiar with IETF specifications found in request for comments (RFCs) of individual CoAP and 6LoWPAN protocol blocks used within this document. This document does not define a new protocol, a new exchange of messages at the CoAP layer, or new data structures. It defines how protocols standardized by IETF are combined so that ITS stations can communicate with one another using CoAP. Procedures defined to share information between the CoAP layer and other components of the ITS station architecture are defined in ISO 24102 series (Management). In addition to the requirements specified within this document, a number of notes and examples are provided to illustrate CoAP main facilities.

Systèmes intelligents de transport — Accès aux communications des services mobiles terrestres (CALM) — Équipements CoAP

General Information

• Status: Published
• Publication Date: 04-Oct-2016
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 16 - Communications
• Current Stage: 9060 - Close of review
• Start Date: 04-Jun-2027

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 19080
First edition
2016-10-01
Intelligent transport systems —
Communications access for land
mobiles (CALM) — CoAP facility
Systèmes intelligents de transport — Accès aux communications des
services mobiles terrestres (CALM) — Équipements CoAP
Reference number
ISO 19080:2016(E)
©
ISO 2016

---------------------- Page: 1 ----------------------
ISO 19080:2016(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO 2016, Published in Switzerland
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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO 2016 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 19080:2016(E)

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 3
5 Requirements . 3
5.1 Categories . 3
5.2 ITS-S nodes implementing CoAP . 4
5.2.1 General. 4
5.2.2 Requirements on all ITS-S CoAP nodes . 6
5.3 CoAP functional modules . 7
5.3.1 General. 7
5.3.2 CoAP management module. 8
5.3.3 CoAP security module .11
5.4 Optional module .12
5.4.1 General.12
5.4.2 CoAP/HTTP interoperability .13
5.4.3 Resource directory .15
5.4.4 Blockwise transfers .16
5.5 Modules implemented in ITS-S CoAP nodes . .17
5.5.1 General.17
5.5.2 ITS-S CoAP full function device modules .17
5.5.3 ITS-S CoAP reduced function device modules .17
Bibliography .18
© ISO 2016 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 19080:2016(E)

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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 ISO documents 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 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 World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
iv © ISO 2016 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 19080:2016(E)

Introduction
The set of International Standards that collectively refer to communications access for land mobile
(CALM) focus on the specification of open interfaces regarding the functionality required by all relevant
layers and entities of a Standard ITS station reference architecture.
These International Standards are designed to allow interoperable instantiations of ITS stations, which
are based on the concept of abstracting applications and services from the underlying communication
layers. This abstraction makes the ITS station architecture described herein ideally suited to the
development and deployment of Cooperative ITS applications and services.
The set of CALM International Standards include specifications for security in ITS communications,
ITS-S management, distributed ITS-S implementations, legacy communication media interfaces, legacy
application interfaces and new communication interfaces specifically designed for ITS applications,
such as those designed for safety of both life and property.
The fundamental advantage of the CALM concept with respect to traditional systems is the ability to
support vertical handovers between the various media that can be included in a CALM system. Handover
mechanisms are defined within the CALM architecture International Standard (ISO 21217), the CALM
medium service access points International Standard (ISO 21218) and the CALM communication and
station management International Standard (ISO 24102).
At network layer, CALM IPv6 networking ISO 21210 and CALM 6LoWPAN networking ISO 19079
determine the network protocols to support reachability at a global IPv6 address for Wireless Sensor
Networks (WSNs) based on the IEEE 802.15.4 access medium.
CALM compliant networks (both in-vehicle and off-vehicle) are expected to interact with each other
to seamlessly exchange information. This should be true also for information retrieved from WSN
to be dispatched to any ITS-Station. As WSNs are largely based on low-cost Component of The Shelf
(COTS), IETF has started the standardization of a set of protocols at network and facility layer suited
for constrained devices (in terms of capability of processing, storage or communication) based on low-
rate wireless personal area networks (LR-WPANs) technologies. An important candidate at application
layer in this sense is the IETF Constrained Application Protocol (CoAP) (IETF RFC 7252), an optimized
Representational State Transfer (REST) protocol built on top of the UDP transport protocol, and
implementing a subset of HTTP specifications. This document specifies some facility protocols by
leveraging the reachability of the WSN nodes guaranteed by the adoption of 6LoWPAN at the Network
Layer, and describes how to use CoAP protocol specified by IETF in the context of C-ITS.
For a general introduction to CALM architecture, IPv6 networking and 6LoWPAN networking, the
reader is referred to ISO 21217, ISO 21210 and ISO 19079, respectively.
© ISO 2016 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 19080:2016(E)
Intelligent transport systems — Communications access
for land mobiles (CALM) — CoAP facility
1 Scope
This document describes the CoAP facilities between two or more ITS stations communicating over the
global internet communication network.
It is assumed that the reader is familiar with IETF specifications found in request for comments (RFCs)
of individual CoAP and 6LoWPAN protocol blocks used within this document. This document does
not define a new protocol, a new exchange of messages at the CoAP layer, or new data structures. It
defines how protocols standardized by IETF are combined so that ITS stations can communicate with
one another using CoAP. Procedures defined to share information between the CoAP layer and other
components of the ITS station architecture are defined in ISO 24102 series (Management). In addition
to the requirements specified within this document, a number of notes and examples are provided to
illustrate CoAP main facilities.
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 21217:2014, Intelligent transport systems — Communications access for land mobiles (CALM) —
Architecture
1)
ISO 24102-6 , Intelligent transport systems — Communications access for land mobiles (CALM) — ITS
station management — Part 6: Path and flow management
IETF RFC 6690, The Constrained RESTful Environments (CoRE) Link Format
IETF RFC 7252:2014, The Constrained Application Protocol (CoAP)
IETF RFC 7641, Observing Resources in the Constrained Application Protocol (CoAP)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 19079, ISO 21210, ISO 21217,
ISO 21218, ISO 24102-3 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
NOTE Most of the definitions are taken from IETF RFC 7252, IETF RFC 7228 and IETF RFC 6690.
3.1
ITS-S CoAP node
device/node that implements CoAP protocol
[SOURCE: IETF RFC 7252]
1) To be published.
© ISO 2016 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO 19080:2016(E)

3.2
ITS-S CoAP Endpoint
entity participating in the CoAP protocol
Note 1 to entry: Colloquially, an endpoint lives on a “node”, although “host” would be more consistent with
Internet standards usage, and is further identified by transport-layer multiplexing information that can include a
UDP port number and a security association.
[SOURCE: IETF RFC 7252]
3.3
ITS-S CoAP Client
originating endpoint of a request; the destination endpoint of a response
[SOURCE: IETF RFC 7252]
3.4
ITS-S Server
destination endpoint of a request; the originating endpoint of a response
[SOURCE: IETF RFC 7252]
3.5
confirmable message
message requiring an acknowledgement
Note 1 to entry: These messages are called “confirmable”. When no packets are lost, each confirmable message
prompts exactly one return message of type acknowledgement or type reset.
[SOURCE: IETF RFC 7252]
3.6
non-confirmable message
message not requiring an acknowledgement
Note 1 to entry: This is particularly true for messages that are repeated regularly for application requirements,
such as repeated readings from a sensor.
[SOURCE: IETF RFC 7252]
3.7
acknowledgement message
message acknowledging that a specific confirmable message arrived
Note 1 to entry: By itself, an acknowledgement message does not indicate success or failure of any request
encapsulated in the confirmable message.
[SOURCE: IETF RFC 7252]
3.8
reset message
message indicating that a specific message (confirmable or non-confirmable) was received, but some
context is missing to properly process it
Note 1 to entry: This condition is usually caused when the receiving node has rebooted and has forgotten some
state that would be required to interpret the message. Provoking a reset message (e.g. by sending an empty
confirmable message) is also useful as an inexpensive check of the aliveness of an endpoint (“CoAP ping”).
[SOURCE: IETF RFC 7252]
2 © ISO 2016 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 19080:2016(E)

3.9
subject
resource in the namespace of an ITS-S CoAP server
Note 1 to entry: The state of the resource can change over time, ranging from infrequent updates to continuous
state transformations.
[SOURCE: IETF RFC 7641]
3.10
observer
ITS-S CoAP client that is interested in having a current representation of the resource at any given time
[SOURCE: IETF RFC 7641]
4 Symbols and abbreviated terms
For the purposes of this document, symbols and abbreviated terms in ISO 21210, ISO 21217, IETF
RFC 4944, IETF RFC 6282 apply.
5 Requirements
5.1 Categories
Clause 5 explains the relationship between the four categories of the requirements.
— The first category (see 5.2) contains requirements applying to all ITS-S CoAP nodes and it specifies
requirements that are applicable to the different types of CoAP nodes in each ITS sub-system.
— The second category (see 5.3) contains the requirements that define the CoAP functional modules
that are mandatory for the implementation of “ITS-S CoAP nodes”. Two different modules are
detailed.
— The third category (see 5.4) contains optional features and functions specified as one of the
functional modules of the CoAP protocol block. These optional features could be combined to realize
a set of ITS-S architecture depending on the specific application.
— The fourth category (see 5.5) contain requirements defining which of the CoAP functional modules
specified in 5.3 and 5.4 are combined for each particular “ITS-S CoAP node” specified in 5.3.
© ISO 2016 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO 19080:2016(E)

Figure 1 — Scope of this document within the architecture of an ITS-S
5.2 ITS-S nodes implementing CoAP
5.2.1 General
As CoAP was designed according to the REST architecture, it thus exhibits functionality similar to that
of the HTTP protocol, it will support web style transactions originated or directed to 6LoWPAN nodes
in ITS stations (ISO 19079).
4 © ISO 2016 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 19080:2016(E)

For a better understanding of CoAP, the terminologies are specified in IETF RFC 7252 and the
“Terminologies behind constrained-node networks” in IETF RFC 7228. These documents shall serve as
the normative references for how to apply “CoAP” to ITS CALM.
Figure 2 — CoAP based subsystem
A station implementing CoAP (in a PAN) is pictorially represented in Figure 2 together with its
connections with other CoAP nodes in the same 6LoWPAN (IETF RFC 4919, IETF RFC 4944, IETF
RFC 6282), eventually exploiting the multi-hop forwarding module featured by ad-hoc routers. The
forwarding service established with peers of the Internet is also shown leveraging the functionality
provided by a “6LoWPAN Border Router” equipped with at least two MAC interfaces.
The CoAP-based ITS stations can notably take part in the “road-side” and “vehicular” subsystems as
pictorially shown in ISO 21217:2014, Figure 16, although this protocol instantiated at the facility layer
does not depend on the actual network topology. The other scenarios will not be discussed in this
document due to the reduced impact they provide on the C-ITS general architecture.
© ISO 2016 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO 19080:2016(E)

Although CoAP is a UDP-dependent standard applicable to every layer-3 protocol, its most popular
implementation is the one connected with 6LoWPAN. The latter will be considered in the remainder of
this document.
5.2.2 Requirements on all ITS-S CoAP nodes
This subclause specifies the functional requirements of all ITS stations implementing CoAP in an “ITS-S
6LoWPAN” as shown in the scenario of Figure 3. This figure depicts two possible ITS-S subsystems
that utilize CoAP protocol to realize communication between constrained devices, e.g. WSNs and the
internet.
An “ITS-S CoAP node” shall implement CoAP in accordance with IETF RFC 7252 and IETF RFC 6690.
Figure 3 — Example CoAP nodes in ITS
ITS-S CoAP nodes could be used in Traffic variable message systems (VMSs), ITS weather stations and
transportation and logistics applications. The network of wireless sensor nodes deployed in these
categories shall be prescribed as ITS-S CoAP nodes.
6 © ISO 2016 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 19080:2016(E)

Figure 4 — Extended road-side sub-systems (ISO 21210 and ISO 21217) including CoAP
Figure 5 — Extended vehicular ITS sub-system including CoAP
In all setups (see Figures 4 and 5), the deployment will include a set of ITS CoAP nodes addressable
from the internet through a ITS 6LoWPAN border router (or mobile router in the case of vehicles), as
specified in ISO 19079.
5.3 CoAP functional modules
5.3.1 General
This subclause specifies what CoAP functions are required by an ITS-S CoAP node. These functions are
put together in three different modules. 5.5 specifies which of these modules are required for each type
of ITS-S CoAP node specified in 5.2. This separation into modules simplifies the specification of CoAP
functions.
© ISO 2016 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO 19080:2016(E)

Figure 6 illustrates how these functional modules are mapped to the CoAP facilities functional block of
the ITS station reference architecture.
Figure 6 — CoAP functional modules
5.3.2 CoAP management module
5.3.2.1 General
The CoAP management module shall implement some functions defined in the CoRE Link Format (IETF
RFC 6690) and the CoAP (IETF RFC 7252).
These functions are used by an ITS-S CoAP node to enable resource discovery, resource directory and
resource observation of the available resources on an ITS-S CoAP node.
With the aim of offering generic services performing similar common actions at the ITS-S facilities layer
to all applications, as standardized in ISO 21217 the CoAP management module shall:
a) request default settings from the ITS station management entity through the MF-SAP using MF-
COMMAND.request instructions as specified in ISO 24102-6;
b) use the procedures defined in ISO 17429 for the exchange of information between the ITS station
facilities layer and the ITS-S application processes.
5.3.2.2 Message formatting
For clarity, the mechanism of message formatting is included below.
8 © ISO 2016 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 19080:2016(E)

Message Formatting: The CoAP message definition used in an ITS-S system shall be encoded in a
simple binary format, which by default are transported over UDP i.e., every CoAP message occupies the
data section of one UDP datagram. The CoAP message starts with a fixed-size of 4-byte header that is
followed by a variable-length token value, which can be between 0 and 8 byte long. Following the Token
value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally
followed by a payload that takes up the rest of the datagram. Figure 6 shows an example message
format (see IETF RFC 7252).
Figure 7 — Message format
The fields in the header are defined as follows:
Version (Ver): 2-bit unsigned integer indicates the CoAP version number. Implementations of this
specification MUST set this field to 1 (01 binary). Other values are reserved for future versions.
Messages with unknown version numbers MUST be silently ignored.
Type (T): 2-bit unsigned integer indicates if this message is of type Confirmable (0) (CON), Non-
confirmable (1) (NON), Acknowledgement (2) (ACK), or Reset (3) (RST). The semantics of these message
types are defined in IETF RFC 7252:2014, Clause 4.
Token Length (TKL): 4-bit unsigned integer, indicates the length of the variable-length Token field (0-8
bytes). Lengths 9-15 are reserved, MUST NOT be sent, and MUST be processed as a message format error.
Code: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least
significant bits), documented as “c.dd” where “c” is a digit from 0 to 7 for the 3-bit subfield and “dd” are
two digits from 00 to 31 for the 5-bit subfield. The class can indicate a request (0), a success response
(2), a client error response (4), or a server error response (5). (All other class values are reserved.) As
a special case, Code 0.00 indicates an empty message. In case of a request, the code field indicates the
request method; in case of a response, a response code. The semantics of requests and responses are
defined in IETF RFC 7252:2014, Clause 5.
Message ID: 16-bit unsigned integer in network byte order. Used to detect message duplication and
to match messages of type acknowledgement/reset to messages of type confirmable/non-confirmable.
The rules for generating a message ID and matching messages are defined in IETF RFC 7252:2014,
Clause 4.
5.3.2.3 Resource Discovery
With this service an ITS-S CoAP node will discover on-line resources using the CoRE Link Format
(IETF RFC 6690). An ITS-S CoAP node (end-point) could be implemented either as a server or a client
node. This CoAP node shall implement a resource discovery as either a unicast or multicast. When an
ITS-S CoAP server node’s IP address is known unicast discovery is used to locate the entry point to the
interested resource. This function is performed using a GET to “/.well-known/core” (shown in Figure 8)
on the ITS-S server node, which returns a payload in the CoRE Link Format. An ITS-S CoAP node as a
© ISO 2016 – All rights reserved 9

---------------------- Page: 14 ----------------------
ISO 19080:2016(E)

client would then match the appropriate URI, resource type, interface description, content-type and
media type, etc. with the specific directives of the final application.
A multicast resource discovery is useful if the ITS-S CoAP node needs to discover a resource within
a limited scope, which supports a multicast. The GET request to “/.well-known/core” on the ITS-S
server node is made. Same as with the unicast, the multicast resource discovery is located based on the
resource type, interface description and other ITS-S specific attributes. An example implementation of
a CoAP server and client targeted for logistic transportation is described in Reference [12].
Figure 8 — Resource discovery
To increase interoperability in a CoRE environment, a CoAP endpoint shall support the CoRE Link Format
of discoverable resources as described in IETF RFC 6690, except where fully manual configuration is
desired.
5.3.2.4 Resource observe
The ITS-S CoAP node shall implement the CoAP core protocol specified in IETF RFC 7641 with a
mechanism for an ITS-S CoAP client to “observe” a resource on an ITS-S CoAP server. The ITS-S CoAP
client retrieves a representation of the resource and requests this representation be updated by the
ITS-S server as long as the ITS-S client is interested in the resource.
10 © ISO 2016 – All rights reserved

---------------------- Page: 15 ----------------------
ISO 19080:2016(E)

Figure 9 — Observer design pattern
As shown in Figure 9, the observer design pattern shall be realized in an ITS-S CoAP network as follows:
Subject: In the context of CoAP, the subject is a resource in the namespace of an ITS-S CoAP server.
The state of the resource can change over time, ranging from infrequent updates to continuous state
transformations.
Observer: An observer is an ITS-S CoAP client that is interested in having a current representation of
the resource at any given time.
Registration: An ITS-S CoAP client registers its interest in a resource by initiating an extended GET
request to the server. In addition to returning a representation of the target resource, this request
causes the ITS-S CoAP server to add the client to the list of observers of the resource.
Notification: Whenever the state of a resource changes, the ITS-S CoAP server shall notify each client in
the list of observers of the resource. Each notification is an additional CoAP response sent by the ITS-S
CoAP server in response to the GET request and this includes a complete, updated representation of the
new resource state.
NOTE Responses sent by ITS-S CoAP server: As notifications are just additional responses sent by the
ITS-S CoAP server in response to a GET request, they are subject to caching as defined in IETF RFC 7252:2014, 5.6
(see 5.5).
5.3.3 CoAP security module
The ITS-S CoAP security module has the same security considerations as described in
IETF RFC 7252:2014, Clauses 9 and 11. Just as HTTP is secured using transport layer security (TLS)
over TCP, CoAP is secured using datagram TLS (DTLS) (IETF RFC 6347) over UDP (see Figure 10). DTLS
is TLS with added features to deal with the unreliable nature of the UDP transport.
© ISO 2016 – All rights reserved 11

---------------------- Page: 16 ----------------------
ISO 19080:2016(E)

NOTE As shown in IETF RFC 7252.
Figure 10 — DTLS-secured CoAP
In some ITS constrained nodes (limited flash and/or RAM) and networks (limited bandwidth or high
scalability requirements), and depending on the specific cipher suites in use, all modes of DTLS may
not be applicable. Some DTLS cipher suites can add significant implementation complexity, as well as
some initial handshake overhead needed when setting up the security association. Once the initial
handshake is completed, DTLS adds a limited per-datagram overhead of approximately 13 bytes, not
including any initialization vectors/nonce (e.g. 8 bytes with TLS_PSK_WITH_AES_128_CCM_8, see IETF
RFC 6655), integrity check values and padding required by the cipher suite. Whether the use of a given
mode of DTLS is applicable for an ITS CoAP-based application should be carefully weighed considering
the specific cipher suites that may be applicable, whether the session maintenance makes it compatible
with application flows, and whether sufficient resources are available on the constrained nodes and for
the added network overhead.
The “/.well-known/core” resource MAY be protected, e.g. using datagram transport layer security
(DTLS) following the approach of IETF RFC 6347, when hosted on an ITS-S CoAP server as per
IETF
...

DRAFT INTERNATIONAL STANDARD
ISO/DIS 19080
ISO/TC 204 Secretariat: ANSI
Voting begins on: Voting terminates on:
2015-10-06 2016-01-06
Intelligent Transport Systems — Communications access
for land mobiles (CALM) - CoAP facility
Titre manque
ICS: 35.240.60; 03.220.20
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/DIS 19080:2015(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO 2015

---------------------- Page: 1 ----------------------
ISO/DIS 19080
ISO/DIS 19080:2015(E)

Contents Page
Foreword . iv
Introduction . iv
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms . 3
5 Requirements . 3
5.1 Categories . 3
5.2 ITS-S nodes implementing CoAP . 4
5.2.1 General . 4
5.2.2 Requirements on all ITS-S CoAP nodes . 5
5.3 CoAP functional modules . 7
5.3.1 General . 7
5.3.2 CoAP management module . 8
5.3.3 CoAP security module . 12
5.4 Optional module . 13
5.4.1 General . 13
5.4.2 CoAP/HTTP Interoperability . 13
5.4.3 Resource Directory . 15
5.4.4 Blockwise Transfers . 17
5.5 Modules implemented in ITS-S CoAP nodes . 17
5.5.1 General . 17
5.5.2 ITS-S CoAP Full Function Device modules . 17
5.5.3 ITS-S CoAP Reduced Function Device modules . 18
6 Bibliography . 18
COPYRIGHT PROTECTED DOCUMENT
© ISO 2015, Published in Switzerland
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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
© ISO 2015 – All rights reserved iii
[e-mail]
www.iso.org
ii © ISO 2015 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/DIS 19080
Contents Page
Foreword . iv
Introduction . iv
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms . 3
5 Requirements . 3
5.1 Categories . 3
5.2 ITS-S nodes implementing CoAP . 4
5.2.1 General . 4
5.2.2 Requirements on all ITS-S CoAP nodes . 5
5.3 CoAP functional modules . 7
5.3.1 General . 7
5.3.2 CoAP management module . 8
5.3.3 CoAP security module . 12
5.4 Optional module . 13
5.4.1 General . 13
5.4.2 CoAP/HTTP Interoperability . 13
5.4.3 Resource Directory . 15
5.4.4 Blockwise Transfers . 17
5.5 Modules implemented in ITS-S CoAP nodes . 17
5.5.1 General . 17
5.5.2 ITS-S CoAP Full Function Device modules . 17
5.5.3 ITS-S CoAP Reduced Function Device modules . 18
6 Bibliography . 18

© ISO 2015 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/DIS 19080
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has
been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 19080 was prepared by Technical Committee ISO/TC 204, Intelligent Transport Systems,
Subcommittee SC , .
This second/third/. edition cancels and replaces the first/second/. edition (), [clause(s) / subclause(s) /
table(s) / figure(s) / annex(es)] of which [has / have] been technically revised.
iv © ISO 2015 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/DIS 19080
Introduction
The set of International Standards that collectively refer to CALM (Communications Access for Land Mobile)
focus on the specification of open interfaces regarding the functionality required by all relevant layers and
entities of a Standard ITS station reference architecture.
These Standards are designed to allow interoperable instantiations of ITS stations, which are based on the
concept of abstracting applications and services from the underlying communication layers. This abstraction
makes the ITS station architecture described herein ideally suited to the development and deployment of
Cooperative ITS applications and services.
The set of CALM standards include specifications for security in ITS communications, ITS-S management,
distributed ITS-S implementations, legacy communication media interfaces, legacy application interfaces,
and new communication interfaces specifically designed for ITS applications such as those designed for
safety of both life and property.
The fundamental advantage of the CALM concept with respect to traditional systems is the ability to support
vertical handovers between the various media that can be included in a CALM system. Handover
mechanisms are defined within the CALM architecture International Standard (ISO 21217), the CALM
medium service access points International Standard (ISO 21218) and the CALM communication and station
management International Standard (ISO 24102).
At network layer, CALM IPv6 networking ISO 21210 and CALM 6LoWPAN networking ISO 19079 determine
the network protocols to support reachability at a global IPv6 address for Wireless Sensor Networks (WSNs)
based on the IEEE 802.15.4 access medium.
CALM compliant networks (both in-vehicle and off-vehicle) are expected to interact with each other to
seamlessly exchange information. This should be true also for information retrieved from WSN to be
dispatched to any ITS-Station. As WSNs are largely based on low-cost Component of The Shelf (COTS),
IETF has started the standardization of a set of protocols at network and facility layer suited for constrained
devices (in terms of capability of processing, storage or communication) based on low-rate wireless personal
area networks (LR-WPANs) technologies. An important candidate at application layer in this sense is the
IETF Constrained Application Protocol (CoAP) (IETF RFC 7228 The Terminologies for Constrained-
node network
IETF RFC 4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals
IETF RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
IETF RFC 6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based
Networks
IETF RFC 6690 The Constrained RESTful Environments (CoRE) Link Format
IETF RFC 7252), an optimized Representational State Transfer (REST) protocol built on top of the UDP
transport protocol, and implementing a subset of HTTP specifications. This Technical document specifies
some facility protocols by leveraging the reachability of the WSN nodes guaranteed by the adoption of
6LoWPAN at the Network Layer, and describes how to use CoAP protocol specified by IETF in the context
of C-ITS.
For a general introduction to CALM architecture, IPv6 networking and 6LoWPAN networking the reader is
referred to ISO 21217, ISO 21210 and ISO 19079 respectively.
© ISO 2015 – All rights reserved v

---------------------- Page: 5 ----------------------
DRAFT INTERNATIONAL STANDARD ISO/DIS 19080

1 Scope
This Technical document described the CoAP facilities between two or more ITS stations
communicating over the global Internet communication network.
It is assumed that the reader is familiar with IETF specifications found in "Request for Comments"
(RFCs) of individual CoAP and 6LoWPAN protocol blocks used within this Technical Specification.
This Technical Specification does not define a new protocol, a new exchange of messages at the
CoAP layer, or new data structures. It defines how protocols standardized by IETF are combined so
that ITS stations can communicate with one another using CoAP. Procedures defined to share
information between the CoAP layer and other components of the ITS station architecture are
defined in ISO 24102 (Management). In addition to the requirements specified within this Technical
Specification, a number of notes and examples are provided to illustrate CoAP main facilities.
2 Normative references
The following referenced documents are indispensable for the application 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 21210:2012, Intelligent transport systems — Communications access for land
mobiles (CALM) — IPv6 Networking
ISO 21217:2014, Intelligent transport systems — Communications access for land
mobiles (CALM) — Architecture
ISO 21218:2013, Intelligent transport systems — Communications access for land
mobiles (CALM) — Access technology support
ISO 24102-3:2013, Intelligent transport systems — Communications access for
land mobiles (CALM) — Management – Service Access Points
ISO 19079, Intelligent transport systems — Communications access for land
mobiles (CALM) — 6LoWPAN Networking
IETF RFC 7228 The Terminologies for Constrained-node network
IETF RFC 4919 IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
IETF RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
IETF RFC 6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-
Based Networks
IETF RFC 6690 The Constrained RESTful Environments (CoRE) Link Format
IETF RFC 7252 The Constrained Application Protocol (CoAP)
IETF RFC 6347 Datagram Transport Layer Security (DTLS)
© ISO 2015 – All rights reserved 1

---------------------- Page: 6 ----------------------
IETF RFC 6655 AES-CCM Cipher Suites for Transport Layer Security (TLS)
3 Terms and definitions
For the purposes of this document, the terms and definitions in ISO 19079, ISO 21210:2012, ISO
21217:2014, ISO 21218:2013 and ISO 24102-3:2013 and the following apply.
NOTE Most of the definitions are taken from IETF RFC 7228 The Terminologies for
Constrained-node network
IETF RFC 4919 IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
IETF RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
IETF RFC 6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-
Based Networks
IETF RFC 6690 The Constrained RESTful Environments (CoRE) Link Format
IETF RFC 7252, Error! Reference source not found.and Error! Reference source not found.
ITS-S CoAP node
device/node that implements CoAP protocol (IETF RFC 7228 The Terminologies for
Constrained-node network
IETF RFC 4919 IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
IETF RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
IETF RFC 6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-
Based Networks
IETF RFC 6690 The Constrained RESTful Environments (CoRE) Link Format
IETF RFC 7252)
ITS-S CoAP Endpoint
entity participating in the CoAP protocol
NOTE Colloquially, an endpoint lives on a "Node", although "Host" would be more consistent with Internet
standards usage, and is further identified by transport-layer multiplexing information that can include a UDP port
number and a security association.
ITS-S CoAP Client
originating endpoint of a request; the destination endpoint of a response
ITS-S Server
destination endpoint of a request; the originating endpoint of a response
Confirmable message
message requiring an acknowledgement.
2 © ISO 2015 – All rights reserved

---------------------- Page: 7 ----------------------
NOTE These messages are called "Confirmable". When no packets are lost, each Confirmable message
prompts exactly one return message of type Acknowledgement or type Reset.
Non-confirmable message
message not requiring an acknowledgement
NOTE This is particularly true for messages that are repeated regularly for application requirements, such
as repeated readings from a sensor.
Acknowledgement message
message acknowledging that a specific Confirmable message arrived
NOTE By itself, an Acknowledgement message does not indicate success or failure of any request
encapsulated in the Confirmable message.
Reset message
message indicating that a specific message (Confirmable or Non-confirmable) was received, but
some context is missing to properly process it
NOTE This condition is usually caused when the receiving node has rebooted and has forgotten some
state that would be required to interpret the message. Provoking a Reset message (e.g., by sending an Empty
Confirmable message) is also useful as an inexpensive check of the aliveness of an endpoint ("CoAP ping").
Subject
a resource in the namespace of an ITS-S CoAP server
NOTE The state of the resource can change over time, ranging from infrequent updates to continuous
state transformations.
Observer
ITS-S CoAP client that is interested in having a current representation of the resource at any given
time
4 Symbols and abbreviated terms
Symbols and abbreviated terms used in this Technical Specification are listed below. Reference
should also be made to ISO 19079, ISO 21210, ISO 21217, ISO 21218, ISO 24102, IETF RFC
4944, IETF RFC 6282, IETF RFC 7228 and IETF RFC 6775.
5 Requirements
5.1 Categories
Clause 6 explains the relationship between the four categories of the requirements.
 The first category (see 6.2) contains requirements applying to all ITS-S CoAP nodes and it
specifies requirements that are applicable to the different types of CoAP nodes in each ITS sub-
system.
 The second category (see 6.3) contains the requirements that define the CoAP functional
modules that are mandatory for the implementation of 'ITS-S CoAP nodes'. Two different
modules are detailed.
 The third category (see 6.4) contains optional features and functions specified as one of the
functional modules of the CoAP protocol block. These optional features could be combined to
realize a set of ITS-S architecture depending on the specific application.
© ISO 2015 – All rights reserved 3

---------------------- Page: 8 ----------------------
 The fourth category (see 6.5) contain requirements defining which of the CoAP functional
modules specified in 6.3 and 6.4 are combined for each particular 'ITS-S CoAP node' specified
in 6.3;

Figure 1: Scope of this TS within the architecture of an ITS-S
5.2 ITS-S nodes implementing CoAP
5.2.1 General
As CoAP was designed according to the REST architecture, it thus exhibits functionality similar to
that of the HTTP protocol, it will support web style transactions originated or directed to 6LoWPAN
nodes in ITS stations (ISO 19079).
For a better understanding of CoAP, the terminologies are specified in IETF RFC 7252 and the
'Terminologies behind constrained-node networks' in IETF RFC 7228. These documents shall serve
as the normative references for how to apply 'CoAP' to ITS CALM.

4 © ISO 2015 – All rights reserved

---------------------- Page: 9 ----------------------
Figure 2: A CoAP based subsystem
A station implementing CoAP (in a PAN) is pictorially represented in Figure 2 together with its’
connections with other CoAP nodes in the same 6LoWPAN (IETF RFC 4919, 4944, 6282),
eventually exploiting the multi-hop forwarding module featured by ad-hoc routers. The forwarding
service established with peers of the Internet is also shown leveraging the functionality provided by a
“6LoWPAN Border Router” equipped with at least two MAC interfaces.
The CoAP-based ITS stations can notably take part in the “Road-side” and “Vehicular” subsystems
as pictorially shown in ISO 21217:2012 Figure 16 although this protocol instantiated at the facility
layer does not depend on the actual network topology. The other scenarios will not be discussed in
this Technical Specification due to the reduced impact they provide on the C-ITS general
architecture.
Although CoAP is a UDP-dependent standard applicable to every layer-3 protocol, its most popular
implementation is the one connected with 6LoWPAN. The latter will be considered in the remainder
of this document.
5.2.2 Requirements on all ITS-S CoAP nodes
This sub-clause specifies the functional requirements of all ITS stations implementing CoAP in an
'ITS-S 6LoWPAN' as shown in the scenario of Figure 3. This figure depicts two possible ITS-S
subsystems that utilize CoAP protocol to realize communication between constrained devices e.g.
WSNs and the internet.
An 'ITS-S CoAP node' shall implement CoAP in accordance with IETF RFC 7252 and IETF RFC
6690.
© ISO 2015 – All rights reserved 5

---------------------- Page: 10 ----------------------
Figure 3: An example CoAP nodes in ITS
ITS-S CoAP nodes could be used in Traffic variable message systems (VMSs), ITS weather
stations, and Transportation and Logistics applications. The network of wireless sensor nodes
deployed in these categories shall be prescribed as ITS-S CoAP nodes.

Figure 4: The extended road-side sub-systems (ISO 21210 and ISO 21217) including CoAP
6 © ISO 2015 – All rights reserved

---------------------- Page: 11 ----------------------
Figure 5: The extended Vehicular ITS sub-system including CoAP
In all setup’s (see Figures 4 and 5) the deployment will include a set of ITS CoAP nodes
addressable from the Internet through an ITS 6LoWPAN Border Router (or Mobile Router in the
case of vehicles), as specified in ISO 19079.
5.3 CoAP functional modules
5.3.1 General
This sub-clause specifies what CoAP functions are required by an ITS-S CoAP node. These
functions are put together in three different modules. Section 6.5 specifies which of these modules
are required for each type of ITS-S CoAP node specified in 6.2. This separation into modules
simplifies the specification of CoAP functions.
Figure 6 illustrates how these functional modules are mapped to the CoAP facilities functional block
of the ITS station reference architecture.
© ISO 2015 – All rights reserved 7

---------------------- Page: 12 ----------------------
Figure 6: CoAP functional modules
5.3.2 CoAP management module
5.3.2.1 General
The CoAP management module shall implement some functions defined in the
CoRE Link Format (Error! Reference source not found.) and the CoAP (IETF
RFC 7228 The Terminologies for Constrained-node network
IETF RFC 4919 IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
IETF RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
IETF RFC 6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-
Based Networks
IETF RFC 6690 The Constrained RESTful Environments (CoRE) Link Format
IETF RFC 7252). These functions are used by an ITS-S CoAP node to enable
Resource Discovery, Resource Directory and Resource Observation of the
available resources on an ITS-S CoAP node.
5.3.2.2 Message formatting
For clarity, the mechanism of message formatting is included in the Note below.
8 © ISO 2015 – All rights reserved

---------------------- Page: 13 ----------------------
NOTE Message Formatting: The CoAP message definition used in an ITS-S system shall be encoded in
a simple binary format, which by default are transported over UDP i.e., every CoAP message occupies the data
section of one UDP datagram. The CoAP message starts with a fixed-size of 4-byte header that is followed by a
variable-length token value, which can be between 0 and 8 byte long. Following the Token value comes a
sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload
that takes up the rest of the datagram. Figure 6 shows an example message format (see IETF RFC 7252).
   0          1          2          3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Ver| T | TKL |   Code   |     Message ID      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Token (if any, TKL bytes) .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Options (if any) .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1 1 1 1 1 1 1 1|  Payload (if any) .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Message Format
The fields in the header are defined as follows:
Version (Ver): 2-bit unsigned integer indicates the CoAP version number.
Implementations of this specification MUST set this field to 1 (01 binary). Other
values are reserved for future versions. Messages with unknown version numbers
MUST be silently ignored.
Type (T): 2-bit unsigned integer indicates if this message is of type Confirmable (0)
(CON), Non-confirmable (1) (NON), Acknowledgement (2) (ACK), or Reset (3)
(RST). The semantics of these message types are defined in Section 4 of IETF
RFC 7252.
Token Length (TKL): 4-bit unsigned integer, indicates the length of the variable-
length Token field (0-8 bytes). Lengths 9-15 are reserved, MUST NOT be sent, and
MUST be processed as a message format error.
Code: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-
bit detail (least significant bits), documented as "c.dd" where "c" is a digit from 0 to 7
for the 3-bit subfield and "dd" are two digits from 00 to 31 for the 5-bit subfield. The
class can indicate a request (0), a success response (2), a client error response (4),
or a server error response (5). (All other class values are reserved.) As a special
case, Code 0.00 indicates an Empty message. In case of a request, the Code field
indicates the Request Method; in case of a response, a Response Code. The
semantics of requests and responses are defined in Section 5 of IETF RFC 7252.
Message ID: 16-bit unsigned integer in network byte order. Used to detect
message duplication and to match messages of type Acknowledgement/Reset to
messages of type Confirmable/Non-confirmable. The rules for generating a
Message ID and matching messages are defined in Section 4 of IETF RFC 7252.
5.3.2.3 Resource Discovery
With this service an ITS-S CoAP node will discover on-line resources using the CoRE Link Format
(Error! Reference source not found.). An ITS-S CoAP node (end-point) could be impleme
...