## 4 Our System Design  
### Network Configurations and Graphic Representation  
Following on the principles presented in Section 3, the main idea of this paper is that the labels of entities, which can be computed automatically and efficiently from the _Channel_ relation [20, 21], can be used for routing data in SDN networks, from the entities where data originates, their provenance, to all the entities where they can flow. By using SDN configured according to the partial order security model, it is possible to constrain the flow of data in IoT systems to satisfy data security requirements. On this basis, we formulate an SDN architecture where SDN forwarding tables are set by the SDN controllers using the entities' labels. It follows from the theory presented in Section 3 that this method is general in the sense that it can be used for any network for which the data flow relation can be represented as a directed graph of entities. Our method considers a centralized IoT architecture where all data are transferred and stored on cloud platforms and accessed by user applications. We chose to work on a centralized IoT architecture with a cloud structure using SDN as communication infrastructure. Several papers in the literature propose centralized configurations for IoT security, such as [PERSON] et al. [26], [PERSON] et al. [27], and [PERSON] et al. [28]. Further, our efficient centralized algorithms can reconfigure networks dynamically as necessary; see Section 6. SDN will work very well in closed systems such as hospitals, industrial plants, smart homes, and the like since its architecture is well-conceived for scalability and efficiency. In the Cloud, a data container and a server can be two distinct entities interconnected via the network. For simplicity, we chose to represent them as a single entity. In centralized IoT systems, all devices are connected through centralized cloud servers, and communication between different devices must be achieved through these servers. ThisIoT configuration consists of three main layers: _Sensing layer_, _Networking layer_, and _Application layer_. The _Sensing layer_ consists of different types of sensors, RFIDs, and other data-collecting devices. This layer collects data from the environment and sends it to the cloud servers via centralized gateways. Entities requiring high integrity are found in this layer. The _Application layer_ involves various IoT applications that use the data collected by sensors in contexts such as healthcare systems, smart cities, etc. High-secrecy entities are found in this layer. The Cloud constitutes the IoT _Networking layer_ and all communication passes through it. The Networking layer connects IoT objects to the Internet and contains the servers used to store the data collected from the Sensing layer. Several communications technologies and protocols can be used in this layer, such as 3G/4G/5G, Zigbee, Bluetooth, WiFi to transport data from the _Sensing layer_ to the _Application layer_ on the one hand and inside the _Networking layer_ between the servers on the other hand. Our solutions are oriented towards Wi-Fi since, with this technology, every entity or object in the system will have an IPAD (or IP address) that identifies it. This simplifies our presentation, but our approach can be extended. We adapt the centralized IoT architecture to the SDN architecture; see Figure 1. The Controller will have two routers to take care of: the first router is the Cloud router, which interconnects the servers in the Cloud, implementing the _Networking layer_. The second router is the _Application router_, to which the cloud router connects, and which interconnects the entities in the _Application layer_. We also have an Access point that connects the _Sensing layer_ with the _Networking layer_, but we do not program this one, since its function is simply forwarding the data to the cloud router. These are logical devices that can be implemented by several physical devices of different types.