Skip to main content

Software Update Experiences for IoT
slides-iotsuws-software-update-experiences-for-iot-00

Slides IAB Workshop on Internet of Things Software Update (iotsuws) Team
Title Software Update Experiences for IoT
Abstract Jimenez and Ocak, Software Update Experiences for IoT
State Active
Other versions plain text
Last updated 2023-02-08

slides-iotsuws-software-update-experiences-for-iot-00



Network Working Group                                         J. Jimenez
Internet-Draft                                                   M. Ocak
Intended status: Informational                                  Ericsson
Expires: December 3, 2016                                  June 01, 2016


                  Software Update Experiences for IoT
                      draft-jimenez-iotsu-soft-exp

Abstract

   This document provides a summary of found problems and possible
   solutions for software upgrades on the constrained space.  Some of
   the issues are still open and should be subject of discussion.
   Ideally some implementation guidelines should be made when using CoAP
   [RFC7252], HTTP [RFC7230] or MQTT as transfer protocols.  The
   sections are purposedly left short as they are open issues that
   should be discussed.

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 http://datatracker.ietf.org/drafts/current/.

   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 December 3, 2016.

Copyright Notice

   Copyright (c) 2016 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
   (http://trustee.ietf.org/license-info) 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



Jimenez & Ocak          Expires December 3, 2016                [Page 1]

Internet-Draft        draft-jimenez-iotsu-soft-exp             June 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Dealing with Sleepy endpoints . . . . . . . . . . . . . . . .   3
   4.  Device Initiated Communication  . . . . . . . . . . . . . . .   3
   5.  Manager Initiated Communication . . . . . . . . . . . . . . .   3
   6.  Delegation on other nodes . . . . . . . . . . . . . . . . . .   4
   7.  Using Multiple Stacks . . . . . . . . . . . . . . . . . . . .   4
   8.  Runtime Discovery . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   10. Informative References  . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In this short paper we try to raise some issues we have found when
   dealing with software upgrades in the IoT domain.  Dealing with
   sleepy endpoints is at Section 3.  The case for device initiated
   communication is on Section 4 and manager initiated on Section 5.
   Delegation on gateways or other nodes is in Section 6.  The use of an
   alternative stack for software upgrades is at Section 7.  A possible
   long-term architecture that enables to do runtime updates on the
   constrained device is at Section 8

2.  Architecture

   We start with the assumption of a device that is constrained but does
   not require gateways for communication as it uses some operator-based
   connectivity (though we do not assume SMS transport).

   Device                                      Manager
   +--------------------+                      +--------------------+
   | CoAP Server/Client |                      | CoAP Server/Client |
   +--------------------+                      +--------------------+
   |        UDP         | +----------------->  |        UDP         |
   +--------------------+                      +--------------------+
   |     IPv4/IPv6      | <-----------------+  |     IPv4/IPv6      |
   +--------------------+                      +--------------------+
   |     4G/NB-IoT      |                      |        ANY         |
   +--------------------+                      +--------------------+

   This simple, generic set up presents several problems, specially when
   dealing with the operator environment.  We enumerate some of them
   below.



Jimenez & Ocak          Expires December 3, 2016                [Page 2]

Internet-Draft        draft-jimenez-iotsu-soft-exp             June 2016


3.  Dealing with Sleepy endpoints

   The fact that devices are sleepy poses several problems for doing
   software updates.  Namely that you do not have a connected endpoint
   most of the time and that therefore the device will have to contact
   the manager or the manager will have to poll the device pretty
   frequently.  The case for polling does not scale and therefore it is
   hardly a solution.

   Nevertheless it is very common to use polling on the constrained
   space since the server has more capabilities and thus can query the
   device providing that there are no NATs or firewalls (See Section 4)

4.  Device Initiated Communication

   The first issue are NATs and Firewalls.  Constrained devices do not
   have the capabilities nor the inclination to punch holes through NATs
   and keep them open, that task has to be delegated elsewhere.

   What we have done in order to overcome this obstacle is to set an
   observation on the device.  Assuming that the device has previously
   registered on a Resource Directory (RD)
   [I-D.ietf-core-resource-directory] that the manager has access to,
   the manager would then observe the status of the device (0:off,
   1:on).  Whenever the device wakes up it will send a notification to
   the manager.  During the time the NAT is open the manager will be
   able to send data through the holes in the NAT.

   D<--M: CoAP GET /Radio_link_status, Token: 0x4a, Observe: 0
   D-->M: 2.05 Content, Token: 0x4a, payload: 1, time: 1464619477
   D-->M: 2.05 Content, Token: 0x4a, payload: 1, time: 1464520998

5.  Manager Initiated Communication

   NATs and Firewalls are persistent issues to resolve also in manager
   initiated communication.  However, we could re-use the capabilities
   of CoAP to overcome this issue.

   In this approach, there is no need to set a separate observation on
   the status of the device as defined in Section 4.  When the device
   sends a notification to any existing observation on any resource, the
   manager can initiate the software update during the established
   connection through NAT.  This approach requires the manager to
   implement the logic of linking observation of any resource to send
   software update to the device.






Jimenez & Ocak          Expires December 3, 2016                [Page 3]

Internet-Draft        draft-jimenez-iotsu-soft-exp             June 2016


6.  Delegation on other nodes

   Many of the IoT devices may not have connectivity to the manager and
   gateways are used to provide such connectivity to the manager in the
   e.g. core network.  Gateways used in this use case are more capable
   to perform complex operations and to support different protocol
   stacks together, which can be used to update the device software.

   For our implementation we assumed that the gateway supports, at
   least, both CoAP and HTTP stacks.  The communication between the
   device and the gateway is performed using CoAP.  Gateway can retrieve
   the software update from the manager through HTTP without NAT issues
   and cache the downloaded package.  One other way for the gateway to
   retrieve the software package could be to observe software update
   resource on the manager via CoAP observe option.  The manager
   notifies the gateway with CoAP notifcation when there is a software
   update available.  When the device wakes up and connects to the
   gateway, the gateway can push the cached software update to the
   device.

   However, this approach requires the Gateway to have the required
   credentials to perform such software update operation.  This can be
   achieved e.g. by having a CoAP proxy on the Gateway.

   Gateway retrieving software package via HTTP:

   G-->M: HTTP GET /swupdate
   G<--M: 200 Content, payload: swpackage
   D<--G: COAP POST /sw, Token: 0xbb, payload: swpackage

   Gateway retrieving software package via CoAP Observe option:

   G-->M: COAP GET /swupdate, Token: 0x6a, Observe: 0
   G<--M: 2.05 Content, Token: 0x6a, payload: swpackage
   D<--G: COAP POST /sw, Token: 0xbb, payload: swpackage

7.  Using Multiple Stacks

   We have seen how in some cases devices have multiple stack
   combinations and updates go through an "alternative channel".  For
   example:

   MQTT+HTTP  in this scenario MQTT is used as the base protocol for
      communication.  Having publish/subscribe architecture simplifies
      the (1:n) and (n:1) communication use cases that are very common
      for reporting sensor data.  For firmware upgrades a command is
      sent to the device with the URL where the new binaries are (i.e.
      https://company/devicetype/version00.zip), the device then sets a



Jimenez & Ocak          Expires December 3, 2016                [Page 4]

Internet-Draft        draft-jimenez-iotsu-soft-exp             June 2016


      whole different communication channel just for that, as well as a
      dedicated DTLS/TLS connection.  This is too much overhead for many
      constrained devices.

   MQTT+CoAP  similar to previous scenario, MQTT is the base protocol
      for communication and firmware upgrade command is sent to the
      device in an MQTT message, which includes the CoAP URL to the
      binary to be downloaded.  The device opens a UDP connection to the
      CoAP endpoint and downloads the binary with e.g.  CoAP blockwise
      transfer.  This scenario may occur when the node serving the
      software package supports only CoAP.

8.  Runtime Discovery

   Instead of sending bulk binaries with several megabytes of data, a
   simpler approach would be to send partial modifications related to
   the software update when possible.

   Similarly as it was shown in the IOTSI Workshop [IOTSIWS], Runtime
   Discovery is also a very powerful mechanism to provide updated
   services and software to a device.

   A device could use a single entry point for its firmware information
   (e.g. "/fw"), then device would periodically perform discovery on
   that point and in order to discover new capabilities.  Links to the
   new capabilities could be discoverable on demand.  Only very basic
   semantics would be shared a-priori.

   Current software upgrade mechanism do not allow for changes at
   runtime.  There are predefined interfaces that would break whenever
   the API changes, making it compulsory to send new software to the
   device that would need to install it, reboot, etc.  The device logic
   has to support such interfaces, no changes are possible at runtime.

9.  Acknowledgements

   Runtime Discovery ideas are inspired from Matthias Kovatsch's
   presentations on HATEOAS at [IOTSIWS].  Thanks to Carsten Bormann and
   Jari Arkko for the valuable feedback.

10.  Informative References

   [I-D.ietf-core-resource-directory]
              Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
              Resource Directory", draft-ietf-core-resource-directory-07
              (work in progress), March 2016.





Jimenez & Ocak          Expires December 3, 2016                [Page 5]

Internet-Draft        draft-jimenez-iotsu-soft-exp             June 2016


   [IOTSIWS]  IAB, "IoT Workshop for Semantic Interoperability (IOTSI) -
              Main Page and Position Papers", 2016,
              <https://www.iab.org/activities/workshops/iotsi/>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing", RFC
              7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
              RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

Authors' Addresses

   Jaime Jimenez
   Ericsson

   Email: jaime.jimenez@ericsson.com


   Mert Ocak
   Ericsson

   Email: mert.ocak@ericsson.com

























Jimenez & Ocak          Expires December 3, 2016                [Page 6]