# Internet of Bikes: A DTN Protocol with Data Aggregation for Urban Data Collection
## 1 Introduction  
The urban population of the world has grown quickly since 1950, from 746 million to 3.9 billion in 2014. The United Nations Population Division shows that, from 1950 to 2050, the share of the world's population living in urban areas will grow from 30% to 70% [1]. This migration from rural areas to urban areas has been going on in developing countries, thus increasing the concentration in cities. The large scale urbanization results in enormous negative effects such as unhealthy lifestyle caused by smoke and dust, air pollution such as carbon emission, traffic congestion, etc. Biking has emerged as one of the major alternative transportation modes thanks to its flexibility, low cost and the benefits bikes provide such as a positive effect on the overall health [2]. Therefore, there is a worldwide trend to develop urban biking. In particular, bike sharing systems have been growing tremendous for a decade, covering more that 1000 cities with more than a million bicycles [3; 4; 5]. Consequently, several digital services have been developed to assist bikers and enhance their urban experience. Most currently running services are smartphone-based and are comparable tocrowdsourcing/geolocalized applications. Following the trend of connected vehicle, the development of \"smart bikes\" arose, with integrated sensors and communication capabilities. The data they sense, analyze, collect, control and communicate can be useful for citizens, bike sharing system operators and municipalities. In this paper, we consider a smart bicycle sharing system that senses and collects data. Bicycles are cheap and human powered, thus the integrated sensors and communication devices need to be low cost and use low power. They hence have a small amount of memory and computing power and are, overall, low end moving Internet of Thing (IoT) devices. We are interested in networking protocols that can efficiently support data collection, converge-cast, and application in these settings. Mobile ad-hoc protocols were designed few decades ago with similar constraints. Nevertheless, most of these routing protocols suppose that the network is fully connected tolerating only short duty cycles for energy savings. At least an end-to-end path has to be available, computed a priori or on demand, each time a packet is sent. In practice, this assumption is hardly true in urban scenarios. Besides, the more dynamic is the network topology, the higher is the cost of signaling in these protocols, up to a point where the large majority of energy is spent in control and not payload transmission [6]. The Delay Tolerant Network (DTN) paradigm is an attempt to cope with highly dynamic topologies [7]. Tightly related to opportunistic communications, it is designed for intermittently connected networks facing long duration of partitioning or frequent movement. The core principle of DTN routing protocols is store-carry-and-forward: packets are stored in a buffer of a relay node, carried by it, and forwarded as soon as the \"next link\" is available. The main complexity of DTN routing compared to ad-hoc routing is then to decide which \"next link\" to use with an additional temporal dimension. This paper is an extended paper of [8; 9]. The main contribution of this paper is the design and evaluation of \"IoB-DTN\" (Internet of Bikes Delay Tolerant Network protocol), a data collection DTN-like protocol applied to a network of low cost, constrained and mobile IoT devices. The data sensed by the bicycles are relayed in a store-carry-and-forward manner and collected by a set of equivalent sinks. More precisely, IoB-DTN can be seen as a \"lightweight\" version of various flooding n-copy DTN protocols [10], optimized for IoT devices with several routing features removed for there are useless in converge-cast traffic. We compare this multi-hop approach with Low-Power wide-area network (LPWan, e.g., LoRa) technologies. LPWANs have been specifically designed for large scale coverage and could address the specific constraints of our settings [11].