## 3 System Model  
IoT applications comprise of edge nodes, IoT gateways and IoT servers [34; 55]. IoT servers listen to requests from application users as depicted in Figure 1. The request is communicated over the Internet using IP protocol. IoT servers are deployed on embedded hardware like Raspberry PI, Arduino or Intel Edison Board. IoT gateways are physical devices or software programs that connect cloud and IoT servers. One role of an IoT gateway is to translate user request in one protocol to another protocol [4]. For instance, an IoT front-end application interacting with end users listens to HTTP requests, but IoT servers are communicating with physical objects listens to Constraint Application Protocol (CoAP) requests, so one role of the gateway is to translate the HTTP request to a CoAP request. Similarly, edge nodes are physical objects connected locally with IoT gateways and perform specific tasks. For instance, in a smart home, a temperature sensor keeps sensing room temperature after a certain period. Similarly some edge nodes responsible for actuating an alarm, ring alarm only on the occurrence of a particular event. That being said, IoT tasks are also of two broad categories; periodic tasks which repeat themselves after a predefined interval called period and event-driven tasks which are executed on the occurrence of a specific event. As discussed in earlier sections that the core scheduling theory can be applied in IoT domain [18] so the system modeling can be formulated by leveraging the conventional tasks models. Consider in a typical IoT smart space, edge nodes are performing certain tasks in real-time. We consider a set of \(n\) independent tasks denoted by \([\tau_{1};\tau_{2};...;\tau_{n}]\) which are executed on IoT resources. For periodic tasks, an infinite identical tasks are activated at constant rate determined by their period. Let \(\tau_{i}\) has a period \(P_{i}\in R\) after which the task is reactivated then every release of task, also called instance of that particular task, \(k\in Z\) takes place at time  
\[r_{ik}=\phi_{i}+kP_{i}\]  
where \(\phi_{i}\) is the release time of \(i\)th task's zeroth instance. The list of all the symbols and acronyms are summarised along with their definitions in Table 1.  
Figure 1: General System Model of IoT Applications. It should be noted that instance number \(k\) can be negative, i.e., we have endless repetitions towards both ends of the time axis. \(\phi_{i}\in R\) is the time of release also called the phase of the zeroth instance of \(\tau_{i}\), which serves as a reference release. The first release of all tasks called the phasing \(\phi\) of the tasks. It has been assumed that we do not have control on the phasing of the tasks, for example, since the tasks are released with the occurrence of some external events, so we assume that any arbitrary phasing may occur. This assumption is common in real-time scheduling literature [61; 62; 63]. At any point, the resource is used to execute the first priority task that has some work in the pending. So in case of preemptive scheduling policies, when a task \(\tau_{i}\) is being executed, and a release occurs for a higher priority task \(\tau_{j}\), then the execution of \(\tau_{i}\) gets preempted, and will resume when the execution of \(\tau_{j}\) has finished, as well as all other releases of tasks with a higher priority than \(\tau_{i}\) that have taken place in the meantime. For simplicity, we assume the overhead from switching to be negligible. Figure 2 shows an example of the above. In the example, the priorities of the tasks are rate monotonic [63], i.e., a task with a smaller period has a higher priority. However, the analysis in this paper holds for any fixed priority assignment. **Definition 1**. : _The maximum response time of any release of \(\tau_{i}\) under any arbitrary phasing is called worst-case response time and is measured using Equation (1)._  
\[WR_{i}=max_{\phi,k}(end_{ik}-r_{ik}) \tag{1}\]