## 8 Simulation and Implementation of the Controller  
The SDN implementation of our hospital example has been tested using the Mininet network emulator. Mininet is a network emulator that runs a collection of end hosts, switches, routers, and links on a single Linux kernel. It uses virtualization to make the system look like a complete network, running the same kernel, system, and user code. Mininet hosts behave just like real machines that can run arbitrary programs. The programs can send packets through what appears to be a real Ethernet interface, with a given link speed and delay. Packets get processed by what look like real Ethernet switches or routers, as in our case. In summary, Mininet's virtual components (hosts, switches, links, and controllers) are created using software rather than hardware, and their overall behavior mimics to the one of discrete hardware elements. It is usually possible to create a Mininet network that represents a hardware network, or a hardware network that represents a Mininet network, and to run the same binary code and applications on either platform. Mininet is particularly adapted to simulate SDN networks, and also is efficient and easy to use. For the choice of controller, several reasons led us to use the Ryu controller of [PERSON] et al. [32, 33]. First, we considered the comparison study documented by [PERSON] et al. [34]. Second, there is the fact that Ryu provides software components with well-defined APIs that make it easy for developers to create new network management and control applications. Third, Ryu is the most suitable controller to use in a Mininet environment since it supports OpenFlow 1.0, 1.2, 1.3, and 1.4. Fourth, because Ryu is Python-based, it is easier for Ryu to develop new network management and control applications in comparison with other controllers. And finally, [PERSON] et al. [32] and [PERSON] and [PERSON] [35] have reported on testing the performance of the Ryu controller in many simulation scenarios and have concluded that the controller is very suitable for prototyping and experimentation for research, experimentation, and demonstrations. To create our implementation configuration, we have used the Python API to write a configuration Python script. First, we had to create an empty network and add nodes or entities to it. To create this empty network, we manually created a default controller called _Controller c0_. This default controller was replaced later with our Ryu controller. Figure 15, generated by Mininet, shows our example's topology created in the simulation environment. Note that in the figure, _Router2_ refers to the _AppRouter_. and _r1_ refers to the _AccessPoint_. The table of Figure 16 gives the meaning of the hostnames presented in the topology of Figure 15.  
The simulations that were done aimed to test the integrity and secrecy requirements; in other words, it was tested that by using our labeling tables and derived routing tables, data flows would only arrive at authorized entities. The case of multiple flows was also tested. Parameters such as the performance of the controller, scalability, etc. have been tested in other SDN-related work already mentioned, see [PERSON] et al. [32], [PERSON], and [PERSON] [35]. After implementation, the data flow in the network was simulated. We use the _ping_ command to see if the results match the security requirements expressed by our partial order. Figures 17 and 18 show examples of the results obtained. Figure 16: Entities correspondence in the simulation. Figure 15: The simulated topology generated by Mininet. In Figure 17, we can see some results for a defined scenario. We have a connection established between entities in the case of authorized data flow \(J\) to \(B\), where \(J\) represents _PulseDetect(Sally)_ and \(B\) represents _Nurse2 Wkstn_. Another scenario, presented in Figure 18, shows an unauthorized flow where there is no data flow from \(J\) to \(A\), where \(J\) represents _PulseDetect (Sally)_ and \(A\) represents _Nurse1 wkstn_.