Coordinating heterogeneous IoT devices by means of the centralized vision of the SDN controller

Coordinating heterogeneous IoT devices by means of the centralized vision of the SDN controller Jaime Gal´an-Jim´enez1, Javier Berrocal1, Jose Garcia-Alonso1, Carlos Canal2, and Juan M. Murillo1 1University of Extremadura, Spain {jaime,jberolm,jgaralo,juanmamu}@unex.es 2University of M´alaga, Spain [email protected] Abstract The IoT (Internet of Things) has become a reality during recent years. The desire of having everything connected to the Internet results in clearly identified benefits that will impact on socio economic development. However, the exponential growth in the number of IoT devices and their heterogeneity open new challenges that must be carefully studied. Coordination among devices to adapt them to their users’ context usually requires high volumes of data to be exchanged with the cloud. In order to reduce unnecessary communications and network overhead, this paper proposes a novel network architecture based on the Software-Defined Networking paradigm that allows IoT devices coordinate and adapt them within the scope of a particular context. Keywords: Internet of Things, Situational-Context, Software-Defined Networking 1 Introduction During the last few years we have seen how data traffic has dramatically increased, and this trend will probably continue over the next few years. Some reports forecast [11] that the global IP traffic in 2020 will nearly triple the traffic in 2015. As these reports indicate, this increase is mainly due to the high penetration of smartphones and the massive use of cloud technologies [13]. This increase has a direct consequence: network infrastructure supporting this traffic needs to be improved in order to maintain acceptable levels of QoS (Quality of Service). To that end, new network equipment, higher bandwidth connections and wider mobile coverage are required [11]. Currently, most of the burden to improve this infrastructure rests on the telco operators side. This improvement, until now, has been mainly funded with the users’ quot. However, there are other actors who benefit from this infrastructure, such as applications and cloud service providers. For example, Google or Facebook are storing their users’ information in order to be able to send them personalized advertisements, getting a huge profit with that [1]. Nevertheless, they are not paying operators to improve their network infastructure. While this is currently a concern, it will become a real problem as IoT (Internet of Things) devices and WoT (Web of Things) systems are deployed. The connected smart devices are expected to be continuously sending and receiving information from cloud environments by nature. Therefore, the massive amount of data produced and exchanged by things in IoT networks brings to light the need to restructure and redesign both network and data storage systems [7]. There are new research lines trying to minimize the exhaustive tasks performed in the cloud, bringing the storage and computing of the data to near-user edge devices or even to the user’s end device, such as Fog Computing [10]. Or, for example, in [16], a distributed mobile computing model is developed, in which the information is stored and computed in the user’s mobile devices. Likewise, the Mobile Agents [9] are programs that can autonomously migrate between the nodes of a network, or different networks, resuming their execution there. In this way, passing from Cloud Computing to Edge-Fog Computing would reduce communication interactions among connected IoT devices. During the last few years, the authors of this paper have been working on the Situational-Context [8]. This concept defines a proper way to deal with the expected increase in traffic. The idea behind it is to locally analyse the contextual information that exist at a particular time and place in order to predict, in realtime, the expected behaviour of IoT devices and WoT systems. In order to apply this concept on a real networking environment, we propose to use the new Software-Defined Networking (SDN) paradigm. The centralized nature of SDN networks and the separation between data and control planes make this approach particularly appealing. However, a set of challenging issues must be faced when applying SDN on IoT networks (SDIoT, Software-Defined Internet of Things), especially the ones related to scalability (huge number of devices), heterogeneity (diversity in wireless technologies) and security (entry points for malwares). This paper proposes the Context-SDIoT network architecture, where the Situational Context concept can be easily deployed on IoT networks by means of the SDN paradigm. In this architecture, each Situational-Context is composed of a set of IoT devices that share the same spatio-temporal area and a controller that is responsible of all control decisions within that area (context). The controller is able to know, at each time, specific information retrieved from each IoT device and identify the required strategies to meet the user’s needs. With this approach, data traffic generated and exchanged among IoT devices can be computed within the scope of the proper context, avoiding unnecessary communications and coordination tasks with the cloud. To describe the proposed model and the benefits it provides, this paper is organized as follows. Section 2 motivates the proposed architecture. Section 3 details the proposed Context-SDIoT network architecture. Finally, Section 4 contains our conclusions and future works. 2 Motivation This section details the Situational Context concept, its main open issues and how SDN networks could be used to address some of them. 2.1 Situational Context During the last few years, different approaches, such as Ambient Intelligence [12] and Context-Aware [17], have been working on identifying the users’ needs and preferences. This information is then used to semi-automatically adapt the applications’ behaviour to the users’ context, improving the users experience. In the last few years, the increased computing and storage capabilities of smartphones and smarthtings, allowed us to propose a new context-aware computing model. This model is called Situational-Context [8]. The SituationalContext is a way to analyse the conditions that exist at a particular time and place in order to predict, at run-time, the expected behaviour of WoT systems. This model exploits the smart devices’ capabilities to gather, store and locally compute the contextual information in order to construct its virtual profile, and the virtual profile of its owner. Thus, the surrounding devices can reuse it to adapt themselves to the user’s preferences. To that end, the Situational-Context defines that the virtual profile of an entity (thing or person) should contain at least the following information: –ABasic Profile containing the dated raw contextual information with the entity’s status, the relationships with other devices and its history. –Social Profile. This profile contains the results of high level inferences performed over the Basic Profile. –The Goals detailing the status of the environment desired by the entity. These Goals are deducted from the Basic and Social Profiles at run-time. –The Skills or capabilities that an entity has to make decisions and perform actions capable of modifying the environment and aimed at achieving Goals. Considering environments in which there are different entities and each of them has a virtual profile, the Situational-Context can be defined as the composition of the virtual profiles of all the entities involved in a particular situation. Once the Situational-Context is composed, the ways in which the entities will better satisfy the goals are identified from the Situational-Context itself. Therefore, the Situational-Context provides a higher level of automation of smart things with people. However, this concept have some important issues that should be solved. Some of the most important ones are how the virtual profiles are shared between smart devices (since this implies the transfer of a large amount of data) and where the Situational-Context should be computed (i.e. in the end devices, in a server, in a network device) without this entailing a great overload of the network. In order to give an answer to all these issues, we propose to use SDN and SDIoT networks. Next subsection presents some of the most important challenges of using SDN over IoT environments. 2.2 Software-Defined Networks Software-Defined Networking (SDN) is an emerging networking paradigm that gives hope to change the limitations of current network infrastructures. First, it breaks the vertical integration by separating the network’s control logic (control plane) from the underlying routers and switches that forward the traffic (data plane) [20]. Second, with the separation of control and data planes, network switches become simple forwarding devices and the control logic is implemented in a logically centralized controller, simplifying policy enforcement, network (re)- configuration and evolution [18]. A fundamental characteristic of SDN is the logically centralized, but physically distributed controller component. The controller maintains a global network view of the underlying forwarding infrastructure and programs the forwarding entries (actions to be done) based on the policies defined by network services running on top of it [5]. A standardized programmable interface, namely OpenFlow [2], was adopted by the industry in order to program multiple types of forwarding devices. Next section describes the main challenges of applying the SDN paradigm on the network environment considered in this paper, i.e. IoT networks. 2.3 Challenges of SDIoT Networks SDIoT networks are able to perform customized computations according to specific network requirements. A SDN controller, which is responsible of applying the network logic in the SDIoT scenario, could be used to control the data transfer among devices and the computation of the Situational Context. Although programmability and flexibility allowed by the emerging SDN paradigm [20] on wired environments can be easily exploited on wireless networks, there are challenging tasks that must be carefully studied to let this transition be viable. The most important issues are: – Scalability and heterogeneity. One of the key points regarding the scalability is the one related to the number of coordinated controllers that are needed to satisfy the IoT demands [19]. The huge number of connected devices and their heterogeneity requires the use of a distributed scheme coordinating different physical controllers. Therefore, the proposal of a distributedcentralized control plane could be a feasible option to deal with the inherent dynamic nature of IoT networks [19]. – Security. IoT networks are more sensitive to security than traditional networks. Although the inclusion of centralized controllers with a global network view could lead to improve network performance, it can also attract the attention of attackers. In this way, novel security mechanisms must be proposed [15]. The flow-based nature of SDN forwarding, where all the packets belonging to a flow follow the same path for each source-destination pair, strengthens the importance of defining complex device-access rules based on access control lists, advanced firewalls and developing algorithms to detect specific security threats. – Mobility. Traditional implementations of SDN technology on wired networks are not very close for handling the dynamic needs of pervasive IoT applications, especially the ones related to mobility. Inherent ubiquitous nature of IoT devices results in frequent changes between access networks. Continuous negotiations between controllers as IoT devices enter and leave the network could lead to an increase in network overhead. In order to tackle the mobility issues in SDIoT networks, each controller in the network must have a global view of the mobility of these devices [14]. – Quality of Service. Maximizing the utilization of SDIoT networks requires fine-grained QoS support for differentiated application requirements. Traffic classification, prioritization and analysis of different multimedia applications for streaming become challenges to propose solutions providing acceptable values of QoS [6]. In order to satisfy these distinct QoS requirements, distributed controllers could offer smart routing, scheduling, and virtualization solutions. In this way, IoT use-case with conflicting requirements can be isolated and treated independently, providing specific network resources for each of them. Once the main challenges of applying the SDN paradigm on IoT environments have been introduced, next section describes the proposed architecture for implementing the Situational Context by means of the SDN paradigm. 3 Context-SDIoT Architecture This section proposes a novel network architecture to apply the concept of Situational-Context on a SDIoT environment. Three different approaches can be considered: –Fully-centralized solution. In this situation, a single controller is the responsible of performing all the tasks associated with a specific context. This approach allows the controller to have a (near) real-time view of the network state. Nevertheless, network performance must be analysed in terms of network overhead and controller overload. –Fully-distributed solution. This case considers that all the computation tasks are carried out by end devices in a distributed manner. This option has the drawback of the extremely limitation of end devices in terms of processing and storage capabilities (packet buffering), especially if they are sensors. It is then doubtful whether they can support such a level of programmability. –Hybrid solution. The latter case is to divide the set of actions to be done into two different subsets. Low complexity tasks could be directly carried out by end devices, whilst more complex tasks would be relegated to be done by the controller. This selection of tasks could be performed adaptively depending on the device’s resources and capabilities. With the aim of starting to evaluate the feasibility and effectiveness of these approaches, this paper focuses on the fully-centralized solution where a single controller is able to manage a context. In order to describe it, a set of concepts related to the main components of the architecture must be previously defined: – IoT device: General IoT device that has, at least, one wireless network interface, independently of the specific nature of the wireless technology. Each IoT device is able to create its Basic Profile (BP ) and its Social Profile (SP ). Besides both profiles, a set of Goals (G) and a set of Skills (S) are respectively inferred and provided by the IoT device. – Context-LAN: Local Area Network (LAN) intrinsically associated to a specific geographic area which is composed of a set of switches, access points and IoT devices that all together form a particular context. – SDIoT controller: Centralized device that belongs to a particular ContextLAN and is responsible of all control decisions among the set of IoT devices connected to the proper Context-LAN. The controller has a global network view and is able to request information about IoT devices and retrieve statistics from switches both in a proactive and in a reactive way. Figure 1 depicts the proposed Context-SDIoT network architecture. A set of heterogeneous IoT devices (e.g. smartphone, air conditioner and lighting equipment) are connected to the Context-LAN depicted by the blue area using specific wireless technologies. Moreover, the logically centralized SDIoT controller is able to request and obtain specific information from the set of IoT devices that are connected to the Context-LAN it manages. In reality, physical connections are made between the controller and the different access points (e.g. WiFi, WiMAX, cellular) and switches in the Context-LAN. Green dashed lines represent secure channels connecting the SDIoT controller and the network equipment and OpenFlow protocol [2] is used for this purpose. One step further, Figure 1 also shows the full process that is carried out when a new IoT device joins a particular Context-LAN. When a new IoT device enters an area that is managed by a SDIoT controller 1 , there is an association between the proper IoT device and one of the different types of access points belonging to the Context-LAN 2 . Once this association has been performed, an OpenFlow notification message is generated by the access point and sent back to the controller in order to let it know that a new device has been connected. Therefore, an unique id must be included in the payload of such message 3 . Finally, the SDIoT controller is able to gather information from the newly joined device to know its virtual profile, as well as its goals and skills. In order to do this, the controller creates a new OpenFlow message directed to the same access point requesting information related to the IoT device with the same id that was included in the previously received message 4 . Note that mobile IoT devices are prone to move quickly between ContextLANs, leaving the one they are connected to and entering new ones, in a short period of time. To reduce network overhead and save the communication cost, when a previously associated IoT device enters its Context-LAN again, the controller does not need to initiate another joining process and request information from that device. Instead, the controller can localize the corresponding stateful information using fast lookup on its state table and update it only if necessary. Context-LAN Home comfort Target IoT device (n) entering the context IoT device n connected 1 2 3 AP Context-LAN Home comfort AP Context-LAN Home comfort AP Notify IoT device n 4 Context-LAN Home comfort AP Request info of IoT device n Figure 1: Context-SDIoT network architecture. IoT device joining process. At this point, we define a threshold value, namely assoc thresh, that refers to the maximum time that the stateful information of a particular device remains in the controller table. After expiring, this entry is removed and if the IoT device re-enters the Context-LAN again, it would be necessary to start a new joining process. The value for assoc thresh is dynamically adjusted by the controller based on the history of the particular Context-LAN it is responsible for. With the present work, our aim is to position an initial approach where the concept of Situational-Context is included in the IoT networking scope. Through the use of the emerging SDN paradigm, the SDIoT controller will be able to satisfy the set of goals of each IoT device within the proper context. For this purpose, both the set of goals and the set of skills of each IoT device must be known by the controller at each time. In this way, specific applications according to these skills and goals can be optimally implemented and executed by the controller when necessary. In the following, the generic problem of managing a Context-LAN by a SDIoT controller is formalized and a use case related to home comfort is finally explained. 3.1 Problem Formulation Let us consider a generic Context-LAN, L= (D, C) with a set of di∈Dconnected IoT devices managed by a single SDIoT controller, C. Each IoT device, di∈D, is a 4-tuple of type di={BPi, SPi, Gi, Si}, with BPias the Basic Profile of i-th IoT device, SPias its Social Profile,Gi={gi 1, gi 2, ..., gi k}as the set of Goals that device dipursues and Si={si 1, si 2, ..., si p}as the set of Skills that di is able to perform, respectively. Note that, although each device has, at least, a BPi, any of the three remaining components could not be required by a specific IoT device, i.e. SPi=∅,Gi=∅,Si=∅. Being S={S1, S2, ..., Sn}the full set of skills retrieved from the nIoT devices connected in L, the controller must be able to assess |S|different objective functions. If a generic skill jof a device diis selected at time t,si j, the specific objective function is defined as follows: min σ X di∈D gi j(1) where gi jis the goal jof device direlated to skill si j, taken as input. The objective function for a particular skill (eq. 1) is therefore to minimize the standard deviation among the values of the set of goals related to that skill in the network. The result is finally sent by the controller to the involved devices through the use of specific OpenFlow messages and the desired goals are achieved. 3.2 Use case: Home comfort Context-LAN In the following, a particular use case is described. Consider the Context-LAN of Figure 1 related to home comfort. Network description could be given by L= (D, C), with D={d1, d2, d3, d4, d5}: –d1: Smartphone 1 with only one goal G1={(g1 1=Comfort temperature = 22◦C)}, and no skills, S1=∅. –d2: Smartphone 2 with two goals G2={(g2 1=Comfort temperature = 20◦C); (g2 2=Luminance = 100 lux)}, and no skills, S2=∅. –d3: Smartphone 3 with two goals G3={(g3 1=Comfort temperature = 21◦C); (g3 2=Luminance = 300 lux)}, and no skills, S3=∅. –d4: Air conditioner with no goals, G4=∅, and one skill, S4={(s4 1= Temperature control)}. –d5: Lighting equipment with no goals, G5=∅, and one skill, S5={(s5 1= Luminance control)}. As we can see, there are two different skill functions to be managed and executed by controller C:S={S4, S5}={s4 1, s5 1}. The first one, s4 1, is provided by the air conditioner, d4, and sets the adequate comfort temperature according to goal values, g1 1, g2 1, g3 1, obtained from the three different smartphones. After performing the assessments, Csends the resulting value (temp = 21◦C) to d4, which finally sets the temperature in the Context-LAN L. The latter skill, s5 1, is managed by the lighting equipment and sets the average luminance required by smartphones 2 and 3 (d2and d3), since d1does not have the goal of setting the luminance among its set of goals, G1. As in the previous case, resulting luminance value (200 lux) will be sent by Cto d5in order to set the desired luminance. In order to ease the comprehension of the proposed architecture, the use case explained above employs the average value in the objective function for the two skills considered. Obviously, this simple metric can be used in specific situations, but real IoT environments would require more complex algorithms which would take into account the importance of each IoT device and the role of each user. 4 Conclusion and Future Work This paper proposes the application of the Situational-Context concept on IoT environments by means of the SDN paradigm. The flexibility and programmability offered by SDN can be effectively exploited to reduce unnecessary interactions between IoT devices and the cloud. Specifically, we propose the Context-SDIoT architecture, where each situational context is composed of a set of IoT devices that share the same spatiotemporal area and a controller that is responsible of all control decisions within that area (context). The controller is able to know, at a particular time, specific information retrieved from each IoT device (profile, goals and skills) and identify the required strategies to meet the user’s goals. With this approach, data traffic generated and exchanged among IoT devices can be computed within the scope of the proper context. As future work, the proposed architecture is going to be implemented on wireless network simulators to evaluate its performance under different scenarios. In particular, we believe that the recently added OpenFlow module for OMNeT++ [3] makes this simulator particularly appealing to be used for a prototype implementation. One step further is to evaluate our proposal with realistic experiments by exploiting ORBIT wireless network testbed [4], or even customizing a set of Raspberry Pis to create and evaluate small-sized Context-LANs. Acknowledgements This work was supported by projects TIN2014-53986-REDT, TIN2015-67083-R and TIN201569957-R (MINECO/FEDER, UE), by the Department of Economy and Infrastructure of the Government of Extremadura (GR15098), and by the European Regional Development Fund. References 1. Google Financial Tables - Investor Relations (December 2016), https://abc.xyz/ investor/index.html 2. OpenFlow Switch Specification. Version 1.5.0 (2016), https:// www.opennetworking.org/images/stories/downloads/sdn-resources/ onf-specifications/openflow/openflow-switch-v1.5.0.noipr.pdf 3. OMNeT++ Discrete Event Simulator (2017), https://omnetpp.org/ 4. Open-Access Research Testbed for Next-Generation Wireless Networks (ORBIT) (January 2017), www.orbit-lab.org