## 3 The Envisioned Fog Computing Architecture Supporting the CDNN Execution
### On the Hierarchical Organization of the FC Technological Platform
Due to the real-time nature of the considered IoT application scenario, the inference-delay, at which the decision \(\hat{c}_{m}\) exits at each \(tier\,\#m\), \(1\leq m\leq M\), is assumed to be limited up to a per-tier upper bound \(T_{EXIT}^{(m)}\) (s), \(1\leq m\leq M\), in which the actual value is set on the basis of the Quality of Service (QoS) requirements of the supported application. In order to support real-time inference, the time axis, over which the platform of Figure 3 operates, is partitioned into time-slots which are labeled by a discrete-time slot-index \(t\geq 0\). In the case of periodic sensing, the slot duration is fixed at \(T_{S}\), so that the \(t\)-th slot spans the half-open time-interval: \((tT_{S},(t+1)T_{S})\). In the more general case of event-driven sensing, the duration \(\Delta_{S}(t)\) of the \(t\)-th slot depends on the slot-index \(t\), so that the \(t\)-th slot covers the half-open interval: \((\xi(t),\xi(t)+\Delta_{S}(t))\), where: \(\xi(t)\triangleq\sum_{i=0}^{t-1}\Delta_{S}(i)\) is the starting time of the \(t\)-th slot. We expect that all the results presented in the following hold verbatim in both cases of periodic and event-driven sensing, provided that, in the second case, the minimum slot duration is lower bounded by \(T_{S}\), that is, \(\Delta_{S}(t)\geq T_{S}\), \(\forall t\). The envisioned technological platform of Figure 3 is assumed to be equipped with both networking and computing capabilities. Specifically, the required inter-node message passing is implemented by a number of inter-tier and intra-tier transport connections (see the arrows of Figure 3). Up-link communication between FNs falling in adjacent tiers is supported by a number of TCP/IP one-way reliable connections, which are sustained by wireless (possibly, single-hop and WiFi-based) communication links (see the continuous purple arrows in Figure 3 between adjacent tiers). Since load balancing is assumed to be performed at the outputs of each tier, all the transport connections going from Fog nodes at \(tier\,\#m\) to Fog nodes at \(tier\,\#(m+1)\) are assumed to operate at a _same_ bit-rate of \(R_{m}\) (bit/s). Horizontal communication between the Fog nodes and the Aggregator falling into the same tier is assured by an intra-tier (wired or wireless) LAN which relies on UDP/IP two-way transport connections (see the continuous blue arrows in Figure 3). Being of local-type and used only for (sporadic) aggregation operations, these intra-tier connections are assumed to operate at low bit-rates, so that the impact of their energy consumption is expected _not_ to be so substantial. Finally, the protocol stack implemented by the envisioned architecture of Figure 3 is detailed in Figure 4. Specifically, the three-layered architecture of the simulated protocol stack of Figure 4 reflects the corresponding partition of the technological platform of Figure 3 into three hierarchically-organized main segments, namely: (i) the lower-most segment, at which the IoT devices operate; (ii) the middle segment, which embraces the clusters of Fog nodes; and (iii) the upper-most segment, where the remote Cloud works. Figure 4: _DeepFogSim:_ the protocol stacks of the considered technological platform of Figure 3.  
_Remark--On the optimality of the considered multi-tier hierarchically-organized Fog topology_. A final remark concerns the generality and optimality of the considered hierarchically-organized and multi-tier Fog topology of Figures 1b and 3. In this regard, four main considerations are in order. First, due to its feedforward nature, the topology in Figure 1a of the CDNN to be executed is, by design, of stack-type. This forces, in turn, to select a hierarchically-organized companion topology for the corresponding execution platform of Figure 1b, in order to allow the ordered execution of the layers of the supported CDNN.