City Cloud

From the Things to the Cloud and back
Image: LindaInpijn (CC License)…

The term Internet of Things (IoT) loosely refers to the number of devices (including vehicles and appliances) interconnected with each other and exchanging data via a so called IoT platform. A careful approach to the architectural design can ensure proper integration of a large variety of devices.

The City Cloud project focuses on Internet of Things (IoT) applications in the context of smart cities and in particular on mobility and water management. The reason for doing so is the rich set of (often conflicting) requirements and challenges (in terms of mobility, scale, use, etc) that these smart city applications introduce, but also because these applications are of high interest to cities worldwide. To claim a generic IoT platform supporting a wide range of smart cities applications, having knowledge about their characteristics, similarities, and differences is useful.

There is an increasing demand and popularity of IoT not only from the research community but also from industry. It´s therefore beneficial to have a uniform/unified IoT platform because such a large-scale and heterogeneous platform is not available, and many research questions are becoming more interesting when observing “things” at scale. This unified platform is of great interest and use, because researchers can have real-time data, a real testbed, and a real platform to experiment on. This enables them to answer research questions and verify their approach irrespective of the format of their data, hardware, etc. Moreover, this could enable the research community to showcase their results to potential industry partners by providing these partners with an insight into the technologies, methodologies and applications, as well as evidence on what works via showcases.

This project was looking for a scalable solution (so able to serve multiple applications/use cases) with minimal changes to the platform, especially with respect to interfaces used to communicate with the UT testbeds. To this end, two categories were identified of open-source IoT platforms, cloud-centric and self-maintained.

The eScience Research Engineers found it would be easier to find a solution or platform that fit both use cases, instead of implementing the entire prototype platform from scratch. Additional development could be done on other features later as needed. In general, the choice of a suitable platform depends on the applications (use cases) researchers are trying to serve.

Kaa and ThingsBoard were identified as candidate solutions based on the following criteria: permissible license, an actively maintained GitHub repository, clear architecture, and good documentation. Kaa is a frontrunner due to the smart-city demo which comes close to both of our use cases. However, if the aim is to have a multiple applications served by the IoT platform, then it is best to start with a generic framework for interoperability reasons. In this case, the best suited platforms are IoTivity and FiWARE (e.g., smart city use case), although they might require more effort in the implementation.

There are advantages and disadvantages for using cloud-centric or self-maintained solutions. The self-maintained platform requires the presence of dedicated servers and an administrator maintaining the setup, connection, and is responsible for the backup. Finding a good hosting platform for the self-maintained systems is also a challenge. When arranging this on-premise, inside the academic institution, this will require collaboration with the centralized ICT services in the institute. Since the platform has strong requirements for the external network availability and access, centralized ICT might be hesitant in supporting it. External hosting providers will bring additional costs and risks concerning data security and availability.

In contrast, a cloud-centric solution comes with the cost determined by the service provider but will fully bypass the aforementioned issues. However, this type of solution means a full dependency on the service provider, including any changes to the API and service costs.


  • Nirvana Meratnia
    University of Twente
  • Rena Bakhshi
    Netherlands eScience Center
  • Hanno Spreeuw
    Netherlands eScience Center
  • Johan Hidding
    Netherlands eScience Center