How to see through the Fog? Using Peer to Peer (P2P) for the Internet of Things David Tracey1 Cormac Sreenan Dept. Of Computer Science, Dept. Of Computer Science, University College Cork, Ireland University College Cork, Ireland Abstract—The Internet of Things (IoT) faces the challenge of highlights the importance of interoperability: “Of the total scaling to handle tens of billions of connected devices. This potential economic value the IoT enables, interoperability is challenge is made more difficult by the range of constituent IoT required for 40 percent on average and for nearly 60 percent parts from Cloud-based applications to constrained nodes in in some settings”. Approaches demonstrating scalability and Wireless Sensor Networks (WSNs). Achieving the desired scale interoperability at Internet-scale and the value of an and interoperability requires an architecture for IoT that is architectural approach include the RESTFul architectural scalable and allows seamless operation across networks and style [7] and BitTorrent [8]. The RESTFul style is based on devices. This paper considers the requirements for IoT and specified constraints and components. Its success can be seen considers a number of existing architectural approaches and the in the development of HTTP1.1 and the wide adoption of emergence of Fog computing. It proposes that Fog computing REST APIs. BitTorrent has also shown that Peer-to-Peer architectures must cater for the flow of data from constrained sensor nodes to powerful applications. It considers the (P2P) can provide a low barrier to entry, greater autonomy, suitability of a Peer to Peer (P2P) approach for Fog computing. scale and robustness. Using a prototype implementation, it demonstrates how a This paper considers which architectural approaches may Holistic Peer to Peer (HPP) architecture and application layer be suitable for IoT and how they relate to Fog computing. As protocol meet the requirements set for IoT. such, we present a set of requirements for IoT and consider lessons from the RESTFul style and BitTorrent to meet those Keywords–Internet of Things(IoT), RESTFul Style, Fog requirements. This paper proposes that meeting the challenges Computing, Wireless Sensor Network (WSN), Peer to Peer (P2P). presented by IoT requires an architecture and a set of consistent abstractions for all components in the entire flow as I. INTRODUCTION data is sent (and aggregated/stored/acted on) from constrained devices to edge gateways to Cloud services. As such, this Wireless Sensor Networks (WSNs) interact with the paper proposes that Fog computing [9] architectures must physical world allowing nodes to be deployed close to sensed consider constrained devices as part of that flow and that a phenomena. The “Internet of Things” (IoT) is a distributed P2P overlay network can be used to achieve scalability and system of devices and applications for sensing, actuation and high availability, especially at the edges of the Internet as in computation. The estimated tens of billions of connected IoT Fog computing. In this context, we present a Holistic Peer-to- devices [1] will need solutions to program and manage them, Peer (HPP) application layer protocol that has been extended with services to gather, store and analyze vast amounts of data. to use a Distributed Hash Table (DHT) based on Kademlia Cloud services and Big Data approaches allow the scalable [10] as part of our previously presented architecture [11]. storage and analysis of this data, while Fog and Edge Implementations of the architecture have demonstrated computing offer rich functionality at the edge of the Internet. interoperability by allowing a constrained node to provide Protocols, such as the Constrained Application Protocol IPSO data using HPP and CoAP and shown a straightforward (CoAP) [2] and data models, e.g. IPSO (Smart Objects) [3], service to integrate with HBase. have emerged to support better application interoperability. The remainder of this paper is organized as follows. The potential of IoT is, however, limited by the difficulties Section II presents requirements for IoT, section III reviews a imposed by the constrained processing, memory and energy number of architectural approaches and section IV gives an consumption of WSN nodes and their heterogeneous nature, overview of our Holistic Peer to Peer (HPP) architecture and limited development environments and diverse software and the addition of a DHT. The paper concludes in section V. protocols. A key challenge with such diversity is to enable the growth of IoT in terms of scalability and also of developing II. IOT ARCHITECTURAL REQUIREMENTS services and node software. The scalability challenge requires The requirements for an IoT architecture in [11] have been being able to scale up to billions of devices, but also to scale refined and it should: down to resource-constrained devices in relatively small • WSNs [4]. This requires seamless interoperability and a define the roles of nodes running services. Nodes consistent set of abstractions and APIs/protocols, particularly must meet a minimum level of functionality, e.g. at the application layer to realise Mark Weiser’s vision of tiny respond to a request for its capabilities (Req-1). networked computers woven into everyday life [5]. [6] 1 David Tracey is employed by Rapid7, Dublin, Ireland. 978-1-5386-4980-0/19/$31.00 ©2019 IEEE 47 • provide abstractions to support the basic operations The RESTFul architectural style also includes processing required of a sensor node and the services using it. elements that are determined by their roles, i.e. origin server, These must map easily to a range of heterogeneous gateway proxy, user agent. A recent paper reflecting on the devices and higher level services (Req-2). RESTFul architectural style [14], including the original • be independent of particular node hardware and authors, considers that there have been different handle a range of node capabilities (Req-3). interpretations of the term REST, but reiterates that “REST is • provide simple, consistent APIs for developers of not an architecture, but rather an architectural style. It is a device and application software (Req-4). set of constraints that, when adhered to, will induce a set of • provide a consistent means to exchange information properties; most of those properties are believed to be independent of the underlying technology and support beneficial for decentralized, network-based applications, the modelling of (sensor) data to allow its use by while others are the negative trade-offs that can result from higher level services (Req-5). any design choice”. Importantly it also states that “REST does • support a (sensor) node informing other nodes and not directly constrain the Web’s architecture. Rather, an services of its capabilities (Req-6). application developer may choose to constrain an • be dynamic to handle small, static networks and adapt architecture in accordance with the REST style”. The as the network changes and support applications RESTFul style has been shown to facilitate application discovering and collaborating without a centralized development and scalability as a result of its decoupled nature. coordination facility (Req-7). It must also be robust CoAP [2] is a specialized protocol for constrained nodes to support challenging wireless environments [12]. and constrained (e.g. low-power, lossy) networks. It was originally a binary format on top of UDP, but has been • use protocols that are sufficiently simple for low extended to also support TCP and TLS in RFC83232. It uses capability devices to participate (Req-8). RESTFul concepts such as URIs, with its own schema coap://, These requirements for nodes and services would enable and media formats. It is designed to be easy to proxy to/from an “Opportunistic IoT Service”, which is defined to provide HTTP. CoAP provides resource discovery via the Resource an “interface that allows an IoT entity to be engaged, under Directory (RD) and specific message types to provide specific constraints and pre/post-conditions, in a temporary, reliability. The use of an “observe” flag in the GET Request contextualized and localized usage relationship” [13]. provides observe/notify on a given resource. RESTful III. ARCHITECTURAL APPROACHES approaches with CoAP are increasing [15], e.g. an end-to-end IP based architecture for greenhouse monitoring integrating A. RESTFul Architectural Style CoAP over a 6LowPAN WSN using Contiki [16]. The RESTFul architectural style uses a resource as a key B. Middleware Approaches abstraction of information that can be represented in a number Middleware is software that acts as an intermediary of representations using the Internet media types. It is based between IoT devices and applications. [17] considers three on the following five interface constraints in [7]: types of IoT middleware: service-based, cloud-based and • All important resources are identified by one actor-based. Service-based is a service-oriented architecture resource identifier. This is generally a Universal (SOA) where IoT devices may be represented as services. Resource Identifier (URI). This constraint leads to Cloud-based services allow users to upload their sensor data the interface being simple, visible, and reusable. to the Cloud for storage, querying and analysis using Cloud • Access methods have the same semantics for all databases, NoSQL stores and Machine Learning toolsets. resources. For HTTP, this results in a limited set of These offerings use a proxy/gateway and APIs to provide the verbs, such as HEAD, GET, POST, PUT, DELETE integration with a Cloud service, usually limited to a given with easily understood semantics. This leads to the Cloud provider and perhaps to a given device environment. interface being visible, scalable, and available. The actor-based architecture exposes IoT devices as reusable, • Resources are manipulated through the exchange of distributed actors. It is designed to be lightweight and flexible representations. This constraint leads to the interface enough to run in all components according to their capability, being simple, visible, reusable, cacheable and e.g. a constrained node might not include a storage service.