Internet of Things Patterns
This is an excerpt of the pattern that was first published in [1].

Automatic Client-Driven Registration

Icon of the Automatic Client-Driven Registration pattern

To make itself known to its communication partners, a device initiates a registration process: It calls a registration API on the backend server and supplies required information about itself. From this information, a device model instance is created and stored on the backend server for future reference.

Aliases:

Self-registering Devices

Context:

Some devices should be connected to a backend server. Often, the backend server has to allocate resources for each device, for example, communication queues or storage space for stored events.

Problem:

Usually, many devices will be connected to one backend server, but for security or privacy reasons and to prevent misusage not any device should be able to connect at will. Some information about the authorized devices has to be known to the backend in order to be able to contact and manage them. How can this be done if the devices are autonomous and very dynamic?

Forces:

  • Scalability: In some cases, a large number of devices might be intended to connect to one backend server. Allocating the necessary resources and managing the registration by hand would involve a lot of work.
  • Dynamics: Devices might move between locations and backend servers in a very dynamic fashion. Managing these changing associations manually would be a lot of work or even impossible in highly dynamic scenarios.
  • Security: Not every device should be allowed to connect to a specific platform. There have to be some rules that govern which devices are allowed.

Solution:

Allow unknown devices to register themselves at the backend server via an API. The devices should provide at least a minimal set of metadata in the API call for successful registration. This should include the device id, details on how to communicate with the device, and some kind of authentication information, such as a token. Check the metadata to prevent illegitimate registration attempts, for example by comparing metadata against a list of allowed values or by validating the authentication information. If successful, place this metadata in a Device Registry so that the device can be identified later on.

Solution sketch of the Factory Bootstrap pattern

Solution Details:

This is an excerpt of a previously published pattern. The full pattern can be found in [1].


Benefits:
Drawbacks:

Variants:

Related Patterns:

Known Uses:

  1. L. Reinfurt, U. Breitenbücher, M. Falkenthal, F. Leymann, and A. Riegg, “Internet of Things Patterns for Device Bootstrapping and Registration,” in Proceedings of the 22nd European Conference on Pattern Languages of Programs (EuroPLoP), New York, NY, USA, 2017. Available at https://dl.acm.org/citation.cfm?doid=3147704.3147721