Skip to main content

Comparative Analysis of Distributed Repository Update Methodology and How CoAP-like Update Methods Could Alleviate Internet Strain for Devices that Constitute the Internet of Things
slides-iotsuws-comparative-analysis-of-distributed-repository-update-methodology-and-how-coap-like-00

Slides IAB Workshop on Internet of Things Software Update (iotsuws) Team
Title Comparative Analysis of Distributed Repository Update Methodology and How CoAP-like Update Methods Could Alleviate Internet Strain for Devices that Constitute the Internet of Things
Abstract
Robert Bisewski, Comparative Analysis of Distributed Repository Update Methodology and How CoAP-like Update Methods Could Alleviate Internet Strain for Devices that Constitute the Internet of …
Robert Bisewski, Comparative Analysis of Distributed Repository Update Methodology and How CoAP-like Update Methods Could Alleviate Internet Strain for Devices that Constitute the Internet of Things
State Active
Other versions plain text
Last updated 2023-02-08

slides-iotsuws-comparative-analysis-of-distributed-repository-update-methodology-and-how-coap-like-00
Title:

Comparative Analysis of Distributed Repository Update Methodology and How
CoAP-like Update Methods Could Alleviate Internet Strain for Devices that
Constitute the Internet of Things

---

Author:

Robert Bisewski
#405 - 860 Homer Street
Vancouver, British Columbia, Canada - V6B 2W5
robertb@linuxmagic.com

---

Abstract:

As a consequence of recent advances in computational power, much of the world
relies heavily on electronic devices designed improve our efficiency during
working hours and expand the quality of our life in other areas; otherwise
known as the Internet of Things. However, these device are expected to retain
a level of utility for an extended number of years, possibly 10 or more. As
a result, hardware manufacturers are attempting to develop methodologies to
keep these devices in a functional and secure state for the entirety of their
life cycle. This page explores a number of proposed techniques that attempt
to manage one of the core aspects of this, software updates, from a popular
example of an existing technique, as well as presenting an idea of utilizing
CoAP to allow for reduced straining on existing networks.

---

Categories and Subject Descriptors:  

D.2.9 [Software Engineering]: Management - software process models,
life cycle, maintenance.

---

General Terms:

Management, software maintenance, life cycle.

---

Keywords:

CoAP, CoRE, Software Updates, Software Development, Software Development
Maintenance, Agile Software Development, Software Process, the Internet of
Things.

---

1) Introduction:

From the management of large networked systems [1] to the developmental
ecosystems used by IT employees [2] to a electronicly augmented defense
turrent [3][4], a concept that is on the verge of re-emerging is the idea of
a maintenace life cycle. How this differs from past attempts of planning out
software life cycles with the internet in mind, is a subject of some interest
to the industry. Notably, how flaws in current development models might
accidentally result in wide-ranging exploits in the software of existing
consumer and business devices. In order to deal with possibilities of
migitating this, the goals of this paper are twofold; first an exploration
of a commonly used technique to allow devices to receive updates via
a distributed repository model, as well as the purposal of a theoretical
device-to-device interactive model of updates via the Constrained Application
Protocal, otherwise known as CoAP.

---

2) Common Technique - Distributed Repository Model:

One of the more popular methods for the publishing of updates, is the idea of
a utilizing a wide network of remote proxies that could be used as a sort of
distributed connective interface to a repository containing the latest
version of a given piece of software for a device. This repository would, of
course, be certificate-signed and verified to prevent forging from potentially
malicious agents, such hackers harnessing cloud-based botnets. One such
variant is mentioned in a patent filed by Felipe Albertao [5] on behalf of
Google, in which he outline the basic overview of the technique, which can be
summarized as follows:

Client devices utilize the pre-existing networks at their disposal from their
intranet to then remotely connect to a distribution services machine (e.g. an
online server that stores the latest version of a piece of software). The
distribution services machine, in turn, stays up-to-date by retrieving data
from the original author of the software in question (not unlike the concept
of a mirror). Thus a complete retrieval ecosystem is put in place in order to
accommodate the expectation that end users are able to receive updates from
the known repositories, while at the same time, the repositories are retained
and routinely sent the latest version of the software needed by devices that
constitute the Internet of Things.

For a brief overview of how a retrieval ecosystem could work, please refer to
Figures 1, 2, and 3 on the patent itself [5].

Regarding the devices themselves, they are naturally required to have a
process for dealing with any files that are received. First, the client
will need to determine the designated update policy and check if the
intention of the designers to continue to provide updates as per the
so-called "subscription" model. If the device detects an updated package that
is currently "selected" it will received the updated package as per the
update policy and then check if the package can be validated. If it cannot
be validated, then the process ends. Otherwise it can be validated, and so
will then proceed to check if the system accepts the change as functional.
If an error occurs that this stage, the system will rollback the bad changes
to the previous version stored on its system. If instead the package was a
success, then the software of our device is now up to date.

A breakdown of how such a subscription model could be handled is detailed
in flowchart of Figure 6 in the patent itself [5].

With both of these systems in place, a repository is able to stay up to date,
while the client device is able to be certain that an update is both secure
and will not accidently cause the device to malfunction. In the event of a
potentially bad update, the ability to rollback any hazardous changes is of
utmost importance. So the goal of the "distributed repository" method is to
address this concern as per the above process.

---

3) Suggested Theoretical Idea - Device-to-Device Interactive Model:

While the centralized mirror-like model of updating devices in the Internet
of Things remain the mainstay of established companies, alternative
implementations for handling software updates on smaller devices are growing
in popularity due to the reduce strain on system resources that often
plagues any IT department.

The device-to-device model attempts to resolve this strain by depending less
on event triggers or lookups to large centralized reposities, and instead
rely from other similar devices inquiring about their current state. A famous
example is the MAGIC Broker system [6], but other decentralized models exist,
although admittedly they are rare in that most providers wish to relay from
a more centralized, and thus earlier to control, location.

In the absence of a good and reliable decentralized system, other developers
attempt to fill the gap in interesting ways. One of the more popular recent
attempts is to focus on node-to-node communication. This page will explore
CoAP [7], which uses UDP packets for the purpose of implementing the CoRE
standard (Constrained RESTful Environments), and how in theory it could be
used to reduce possible network strain. More information about the standard
can be found here[8].

CoRE is a framework for handling the input from multiple types of sensors,
or managing simple devices, such as nodes or consumer devices that need
occasional changes or adjustments or need to return output to some other
device in the network topology. For specific details of a basic HTTP mapping
for CoAP, refer to RFC 7252 [9].

By inheritantly incorporating machine-to-machine and multicasting, much of the
overhead of using large HTTP requests is eliminated. As a result, the strain
placed on the Internet and existing protocols can be overcome; this assumes
the next generation of industry manufacturers will be able to integrate
support for this protocol into their future devices.

In theory, CoAP could be used to allow connected nodes to check and verify
with each other. Developers have currently created a number of 
implementations in the prevalent programming languages: examples include
aiocoap[10], cantcoap[11], and node-coap[12].

What this author proposes is that future implementations of CoAP could be
designed to offer machine-to-machine updating within an intranet or possibly
even a local subnet via HTTP. CoAP currently allows for easy multicast of
device setting changes, and can be easily translated to HTTP, which means one
could potentially send updated files via such requests as well. Also worth
mentioning, the end points of CoAP could be used as both server and client
side, unlike HTTP, and so could be used for collections of smaller
interspersed networks[13].

As opposed to relying on direct communication with repository servers,
sending CoAP packets could potentially allow for "waves" of devices that
would verify, download, and then update themselves. All of this could be
conducted independently of the original repository. An example of this could
be as follows:

                 [Device]         [Device]         [Device]
                      \               |               /
                       \              |              /
LAN / WAN               \             |             /
                        \/           \/            \/
                      [Device]    [Device]      [Device]
                         /\           /\         /\
                          \           |          /
-----------------------------------------------------------------------------
                            \         |        /
Internet                     \        |       /
                              \       |      /
                         [Originating Update Server]

As a default fallback mechanism, the devices would attempt to retrieve from
the originating update server. However, if the individual devices were in
contact with each other during their attempt to gather the update, they could
grab the updated packages from their immediate peer without a need for
contacting the main server.

At this time, using CoAP in this manner is purely theoretical, but the
possibility of utilizing given updates from nearby peers in order to save
bandwidth could help reduce strain to existing Internet architecture. A study
done with regards to mobility network management[14] suggests that it is easily
possible to extend CoAP for more specialized purposes. 

Again the goal of this paper is not to devise an implementation, but merely to
note that the author believes this, or something like this, is the future of
system updates for devices that comprise the Internet of Things.

---

4) Conclusion:

The use and development of the internet means that the our increasingly
connected will likely demand a great deal of maintenance in order to remain
functional at a level that end users are accustomed to. This will mean that
both centralized and decentralized techniques will be needed to keep the
growth of the Internet on its current pace.

Software developers are currently weighing the benefits and tradeoffs of
utilizing existing protocols. It is expected that over time a certain method
or combinations of methods will emerge as the ideal system for handling this
constraints of the modern Internet of Things, even if only for specific
type of device and reliability requirement.

As stated earlier, the concept of a distributed repository could fit very well
with the development cycle of device with a device that is being constantly
interacted with on the side of the end user. One such system could be the
the operating system of a mobile consumer product; a Android or iOS tablet
or phone is expected to receive updates in a manner that is electronically
authorized on a secure level and will continue to function even if a number
of the updated packages are broken and a rollback becomes required.

The technique of device-to-device maintenance via constrained protocols like
CoAP could be of assistance to smaller devices, such as sensors, video
cameras, set-top boxes, fridges, or other smart home devices. Possibly with
some research, this technique could be extended to mobile devices with small
size requirements. Alternately, it could be utilized to allow developers to
offer daily updates of complex software, instead of larger whole package
downloads at given intervals. This might be a way to reduce the strain on
existing Internet channels, as well as providing more reliable updates as
fewer files of a system are changed at any given time.

On another note, existing devices are likely cause some strain and be
potentially serious security risks[15], so perhaps there is a need to also
address this aspect of the Internet of Things in the interm until a good
decentralized technique can be developed. However, that is likely a complex
and separate topic unto itself, but security risk do further complicate the
situation of Internet strain.

Ergo, it is the opinion of this author that with the existing strain of
networks of the Internet and the devices using it[16] means that decentralized
or simplified or concurrent methods, such as the possible extension of CoAP,
will be the prefered style of delivering software updates to future smart
devices in the Internet of Things.

---

5) Acknowledgements:

I would personally like to thank all of the staff at LinuxMagic for assistence
in this endeavour; their knowledge of the inner workings of systems helped
make study into this field possible, especially with regards to higher level
concepts in the software industry. A notable mention is Shaun Johnson, who
explained to me value of patience and cautionary measures when dealing with
complex networking systems.

As well, it is only fair to give a mention of my mentor, Dr. Pradeep K. Atrey,
professor at the University of Albany, who demostrated to me critical thinking
techniques for exploring the future of the field of Computer Science. I thank
him for the faith he has placed in me in the past, it will not be forgotten.

---

6) References:

[1] Z. Qin, G. Denker, C. Giannelli, P. Bellavista and N. Venkatasubramanian,
"A Software Defined Networking architecture for the Internet-of-Things,"
2014 IEEE Network Operations and Management Symposium (NOMS), Krakow, 2014,
pp. 1-9. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6838365
&isnumber=6838210

[2] A. Fuggetta, E. Di Nitto. "Software Process," ACM - FOSE 2014, Proceedings
of the on Future of Software Engineering, pp. 1-12.
http://dl.acm.org/citation.cfm?id=2593883

[3] R. Bisewski and P. K. Atrey, "Toward a Remote-Controlled Weapon-Equipped
Camera Surveillance System," 2011 IEEE 23rd International Conference on Tools
with Artificial Intelligence, Boca Raton, FL, 2011, pp. 1087-1092.
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6103476
&isnumber=6103298

[4] R. Bisewski and P. K. Atrey, "Modeling, Simulation and Analysis of a
Weaponry-equipped Camera Surveillance System," Journal of Modelling &
Simulation of Systems. 2012, Vol. 3 Issue 1, p4-13. 10p.

[5] F. Albertao, "System and method for distributing software updates to a
network appliance," US Patent - US 10/725,617 - 
https://www.google.com/patents/US20050120106

[6] M. Blackstock, N. Kaviani, R. Lea and A. Friday, "MAGIC Broker 2: An open
and extensible platform for the Internet of Things," Internet of Things (IOT),
2010, Tokyo, 2010, pp. 1-8.
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5678443&isnumber=5677827

[7] Bormann, Carsten; Castellani, Angelo P; Shelby, Zach. "CoAP: An Application
Protocol for Billions of Tiny Internet Nodes," IEEE Internet Computing 16.2
(Mar 2012): 62-67. 

[8] A. Melnikov, B. Leiba, "Constrained RESTful Environments," April 2016.
https://datatracker.ietf.org/doc/charter-ietf-core/

[9] Z. Shelby, ARM, K. Hartke, C. Bormann, Universitaet Bremen TZI, "The
Constrained Application Protocol (CoAP)," June 2014. RFC 7252 via the IETF.
https://tools.ietf.org/html/rfc7252

[10] M. Wasilak, C. Amsuss, "The Python CoAP library," Nov 2015.
https://pypi.python.org/pypi/aiocoap

[11] A. Mills (staropram), Noisy Atom Limited, UK. October 2015.
https://github.com/staropram/cantcoap

[12] M. Collina (mcollina). "CoAP - Node.js Style," May 2016.
https://github.com/mcollina/node-coap

[13] Alessandro, L.; Pol, M.; Anna, C. "TinyCoAP: A novel constrained
application protocol (CoAP) implementation for embededding restful web
services in wireless sensor networks based on TinyOS," J. Sens. Actuator
Network 2013, 2, 288–315. http://www.mdpi.com/2224-2708/2/2/288/htm

[14] Seung-Man Chun, Hyun-Su Kim and Jong-Tae Park. "CoAP-Based Mobility
Management for the Internet of Things," School of Electronics Engineering,
College of IT Engineering, Kyungpook National University, Daegu 702-701,
Korea. http://www.mdpi.com/1424-8220/15/7/16060/htm

[15] B. Schneier, "There's No Real Difference Between Online Espionage and
an Online Attack", March 2014.
https://www.schneier.com/essays/archives/2014/03/theres_no_real_diffe.html

[16] B. Schneier, "The Internet of Things Is Wildly Insecure And Often
Unpatchable", January 2014. 
https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html