# An IoT Surveillance System Based on a Decentralised Architecture
## 3 Proposed Architecture
### Architecture Elements
#### 3.4.1 Edge Computing  
In this section we discuss of the design of the edge layer and which functions it implements. In particular, the edge layer is used to collect and elaborate data coming from the physical layer for helping the decision making algorithm to classify alarms to raise and to communicate to others. This physical layer gather all the data from the sensors dispatched inside the environment analysing them. The proximity of this set of computational nodes allow a faster response without slowing down the responsiveness of the system. The tasks of the edge computing layer are to integrate and further compute the data and information from different kinds of sensor. Using the information gathered from different device it is possible to give a better interpretation of the contexts and ensure a seamless coordination between the environmental layer devices. For example, if a sensor detects a presence inside a restricted area the system reacts instantaneously by sending one or more drone to check the situation. Furthermore, if an anomaly is detected by different devices in a certain area the attention of the system is raised in order to verify it as soon as possible. Edge layer uses resources for executing some tasks locally with the main goal of reducing latency in the elaboration nodes. Often latency is due because core nodes are placed in the cloud layer and they are far from the user instances of the application that require remote elaboration. Some previous studies showed that latencies may be reduced by migrating some delay sensitive computation module as closely as possible to the users [39; 40]. The computation at edge cloud level is similar in functionality but different in terms of resources availability and elaboration delays. Indeed, the cloud layer uses a big pool of shared resources that bring up a higher computational capability to this layer, instead, edge layer has a limited set of resources but it is placed as closely as possible to the user layer. In this work, we evaluated the latency of the system in two different configurations, the first one presents only the cloud layer, the second one presents the edge layer as well. This configuration can be viewed as a M/M/c service model as shown in [41; 42]. Here, each edge or core processes multiple service requests which are stored temporarily in a buffer with an assumed infinity capacity. Different policies may be used in the management of the buffer taking into account services requests priority. In that case, since we assume that requests may have certain latency constraints we can use a priority scheduling or if we treat all requests in the same way then we can use the first come first served (FCFS) scheduling. Finally, we can show that in the model we use, the latency depends of the arrival rate we called \(\lambda\), the service rate we called \(\mu\) and the number of available servers we called \(c\). When the system load increases the arrival rate \(\lambda\) increases as well and we can measure a direct effect on the experimented latency. In particular, the computing latency per task which is called \(V\). It is easy to demonstrate because of the following equation:  
\[d_{comp}=\frac{1}{(c\mu-\lambda)} \tag{1}\]  
Here, the \(d_{comp}\) term means the computation delay measured in a computation node that has an arrival rate of \(\lambda\) and a service rate of \(\mu=\frac{f}{k}\). The \[W=\frac{\left(c\rho\right)^{c}}{c!}\times\frac{1}{1-\rho}p_{0}\times\frac{\rho}{ \lambda\left(1-\rho\right)} \tag{3}\]  
In the Equation (3) is shown the queue waiting time in a generic server node which is identified by an utilization factor called \(\rho\) and a queue probability called \(P_{Q}\), in the Equation (4) we shown how it is possible to evaluate the \(P_{Q}\). The initial queue probability is depicted in Equation (5).