## 2 Assumptions of Our Target System and Challenge
### Assumptions  
* **IIoT application features. ** As noted above, our target IoT applications are AMI, DA, PA, and so on. These typical industrial applications normally collect field data from end devices periodically within pre-determined deadlines that include communication latency and internal processing time on both a central node and an end device. In this paper, we assume that the end devices periodically generate data in intervals, and a deadline that the central node should get data from an end device is equal to the next time that an end device generates data within the interval. * **polling-based communication. ** Our target IoT applications normally use polling-based communication to keep a sequence of processes or simplify network management. In general, there are two different polling schedulings, called monocycle and multicycle polling scheduling. * **Monocycle polling scheduling. ** Monocycle polling scheduling is the most common and the simplest. In monocycle polling scheduling, a central node uses a single cycle for the polling required for all devices belong to a single group. Figure 1 shows an example of a monocycle polling scheduling. In this case, the deadline (cycle) is \(T_{1}\) and three nodes (\(n_{1,1},n_{1,2},n_{1,3}\)) belong to the group. * **Slot assignment for reliable polling communication. ** A central node transmits the first queries at \(t_{1},t_{2},t_{3}\) to the nodes respectively. Retransmission timings are also allocated in case of communication failure. For example, \(t_{4}\) and \(t_{7}\) are timing for retries of the first query to \(n_{1,1}\). The number of the retries \(R_{j}\) for node \(j\) depends on communication success rate, for example PER (Packet Error Rate) as shown in Equation (1); \[1-P_{PERj}^{R_{j}}\geq Th_{success},\] (1)  
Figure 1: An example of polling schedule in a monocycle polling scheduling. where \(P_{PERj}\) is an end-to-end PER between a central node and node \(j\) and \(Th_{success}\) as one of system requirements is probability of collecting data from any nodes in a system. * **Multicycle polling scheduling. ** Multicycle polling scheduling is a set of heterogeneous monocycle polling schedulings. Figure 2 shows an example of multicycle polling patterns. In this example, three applications in a system have different cycles that are denoted by \(T_{1}\), \(T_{2}\), and \(T_{3}\), respectively. The central node transmits the first queries and their retires in each cycle as well as a monocycle polling scheduling. In Figure 2, lower brightness areas represent some consecutive slots of first queries and higher ones do some consecutive slots of their retires. Besides, white areas stand for open slots for unpredictable on-demand request. The width of the areas depends on the schedules. For example, the first lower brightness area of \(G_{1}\) includes 3 slots and the second one includes 5 slots. * **Wireless communication for IWSNs. ** To increase the reliability of wireless networks for industrial applications, Time Slotted Channel Hopping (TSCH) based IWSN protocols such as WirelessHART, ISA100.11a, and IEEE802.15.4e have been developed. They are time-synchronized and assigned communication timings for transmitting packets by a central network manager in order to decrease both interference within the wireless network and interference from other wireless networks using the same radio channels. The communication timing for both downlink traffic from a central node to end devices and uplink traffic from end devices to a central node are assigned. These bandwidths for downward and upward are normally fixed. In addition, the available bandwidth for upward traffic is bigger than that for downward. * **Imbalanced bandwidth between upstream and downstream of IWSNs. ** Generally speaking, bandwidth of standard IWSNs for the downstream from a center node to end devices is quite less than that for upstream because main traffic for IWSNs is autonomously transmitting sensor data from devices.