## 4 Characterising SDN-Based IoT Architecture  
### The Architecture of SDN Based IoT Networks  
As summarised in Table 3, IoT traffic messages are generated either periodically or occasionally by the IoT applications. This could be regarded as periodical access and random access in the SDN infrastructure. The diversity of IoT applications demands a well-directed transmission route, or so-called user-centric services, to achieve a better performance. In order to process these requests separately, SDN slicing provides an effective solution. As the entire network is centrally controlled, the SDN controller could logically split a physical underlying network tunnel into multiple Virtual Tunnels (VTs). Each VT is independent and has its optimisation of a specific use case. Note that an issue in one VT will not impact other VTs [46]. As there will be various management policies over the same channel, SDN has an inherent advantage to do that due to its decoupled architecture [47]. To improve the efficiency of utilisation, the SDN controller also needs to generate and adjust flow entries for different services on the common physical tunnel. Meanwhile, unnecessary features are removed and essential factors are enhanced according to the service type [48]. To simplify, a basic data plane of SDN supporting IoT consists of three entities:  
* IoT Data Aggregators (IoT-DAG): There are various IoT subscribers including attackers. A client collects data from IoT devices (wired or wireless sensors). These data could be originating from different applications. The client behaves as an upper level node accessing the SDN switches. In this article, we use Raspberry Pi (RPi) as the IoT-DAG, which is a mini-computer running an operating system similar to Linux. Although portable in terms of size, RPi is capable of processing data having graphical interface and could connect to the Internet via Ethernet cable or WiFi. Therefore, users can reprogram or configure it remotely, which is crucial to the IoT applications [49]. Another one is Odroid that supports Ubuntu and Android system with a more powerful RAM compared to other devices with the same size, it is even equipped with a heat sink [50]. These devices have some common points that meet IoT requirements: cheap, small size, easy-to-use, low energy consumption, open-source and adequate processing ability. * SDN Switches: The support from a controller to the SDN switch is essential, although the switch can still work with its last configuration. As a legacy switch without a controller, SDN loses its power. Thus, the controller acts as a coordinator to instruct a switch and redirect different kinds of data to the destination via SDN. Zodiac-FX is the one we use in the test. It is a small OpenFlow switch that is designed to be used in the laboratory providing real traffic on the physical hardware. It has open-source firmware, simple setup procedure and CLI access. Zodiac-FX supports OpenFlow 1.0 and 1.3 and can obtain flow entries from controllers, such as Ryu [51]. This is a suitable choice to emulate SDN-based IoT networks to meet the aforementioned IoT requirements. * IoT Data Servers (IoT-DS): Each IoT application has an independent server, which only processes its type of service. Both scheduled and random access share the same server. Google smart home is a typical random access service, it stores devices per room first and uses this information to create a database, called Home Graph (HG) [52]. Then, the Google Assistant (GA) on the server side will process the user's request according to the HG. Google Home collects command from the user and sends it to the GA. The GA then tries to recognise the request and find relevant devices in the HG. Finally, the GA executes the operation via Google Home. Another instance is Amazon Website Service (AWS) IoT; with the aid of a cloud network, it simplifies the connection and management of enormous amount of IoT devices supporting data collection and complex analytics for reacting to the real-time actions [53].