In this section the design principles behind Fog Computing are discussed. These are general system design principles which we have adopted keeping in mind the re- quirements to be satisfied by Fog Computing as well as some practical issues affecting today’s disaster response efforts. Next, system network architecture that implements these design principles is proposed. Each of the layers in this architecture has specific functions, which are described.
4.1 Design Principles
Based on first hand accounts of USAR deployments and responder requirements, we decide on a set of principles that govern our design of Fog Computing. A list of applicable system design principles can be found in [111].
1. Unmodified COTS Devices: Governmental organizations are increasingly adopt- ing COTS devices because of the available support and software, at fairly eco- nomical prices as compared to a custom platform. In many instances, USAR responders have used their own personal iPhones during disasters to email photographs of rubble piles. In any case, one cannot assume a “jailbroken” de- vice where one can have complete control, as is fairly common with hardware platforms used in academic research. Instead, the system has to be designed such that stock capabilities of popular COTS devices are sufficient, so that devices can be borrowed and setup easily. A custom routing protocol or user replaceable batteries are not possible on the iPhone, as an example.
Parts of this section reprinted with permission from “Distressnet: A disaster response system providing constant availability cloud-like services” by H. Chenji, W. Zhang, R. Stoleru, and C. Arnett. Ad Hoc Networks, vol. 11, no. 8, pp. 2440-2460, 2013. Copyright 2013 by Elsevier.
2. Open Standards and Protocols: Standardized protocols, preferably of inter- national scope, are emphasized. Certain WiFi channels are allowed in Japan but not in the USA; such issues should be planned for. At every layer of the system, open formats and widely supported protocols make integration of hardware with other international teams much easier.
3. App Oriented Design: Because complexity is pushed towards the applica- tion layer, updating the system becomes easy and does not need recompil- ing/reflashing the entire device, especially during disasters. When deployed on a large scale over a variety of heterogeneous devices, This design principle will significantly reduce roadblocks encountered in platform adoption. At the same time, simplicity in these complex apps is necessary: when a human-computer interface is present, having more than three buttons will cause the device to be left behind in a vehicle, instead of being used by first responders.
4. “Premature Optimization is the Root of All Evil”: With Fog Computing we first build a proof-of-concept implementation that captures most of the required functionality, and then iteratively optimize the system based on deployment ex- periences. For example, we trade performance for simplicity in the source rout- ing optimization, by using a simplistic vehicle movement model. The gained simplicity makes it easier to deploy Fog Computing as a whole with limited manpower, providing us with valuable experience which we can then use in the next iteration of the source routing protocol.
4.2 High Level Network Architecture
A network architecture for Fog Computing is shown in Figure 4.1. Being de- signed for COTS devices and open protocols, there is a necessity for incorporating heterogeneity at all levels. For example, there are multiple protocols being used at
Multiprotocol MAC
Middleware
Applications
Multiprotocol Routing
LocalizationPHY
Heterogeneous Hardware
E
n
e
rg
y
A
w
a
re
n
e
ss
B
u
s
Co-existence
Figure 4.1: System architecture
the PHY, MAC and Routing layers. 802.15.4 is a popular PHY choice for low power sensing systems, whereas 802.11/WiFi is widely used in smartphones and COTS end user devices. In addition, a device may or may not have additional hardware like GPS and USB storage devices. All these components are important to the de- sign of Fog Computing. A Coexistence layer manages and coordinates the various PHY/MAC/Routing protocols. However, multiple protocol coexistence is not ex- plored in this dissertation and is left as future work. The middleware layer acts an abstraction layer to the Applications used in Fog Computing. It contains the QoS aware routing protocol that takes data from the applications and computes the node to which this data is to be transmitted (via the lower layers). A Localization layer provides precise location information that may be used as data quality enhancement by an Application, or by the Middleware layer to optimize the aggregate goodput of the system. For localization to work, it needs low level access to hardware. Energy Awareness is implemented as a cross-layer bus that interacts with all of the above layers. The bus can compute a work schedule for PHY given an expected network
usage estimate by the Middleware layer, which in turn creates its estimate from the installed Applications and their usage pattern.
The precise functions of each of these components is enumerated below:
1. Heterogeneous Hardware: Provide basic hardware functionality to the upper layers
2. PHY (Network Physical Layer): Provide access to the radio
3. MAC (Network Medium Access Control): Provide control primitives for the radio to access the physical medium, provide link layer robustness to the upper layers
4. Routing (Network Routing): Provide basic device addressing functionality, choose a link for data forwarding
5. Multiprotocol Coexistence: Optimize and tune each PHY protocol so that interference between multiple PHY protocols is minimized
6. Middleware: Provide Fog Computing API functionality to the applications, provide QoS aware routing functionality to the applications, provide waypoint placement functionality
7. Localization: Provide the geographic location of the host device
8. Applications: Provide an interface into Fog Computing for the user, provide file sharing and social networking services to the user
9. Energy Awareness Bus: Duty cycle each hardware component based on network performance requirements