Hardware/Software Architecture

Here we discuss how the above high level architecture can be implemented on various categories of devices. There exist three distinct classes of devices in the Fog: Sensors, Smartphones and Routers. We now describe the hardware used to imple- ment these three classes, following by a listing (Table 5.1) of the actual devices used in Fog Computing, some of which may represent multiple device classes depending on their functionality.

UDP/TCP IPv4,v6 Localization 802.11 a/b/g (2.4 GHz) (A)-GPS, Camera Driver Hardware (Ipod Touch/Tablet/Smartphone) File Sharing

App _{Detection App}Separation Applications Social Networking App Building Monitoring App

Figure 5.6: The hardware/software architecture of Fog Smartphones.

5.2.1 Fog Sensors

Sensors are typically low power, battery powered wireless sensor network plat- forms such as an EPIC [114] mote. The data sensed may be either mission critical or informational. Being heavily duty cycled, they are designed to last for several weeks with a single charge. 802.11 support is rarely found on these devices, with 802.15.4 or no networking being more common. Applications deployed on such de- vices include sensing and services (Building Monitoring Service, Sink Election App, Vibration Sensing App, and Self-Localization App in Figure 5.5). The BLIP stack provides UDP connectivity over the IPv6 provided by 6lowpan. In Fog Computing, we use RPL [115], an IPv6 routing Protocol for low power and lossy networks, as the default routing protocol. Fog Sensors can upload data into the Fog using a Fog Router as a proxy (to be described shortly).

5.2.2 Fog Smartphones

Smartphones refer to popular network centric consumer electronics like tablets, smartphones and laptops which have networking capabilities, but have limited re-

sources. Fog Smartphones are primarily used by first responders to access data stored in the Fog. They provide a rich interface to the data collected in the field, while also providing some functionality themselves. Not as resource constrained as Fog Sensors, most devices have 802.11 capability and are designed to last a few days on a single charge. Smartphones also have various sensors such as GPS, cameras, microphones and accelerometers. They are usually incapable of routing or advanced networking capabilities and have limited, but not scarce, resources. Apps installed on these devices are more of data consumers than data generators. The hardware platform used was the iPod Touch as well as the iPad. We were limited to the application layer since the SDK does not allow non-trivial modifications to the operating system for security reasons. The network stack on these devices consists of TCP/UDP over IPv4/v6 and 802.11. The fact that 802.11 IBSS mode was readily supported out of the box made us choose iOS over Android.

Fog Computing apps and services that run on Fog Smartphones including the Building Monitoring App (BTag App in Figure 5.6) that is used to program Fog Sensors running the Building Monitoring Service once they are deployed with relevant information. The File Sharing and Social Networking Apps (as shown in Figure 5.6) are also implemented on Smartphones, as is the Team Separation Detection App.

5.2.3 Fog Routers

Routers are portable, battery powered devices which provide basic wireless net- working functionality and are deployed in the field. An example is a common 802.11 router found in most homes today. They can be assumed to have expansion ports to provide additional functionality like persistent storage or cellular connectivity. These can either be static or deployed inside a vehicle. The hardware platform used in the Mikrotik RB433UAH routerboard which has 3 MiniPCI slots and 2 USB 2.0 ports,

UDP IPv6 RPL

802.15.4

Hardware

(Mikrotik RB433UAH + Epic Mote) 802.11-802.15.4 Switch

802.11 abgn File Sharing Service

Social Networking

Service

DTN Bundle Server TCP/UDP IPv4/6 and OLSR

Figure 5.7: The hardware/software architecture of Fog Routers.

allowing for two 802.11abgn wireless cards configured for 2.4 and 5 GHz respectively. It also has 512MB of NAND flash and 128MB of RAM. OpenWRT [116] is an open source GNU/Linux based operating system compatible with this router, which was chosen because of the openness and the wide range of software and support available. The USB port can be used to provide functionality like a new physical layer such as 802.15.4 (to communicate with Fog Sensors), enhanced storage like a USB flash drive or both. The networking stack used in is 802.11abgn below IPv6/v4 and UDP (Fig- ures 5.7). Since most COTS WiFi compliant devices support only the 2.4GHz band, we decided to use the 5GHz interface exclusively for routing. DHCP is provided on the 2.4GHz interface for clients to connect. All routers have statically assigned IPs - router n has an IP of 192.168.50.n for its 5GHz interface and 192.168.n.1 for the 2.4GHz interface. Each router can handle 255 end user devices - they are assigned IPs in the 192.168.n.0/24 range.

Fog Routers employ delay and disruption networking. For implementing DTN functionality, we used the IBR-DTN [117] implementation which is readily available as a package for OpenWRT. A “Bundle” (RFC 5050) is the primary data unit in

DTN. Each DTN node is identified by a URI like dtn : //dn.zigbeegateway1. A client application with an ID of mote1 can connect via an API to the local “Bundle Server”. Then, any traffic intended for this app will simply need to be addressed to dtn : //dn.zigbeegateway1/mote1. Examples of functions provided by the bundle server API includes registering the application name (e.g., “mote1”), setting a desti- nation, requesting encryption or authentication or custody transfer and setting the lifetime. All communication in the DTN layer can be encrypted and authenticated, as defined in RFC 6527. Each DTN node first generates, pre-deployment, a 2048- bit RSA public/private key pair. The public keys of all nodes are aggregated and shared among all DTN nodes. This data is used for bundle encryption in a public-key cryptography fashion. It is to be noted that bundle encryption is always between source-destination and authentication is always on a single hop basis. Bundle au- thentication uses the HMAC-SHA1 message authentication cipher, which encrypts a message based on a key. In this case, the key is a pre-shared plaintext key of arbitrary length that is different from the public/private keys.

DTN is implemented as an overlay network of nodes where multiple local clients can connect to a local DTN server (Bundle server in Figure 5.7) in the application layer. A special DTN app on the router which can talk to 802.15.4 based Fog Sensors as well as the DTN server provides DTN proxying functionality (“802.11-802.15.4 Switch” in Figure 5.7). The File Sharing and Social Networking Services have the capability to interface with Fog Smartphones by acting as a Fog API provider, while simultaneously talking to the Bundle server in order to replicate data on other Fog Routers.