Network Working Group A. Minaburo
Internet-Draft Acklio
Intended status: Informational L. Toutain
Expires: April 30, 2018 Institut Mines Telecom Atlantique
October 27, 2017

CoAP Time Scale Option


SCHC compression mechanism for LPWAN network enables IPv6 on devices connected to a constrained network (LPWAN). They can communicate with a CoAP server located anywhere in the Internet. LPWAN network characteristics limits the number of exchanges and may impose a long RTT. The CoAP server must be aware of these properties to manage correctly requests. The Time Scale option allows a device to inform a CoAP server of the duration the message ID value should be kept in memory to manage correctly message duplication.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 30, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. CoAP Message ID

Constraint Application Protocol (CoAP) [RFC7252] implements a simple reliable transport mechanism based on ARQ. Each CoAP message contains a 16 bit Message ID (noted afterward MID). A client selects a MID in a CON message and expects an ACK message containing the same MID value. A timer makes the client resend the request if no ACK is received during a pre-defined period.

            client                              server
              |           CON MID = XXXX          |
              |---------------------------------->|=> process
 EXCHANGE   ^ |           ACK MID = XXXX          |  ^
 LIFETIME   | |                  <----------------|  | EXCHANGE
            | |                                   |  | LIFETIME
  XXXX      | |           CON MID = XXXX          |  |
  cannot    | |---------------------------------->|  | XXXX in 
  be reused | |           ACK MID = XXXX          |  | memory
            | |<----------------------------------|  |
            | |                                   |  |
            v |                                   |  v
 XXXX can be  .                                   .
 reused       .                                   .
              .                                   .
              |           CON MID = XXXX          |
              |---------------------------------->|=> process
            ^ |           ACK MID = XXXX          |  ^ 
            | |<----------------------------------|  |
              .                                   .

Figure 1: Delayed transmission.

To avoid a second process of duplicated requests by the server, a list of messages ID already acknowledged must be maintained for a period of time. If the message ID is already in the list, the message is just acknowledged and not processed by upper layer. Therefore, the client cannot use this MID value in another request during the same period of time.

[RFC7252] calls the period a MID is assigned to a request the EXCHANGE_LIFETIME. The value is based on the worst case scenario taking into account the propagation time, the number of retransmissions and the processing time. The default value for EXCHANGE_LIFETIME is set to 247 seconds for MAX_RTT of 202 seconds.

2. LPWAN networks

Low Power Wide Area Network (LPWAN) family regroups networks dedicated to the Internet of Things. They provide a large coverage with a limited energy consumption. They mostly use the license-free ISM band. The [I-D.ietf-lpwan-overview] gives an overview of the technology and the star oriented topology architecture. A Network Gateway (NGW) is at the interconnection between the LPWAN and the Internet network.

To ensure fairness among nodes, regulation imposes a duty cycle. In practice, with a 1% duty cycle, a node sending a message of s seconds must wait 99 x s seconds before sending another message. For instance, in some technologies sending a 50 bytes message takes 2 seconds, forcing a silence of 198 seconds.

The device sleeps most of the time to preserve energy. If a device can use the uplink channel at any time, downlink channel is generally available during a short receiving window following the message emission. Therefore a message sent to a device out of this receiving window will be lost. Network Gateways are aware of this restriction and buffers downlink messages until an uplink message is received which opens the receiving window.

     client on LPWAN         NGW               server
            |                 |                 |
        ^   |---------------------------------->| CON MID = 1
        |   |                 |                 |
 1 hour |   |         delayed H<----------------| ACK MID = 1
        |   |                 H                 |
        |   |                 H                 |
        |   |                 H                 |
        v   |---------------------------------->| CON MID = 2
ACK MID = 1 |<----------------|                 |
            |                 |                 |         
            v                 v                 v

Figure 2: Delayed transmission.

     client on LPWAN         NGW               server
            |   CON MID = 1   |                 |
 Timer  -   |---------------------------------->| => process 
        |   |         delayed H<----------------| ^  
        |   |                 H   ACK MID = 1   | | EXCHANGE
        |   |                 H                 | v LIFETIME
        |   |   CON MID = 2   H                 |
        |   |---------------------------------->| 
        |   |       X---------|                 |         
        |   |                 |                 |
        |   |   CON MID = 1   |                 |
Expire  O   |---------------------------------->| => process
            |                 |<----------------| 
            .                 .   ACK MID = 1   .
            .                 .                 .

Figure 3: Retransmission.

Figure 2 illustrates this. A CoAP client sends a request every hour. Even if the server replies immediately, the answer may be buffered by the Network GW until an new uplink message is sent. In that case, the client will only receive the answer after one hour when the next request is sent. The RTT is influenced by the message periodicity and the EXCHANGE_LIFTEIME value can be computed locally by client to dimension its timers. Figure 3, a retransmission will be viewed as a new request.

The Time Scale option, added into all the CoAP requests, informs the server of the duration a message ID should be memorized into the server and therefore the duration during which a client should not reuse the same message ID for a new request. This way, the server can adapt its behavior to different environments.

It is important to notice that this option will not contribute to an DoS attack. This option does not increase the number of message ID memorized by the server. In fact, the Time Scale option can be viewed as a contract between the client and the server, which means that the client will send a reasonable number of request during that period. The number of memorized message ID is independent of the duration of the exchange but linked to the number a simultaneous request a client can send. If a client is sending a number of request larger than expected, they can be easily discarded by the server.

3. Timescale Option

   | Number | C | U | N | R |   Name      | Format | Length | Default |
   |   259  | X |   |   |   | Time Scale  |  uint  |  1-4   |   3600  |

Figure 4: Time Scale Option.

Timescale is a new CoAP option that tells the server how many seconds the MID should be memorized by the server. This option must be included in all the exchanges coming from a high latency device.

4. Normative References

[I-D.ietf-lpwan-overview] Farrell, S., "LPWAN Overview", Internet-Draft draft-ietf-lpwan-overview-07, October 2017.
[RFC7252] Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014.

Authors' Addresses

Ana Minaburo Acklio 2bis rue de la Chataigneraie 35510 Cesson-Sevigne Cedex, France EMail:
Laurent Toutain Institut Mines Telecom Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex, France EMail:

Table of Contents