Centralized QoS Routing Model for Delay/Loss Sensitive Flows at the SDN-IoT Infrastructure

Mykola Beshley,Natalia Kryvinska,Halyna Beshley,Mykhailo Medvetskyi and Leonard Barolli

1Department of Telecommunications,Lviv Polytechnic National University,Lviv,79013,Ukraine

2Department of Information Systems,Faculty of Management,Comenius University in Bratislava,Bratislava,82005,Slovakia

3Department of Information and Communication Engineering,Faculty of Information Engineering,Fukuoka Institute of Technology(FIT),Higashi-Ku,811-0295,Fukuoka,Japan

Abstract:The rapidly increasing number of Internet of Things(IoT)devices and Quality of Service (QoS) requirements have made the provisioning of network solutions to meet this demand a major research topic.Providing fast and reliable routing paths based on the QoS requirements of IoT devices is very important task for Industry 4.0.The software-defined network is one of the most current interesting research developments,offering an efficient and effective solution for centralized control and network intelligence.A new SDN-IoT paradigm has been proposed to improve network QoS, taking advantage of SDN architecture in IoT networks.At the present time,most publish-subscribe IoT platforms assume the same QoS requirements for all customers.However, in many real-world scenarios of IoT applications, different subscribers may have different E2E delay requirements.Providing reliable differentiated services has become a relevant problem.For this we developed a technique for classifying IoT flows with the individual subscriber recommendation on the importance of certain parameters for particular classes of traffic taken into account.To improve the QoS for mission-critical IoT applications in large-scale SDN-IoT infrastructure,we focused on optimizing routing in the SDN.For this purpose, a centralized routing model based on QoS parameters and IoT priority flow for the SDN was proposed and implemented.We have compared the proposed routing model with the state-of-art deterministic multiconstrained centralized QoS routing model (DMCQR).The developed centralized routing model in comparison with the known DMCQR flow routing achieved better balance of channel resources load due to rational choice of transmission paths for different traffic.And it was possible to reduce up to 3 times the average delay of real time flows service from end to end, for which with the existing DMCQR routing model the permissible delay rates were not met.

Keywords: Internet of things; software defined networking; quality of services; routing; internet of video things

1 Introduction

The trend of the Internet of Things (IoT) is becoming more and more popular now in the Industry 4.0 [1].Briefly it can be described as follows:an increase in the number of devices that interact not only with users but also with each other [2].The huge number of devices will enable services from a wide variety of sources such as home appliances, surveillance cameras, monitoring sensors, actuators, displays, vehicles, machines, and so on [3].The rapid emergence of the IoT takes advantage of the promises of many important new benefits, but at the same time creates some potential problems and issues [4–6].To support the huge number of connected devices with heterogeneous characteristics, the IoT communication infrastructure needs new architectures and devices that can accommodate the growing IoT traffic with the guarantee of a specific QoS level [7–9].

IoT will allow the development of applications in many different domains, such as home automation, industrial automation, medical aids, traffic management, and many others [10,11].These applications have a range of QoS requirements, which can be typically categorized as best effort (no QoS), differentiated services (soft QoS) and guaranteed services (hard QoS), especially for a mission-critical IoT applications [12].The authors [13] considered five important missioncritical IoT applications and characterize them based on several different requirements such as factory automation, process automation, smart grids, intelligent transport systems and professional audio.For example, process automation includes applications for monitoring and diagnostics of industrial elements, and processes such as heating, cooling, mixing, stirring, pumping, etc.Therefore, End-to-End (E2E) delay requirements for such IoT services range from 50 to 100 ms with the available Packet Loss Ratio (PLR) up to 10-3.

The network infrastructure is a critical component of the ecosystem for a mission-critical IoT application.In order to provide strong QoS for IoT applications, it is necessary to provide suitable mechanisms at each layer of the IoT infrastructure, as some factors, such as E2E latency, are very important [14–16].A delay in any layer can lead to unacceptable QoS for safety critical applications, such as automated driving systems which need constant feedback to maintain control.Such ultimate results are the main reason why strict compliance with QoS requirements is so necessary in the mission-critical IoT.This is also part of why designing for mission-critical IoT platform is so complex.Nowadays, most publish/subscribe IoT platforms suppose that there are equal QoS requirements for all clients.However, in many real-world IoT applications scenarios, different subscribers may have different E2E delay requirements.How to provide reliable differentiated services has become an relevant problem.

In addition, the IoT communication infrastructure has to be energy efficient, cost-effective,flexible and scalable to provide IoT services with different quality of service requirements [17–20].To develop a more flexible and scalable network, the Software Defined Networking (SDN)paradigm has been proposed in recent years [21–24].The SDN provides simplified network management by separating the control plane from the data plane [25–27].Thus, with this programmable and centralized control plane, it is possible to monitor real time network behavior and flexibly manage network traffic, which also makes SDN one of the key technologies in SDN-IoT applications.So, approaches based on the SDN in the context of IoT have recently attracted some attention [28–30].The SDN-IoT infrastructure is depicted in Fig.1.

Figure 1:SDN-IoT infrastructure

Special attention is paid to the means of routing and distribution of flows under high load conditions to ensure the specified parameters of the quality of service within the network management.In this regard, the development and implementation of SDN solutions require improvements to existing routing protocols and load-balancing mechanisms [31–33].Analysis of the known routing protocols has a significant disadvantage for they provide the calculation of the shortest path by only one, however composite metrics [34].Thus, the necessary numerical values of one of the key QoS parameters of a particular flow of a certain client are not guaranteed.On the other hand, these routing protocols generally cannot ensure a universal and satisfactory solution that meets the requirements of heterogeneous large-scale IoT networks [35].The most common is the flow model of routing with load balancing to minimize the coefficient of maximum channel utilization [36].The study of this model for SDN showed that load balancing by the criterion of channel utilization ratio does not allow improving the QoS level in all cases.Therefore, it is recommended to change the criterion underlying the optimization of the load balancing process in such a way as to maximize the values of the basic QoS values [37] when addressing the routing and load balancing task in the SDN [38].

In order to address the abovementioned challenges, this paper focuses on creating a new costeffective and low-energy customizable platform based on SDN architecture.It can adapt its configuration to meet the QoS requirements of target IoT applications.Our principal contributions in this paper are summarized as follows:

? We developed a technique for classifying IoT flows with the customers recommendation on the importance of certain parameters for particular classes of traffic taken into account.

? We proposed and realized a centralized routing model based on QoS parameters and IoT priority flow for SDN to enhance QoS for mission-critical IoT applications in a large-scale SDN-IoT infrastructure.

? We have compared the proposed routing model with the state-of-art deterministic multiconstrained centralized QoS routing model (DMCQR)

The paper is organized as follows.Section 2 presents a brief review of the related works.Section 3 introduces the implementation details of our enhanced QoS-aware routing model in the SDN section of the IoT platform and evaluates our model with respect to state of the arts DMCQR.Finally, we conclude in Section 4.

2 Related Work

Routing in SDN based IoT infrastructure has recently become a hot topic of research and has generated so much scientific interest [39–47].A summary of the related work is shown in Tab.1.

Table 1:Related work on routing in SDN-IoT infrastructure

To the best of our knowledge, the studies on QoS-aware routing for mission-critical IoT applications in the SDN based IoT platform are still very limited in literature.Most of the existing scientific papers on routing in SDN-IoT still have a number of significant shortcomings, are only theoretical and difficult to implement in practices.Also, when analyzing the scientific papers, we have not found approaches to provide QoS for the mission-critical IoT applications in conditions of high network load with the presence of subscribers to the same IoT applications of topics with different QoS requirements.

3 Enhanced QoS-Aware Routing Model in SDN

3.1 Centralized Routing Model Based on QoS Parameters and IoT Priority Flow for SDN

The paper proposes an advanced model of routing that allows balancing the load on the criteria of minimum/maximum network channel load and service quality for each flow in SDN.There is developed a technique for classifying IoT flows with the recommendation on the importance of certain parameters for particular classes of traffic taken into account.Tab.2 show the requirements for QoS of existing services operating within the Internet of Things [48] (IoT automated emergency call—A, Real time Monitoring temperature—B, Real time Internet of Video Things (IoVT)—C, IoT-Alert (Photo/text/Email)—D, Un Real time IoVT (Video on Demand)—E, Un Real time IoVT (720p60)—F, Un Real time IoVT (1080p60)—G).The primary goal of QoS is to provide priority, including dedicated throughput—C, delay—T, jitter—J, packet loss—P(required by some real-time and non real-time traffic).We also introduce two additional criteria for the classification of IoT flows the first criterion is the sensitivity to the mixing of packet—Pmand the second criterion is the priority of the IoT subscribers–Cp.

Table 2:Requirements for QoS of certain IoT applications

To calculate the relative priority of a flow for a particular path, we defined the relative coefficients for each flow.The relative coefficients are the ratio of the minimum values of the service quality parameters to the current values obtained from the network monitoring.

The relative coefficient of packet loss—p, packet delay—t, packet jitter—j, throughput—c,sensitivity to the mixing of packets—pmand priority of the subscribers—cpare defined as shown in Eq.(1):

The results of the calculations are shown in Tab.3.

Table 3:The matrix of relative coefficients

Tab.4 is filled with numbers 1–3, which correspond to low, medium, and high significance of the QoS parameters, respectively [49].

Table 4:The matrix of importance of QoS parameters

These parameters can be specified by the operator.Moreover, each subscriber is assigned a priority for each type of traffic.If the priority is not explicitly specified in the service agreement,then the IoT subscribers are assigned the lowest priority of all possible by default.

Thus, the relative priority for each category of IoT applications (services) is determined by Eq.(2).

wherePIoTk—the relative priority of thei-th IoT service;

k—IoT service type number;

m—number service quality parameter;

Xkm—relative priority of parametermfor IoT servicek;

Ykm—the importance of parametermfor IoT servicek.

The final result of this formula is a fraction within the range from zero to one.The greater value, the higher priority of an IoT flow.The formula can be applied to any number of flows and various quality requirements for the IoT service.

Considering above technique of prioritizing IoT flows, we divide them into three categories.The first type flows of should be delivered optimally with respect to the criterion of cost, which considers the following quality of service parameters:delay and jitter.Such flows are very sensitive to delay and jitter in the mission-critical IoT applications, so multi routing is forbidden for them,that is the whole flow can be transmitted one path only.The second type flows are less sensitive to the time parameters of the QoS, and therefore it is allowed to balance such flows.However, when balancing, there is a limit on the minimum sub-flow size.This constrain is essential because the second kind flows are usually TCP flows.They are sensitive to loss and mixing of packets, and as the number of sub-flows increases their size decreases, so the probability of loss and mixing due to multi routing increases.In this case, the delivery of the second types flows is guaranteed with QoS parameters within acceptable limits.The third type flows can be delivered by any routing with no guarantee of quality of service.Therefore, such flows are used to load low-load paths and to balance the load distribution between channels in a network.

When the network is operating in normal mode, without overload or bottlenecks, the monitoring system polls the network devices at a consistently long interval.In particular, the monitoring system polls network interface loads, switch flow table loads, and switch central input buffer loads that identify interface overloads.The monitoring system polls nodes with a certain interval of time and monitors the time parameters of the flows of the first category.In case of average growth in interface load, transmission delay and jitter, the system switches to the state of close monitoring of the specified interface and increases the intensity of delay measurement.In addition, when the interface load level reaches 0.9, the system starts polling the device buffer loads.

The developed monitoring system facilitates the implementation of this approach through adaptive monitoring of the used resources of channels and devices.The search for the optimum path is based on the mathematical theory used to solve the two well-known problems:the Multi-Commodity Flow Problem and the Constrained Shortest Path Problem.The main goal is to find the optimum set of paths in a network for all flows with a minimum total cost.The main constrain is that the total flow rate through a channel cannot exceed channel throughput.

Our model combines both of the abovementioned problems and allows finding the shortest path for each flow, subject to the given constraints.Suppose we have a network of nodes where each channel (link) is characterized by a delay, a loss and a channel throughput.In addition, each path is characterized by the cost calculated as a weighted sum of delays and packet losses.The model assumes that for each type of service/traffic there is a set of flows that can have completely different input and output nodes in the network.The goal is to find a set of optimum network paths for each flow with the minimum cost subjected to certain constraints, in particular such as the maximum delay, packet loss, and available link throughput.

Suppose a network is represented by the graphG=(V,E), whereVis the set of nodes, andEis the set of arcs between each pair of nodes.The arcs, that is, the links, are characterized by available channel throughput, delays, packet loss, and the cost of transfer per unit flow.As a result, the cost can be calculated by following Eq.(3):

whereθandξ—the weighs for delay and loss, respectively.

This formula allows adjusting the cost of the path with respect to either delay or loss of packets for a particular flow.This allows adjusting these settings to meet the quality requirements for each flow.For example, multimedia traffic has restrictions on end-to-end delays, so one can setθ=1 andξ=0 to take into account the delay only.Each individual flow k is identified by a relative priorityPIoTk, whose value lies within the range from zero to one.The set of different IoT traffic flows to be transferred over the network is denoted byK.Each flow is characterized by five parameters:

Gxk—the node (host) where thek-th flow enters the network;

Gyk—the node (host) where thek-th flow leaves the network;

fk—the rate of thek-th flow that must be delivered from the input node to the output one;

≥0—the maximum allowed packet loss for thek-th flow;

0—the maximum allowed delay for thek-th flow.

The goal of optimization is to path all flows in the network through the paths with the minimum cost.

Sets:

nodes:n∈V;

arcs:(i,j)∈E;

channels (links):(i,j)∈E∪(j,i)∈E;

Variables:

0 ≤≤fk—the data volume of the k-th flow passing through the link(i,j).

Parameters:

bij≥0—available link throughput(i,j);

0 ≤ρ≤1—the maximum channel load (link utilization) in the network;

0 ≤r≤1—relative cost priority over the maximum channel loadρ;

Cmax≥0—the maximum link throughput;

cij≥0—channel cost(i,j)calculated asθ·dij+ξ·pij;

θ—weight for delay;

ξ—weight for packet loss;

Gxk∈V—source of thek-th flow;

Gyk∈V—destination of thek-th flow;

fk—the rate of thek-th flow;

pij≥0—actual packet loss in the link(i,j);

dij≥0—actual link delay(i,j);

Bk≥0—the throughput required for thek-th flow.

The routing parameters are controlled based on the relative priority of a flow, which is calculated according to the technique presented above in this section.All values of the relative priorityPIoTkof a flow are within the range from 0 to 1.Let us introduce the parametersTCHighPriority∈TCandTCBestEffort∈TC, with the conditionTCHighPriority ＜TCBestEffort.The parameterTCHighPrioritycontains the relative priority which the relative prioritiesPIoTkof all other flows are compared with.If the relative priority of a certain flow is greater thanTCHighPriority,then the flow belongs to the first category and has high priority.This means it cannot be split into sub-flows for load balancing.If the relative priority of the flow is less thanTCHighPriority, however larger thanTCBestEffort, then the flow belongs to the second category and has an average priority.This means the flow can be split into sub-flows and choose for them the paths with the quality of service no lower than the shortest available path.Such flows have a limitation that determines the minimum volume of a sub-flow.This allows controlling the levels of redistribution of sub-flows in the network to avoid packet mixing for the TCP flows.The quality of service is not guaranteed for all the flows with the priority lower thanTCBestEffort.They can be split into sub-flows of arbitrary volume.For these sub-flows, the paths with minimum channel load are selected.

The objective function (4) minimizes cost with respect to the parameters of the quality of service in links, as well as with respect to the coefficient of the minimum/maximum load of links,which depends on the type of relative priority of a flow.

Constrain in Eq.(5) corresponds to the conservation of the flow

Constrain in Eq.(6) takes into account the allowed level of flow distribution with respect to its relative priority:

whereBLandBHare the minimum link throughput of sub-flows when balancing the main flow of the second and third category, respectively.

The following two constraints in Eqs.(7) and (8) consider the maximum allowed E2E packet loss and delay, which should not exceed critical values,, for a flow with relative priority k.In the case of routing of the third category, these parameters are given the maximum possible value:

Inequality in Eq.(9) imposes a constrain on the available throughput of each link, taking into account all the flows k through these links.Moreover, this constrain is lower in case of routing flows of the second and the third categories, which causes their transmission in ways with low loading efficiency and with poor quality of service:

The last constrain in Eq.(10) establishes the range of the variable and ensures that the variable acquires values within the flow rate:

The proposed mathematical model allows setting the maximum allowed packet loss and delay for the first category flows.These values are essential for choosing the best path for the QoS criterion.By using weights, one can match the weight of each flow based on its requirements.On the one hand, one can set the maximum allowed loss and delay and, as a result of solving a linear programming problem, obtain a path with the minimum transfer cost that meets the requirements of the QoS parameters.On the other hand, one can change the maximum allowed packet loss and delay, then recalculate the optimum paths to find the path that ensures the required quality.

Let us analyze the structure of the communication network that consists of theNnetwork devices.Numeric values of the metricW(i,j)can be presented as adjacency matrixW:

It is worth mentioning that the matrix of parametersWis not symmetric(W(i,j)W(j,i)).Minimization of target function metricW(i,j)that can be under several constraints or limits is called multi criteria optimization.The main difficulty encountered in solving problems of this type is the ambiguity of the optimal solution at the point where one of the criteria reaches its maximum, while the other may be far from not only the maximum, but even from any arbitrarily admissible value.Finding a metric by the “ideal point” method requires that all values have the same dimensionality.To do this, let us model the channel characteristics as follows:

? for the number of lost packets

whereNi,jis a number of received packets,Mi,jis a number of sent packets andMi,j ＞0

? for the flow delay

Thus, the metric based on the two parameters can be calculated as:

whereθandξare the weight coefficients that change their values in the range between 0 and 1,and their sum must be equal to 1:

Changing the values of weight coefficients in the metricW(i,j), we create an apparatus for controlling the value of a particular parameter when evaluating the channel characteristic from nodeito nodej.

In terms of mathematics, the “ideal point” is the one that has coordinates that correspond toDmin,Pmin, under the fixed weight coefficientsθandξ.

3.2 Experimental Results and Analyses

This part describes the implementation of our novel centralized routing model based on the multiple QoS requirements and IoT priority flow approach described in Section 3.1.The mathematical routing model is implemented as an external module on top of the Floodlight Open SDN Controller.This module is implemented in Java Programming Language.To solve the problem of finding the optimum path in the SDN, we also used AMPL (A Mathematical Programming Language) and the CPLEX optimizer [50].

For our experimental tests, we developed a network topology in the Mininet emulator.This topology composed of 7 Open vSwitches, 1 the Floodlight SDN controller and 6 IoT traffic generators (G1–G6).Link throughput between all nodes for all ports is set equal to 100 Mbps.The experimental SDN testbed is depicted in Fig.2.

Figure 2:SDN topology considered for experiment

For the first time we tested the average packet delayvs.link utilization of the developed SDN switch ports (Fig.3).For this we also used a traffic generator, iperf, to generate traffic and transfer from host to client.The load was generated from 10 to 100 Mbp in 10 Mbps steps.

Figure 3:Average packet delay vs.link utilization in SDN

During the experiment, IoT traffic was generated in the network using a multi-service traffic generation system proposed in paper [51].The matrix of requirements Cijfor link throughput in Mbps between nodes is given below.

Node No 7 is intermediate (it represents the aggregation level), so no IoT devices (servers) are connected to it.According to the matrix of requirements, the list of flows for all traffic categories was generated.A set of subscribers and the IoT services they use are generated for the channel(link) throughput of 100 Mbps.The list of flows for 9 subscribers is given in Tab.5 (Cis the link throughput, Mbps;Cpis the priority of IoT subscribers,PIoTkis the relative priority of the i-th IoT service).

Each subscriber uses a specific set of IoT services.In case an empty cell at the intersection of a column and a row, this service should be considered as the one with no guarantee of quality of service if a subscriber uses it.All other IoT services have throughput requirements and service parameters for a particular user secured by a service agreement between a subscriber and the network operator.As can be seen from Tab.4, each subscriber is assigned a priority within the appropriate priority range for a particular type of service.This generation is carried out for each pair of servers used to generate subscribers’load.

The next step was to calculate the relative priorities of IoT flows, taking into account the classification of service categories proposed in Section 3.1 of the paper.

For the first category of services (mission-critical IoT applications), which determines realtime flows that are extremely sensitive to fluctuations of time belongs the following ones:IoT automated emergency call (A), monitoring temperature (B), real time IoVT (C).

The results of the calculation of the relative priorities for all the subscribers according to the technique improved in the 3.1 section of this work, are given in Tab.5.

Table 5:Relative flow priorities based on subscriber’s priority and its IoT QoS requirements

We have compared the proposed routing model with the deterministic multiconstrained centralized QoS routing model (DMCQR) presented in work [45].

To verify the effectiveness of the proposed solutions for mission-critical IoT applications at high network loads was used real time IoVT (Internet of Video Things) service, broadcasting video from the server G6.The network is filled with IoT traffic in accordance with the requirements given in the above matrix generated by the IoT multiservice traffic generators G1 to G6 connected to 6 OvS switch.

As a result of the functioning of DMCQR, the network was filled with background multiservice traffic generated by IoT devices.All paths for all requirements are given in Tab.6.

Table 6:Paths of background IoT traffic according to the DMCQR

The next step was to generate load with only the real time IoVT service from the G6 IoT traffic generator.As a result of operation of the DMCQR, the paths for IoVT flows are selected as shown in Tab.7.

Table 7:Paths of real time IoVT according to the DMCQR

The network awareness module can use OpenFlow to send HTTP requests in order to obtain real-time link throughput usage.The histogram of link utilization was obtained when using the DMCQR and is depicted in Fig.4.

Figure 4:Links utilization in SDN testbed according to the DMCQR model

As a result of routing with the DMCQR model, unbalanced loading of links occurred in the network.Particular attention should be focused on link 4-6 which has significant delays and a high probability of packet loss due to insufficient link throughput.The links 5–6 and 6–7 are in a state near overload with a high probability of delays for the real time IoVT flow.In addition,there are no alternative transmission paths with sufficient throughput for a 9 Mbps flow from G6 to G4 hosts.Therefore, according to the DMCQR approach, the optimal path for an IoVT flows of 9.05 Mbps from G6 to G4 on the basis of QoS criterion is path 6–4.

We have a detailed analysis of the IoT flows leading to overload of link 4–6 according to the DMCQR model.The total load from the background multi-service IoT traffic according to Tabs.5 and 6 is calculated as follows.

f(G2→G5)=F3+B2+F4+D2+D7=3.99+1.01+5.5+1.6+1.9=14 [Mbps]

f(G4→G5)=F2+C5+D5+A2+D9+D2=5.57+2.15+1.68+0.19+1.81+1.6=13 [Mbps]

f(G4→G6)=G7+A2+A3+C6+A6=8.3+0.19+0.16+2.17+0.18=11 [Mbps]

f(G5→G2)=G8+C9+B8+B3+A5=12.98+2.42+1.09+0.16+1.17+0.18=18 [Mbps]

f(G5→G4)=F7+A3+B8+B4=5.5+0.16+1.09+1.25=8 [Mbps]

f(G6→G2)=G6+B3+A6+A3=10.49+1.17+0.18+0.16=12 [Mbps]

f(G6→G4)=G4+F3+A2+A4=10.63+3.99+0.19+0.19=15 [Mbps]

The load in link 4-6 generated by background IoT traffic and the load in channel 4–6 generated by background IoT traffic and additional real-time IoVT traffic are depicted in the Figs.5 and 6 respectively.

The total load from the real time IoVT service generated by IoT traffic generator G6 according to the Tabs.4 and 6 is calculated as follows.

Figure 5:The load in link 4–6 generated by background IoT traffic

Figure 6:Load in channel 4–6 generated by background IoT traffic and additional real-time IoVT traffic

According to the analysis we can see that the load in link 4–6 is created by multi-service IoT traffic.This multiservice traffic also includes the real time IoT flows (IoT automated emergency call (A), monitoring temperature (B), real time IoVT (C)) for which it is necessary to provide the allowable E2E delay.The E2E delay of IoT flows passing through a link can be defined by Eq.(14).

We estimated the E2E delay for background multi-service IoT traffic passing through overloaded link 4-6 as follows.

DE2E(G2→G5)=d24+d46+d65=24.5+200+35.6=260.1 [ms]

DE2E(G4→G5)=d46+d65=200+35.6=235.6 [ms]

DE2E(G4→G6)=d46=200 [ms]

DE2E(G5→G2)=d56+d64+d42=35.6+200+24.5=260.1 [ms]

DE2E(G5→G4)=d56+d64=35.6+200=235.6 [ms]

DE2E(G6→G2)=d64+d42=200+24.5=224.5 [ms]

DE2E(G6→G4)=d64=200 [ms]

And we estimated the E2E delay for real time IoVT flows generate from G6 as follows.

DE2E(G6→G1)=d67+d71=34.4+35.6=70 [ms]

DE2E(G6→G2)=d67+d71+d12=34.4+35.6+27=97 [ms]

DE2E(G6→G3)=d65+d53=35.6+11.2=46.8 [ms]

DE2E(G6→G4)=d64=200 [ms]

DE2E(G6→G5)=d65=35.6 [ms]

According to the proposed routing model to prevent overload on channel 4-6, we proposed to use path 4-7-3-5 for non real-time IoT flowsf(G4→G5)realtime=F2+D5+D9+D2=5.57+1.68+1.81+1.6=10.66 [Mbps] and to use path 4-6-5 for real-time flowsf(G4→G5)unrealtime=C5+A2=2.15+0.19=2.34 [Mbps] generated from host G4 to G5.

The histogram of link utilization was obtained when using the proposed routing model and is depicted in Fig.7.

Figure 7:Links utilization in SDN testbed according to the proposed routing model

We estimated the E2E delay of IoT flows passing through overloaded link 4-6 according to the proposed routing model.

The E2E delay for background multi-service IoT traffic is as follows.

DE2E(G2→G5)=d24+d46+d65=24.5+29.5+26=80 [ms]

DE2E(G4→G5)=d46+d65=29.5+26=55.5 [ms]

DE2E(G4→G6)=d46=29.5 [ms]

DE2E(G5→G2)=d56+d64+d42=26+29.5+24.5=80 [ms]

DE2E(G5→G4)=d56+d64=26+29.5=55.5 [ms]

DE2E(G6→G2)=d64+d42=29.5+24.5=54 [ms]

DE2E(G6→G4)=d64=29.5 [ms]

The E2E delay for real time IoVT flows generate from G6 is as follows.

DE2E(G6→G1)=d67+d71=34.4+35.6=70 [ms]

DE2E(G6→G2)=d67+d71+d12=34.4+35.6+27=97 [ms]

DE2E(G6→G3)=d65+d53=26+13=39 [ms]

DE2E(G6→G4)=d64=29.5 [ms]

DE2E(G6→G5)=d65=26 [ms]

Comparison of average E2E delay of the DMCQR model with our proposed routing model is depicted in Fig.8.

Figure 8:Comparison of average end-to-end delay of the DMCQR model with our proposed routing model

In general, the above results show that the routing model proposed in this paper provides an acceptable E2E QoS guarantee for all mission-critical IoT applications, in contrast to the existing DMCQR routing model that has been developed by authors in paper [41].

4 Conclusions

A software-defined networking paradigm, with simpler hardware and flexible management and monitoring, is the true solution to allow the Internet to converge with the IoT.SDN belongs to the programmable network domain.It separates the data and control planes using simpler hardware devices and centralized software control of the entire network.Our research focuses on guaranteeing QoS applications over an SDN network in the context of the IoT.

To solve this problem, we proposed the centralized routing model based on QoS parameters and IoT subscriber flow priorities for SDN.It enhances QoS for mission-critical IoT applications in large-scale SDN-IoT infrastructure.Experimental results showed that in contrast to the existing DMCQR routing scheme, the proposed model can provide QoS to both delay- and loss-sensitive IoT flows.

The developed centralized routing model in comparison with the known DMCQR flow routing achieved better balance of channel resources load due to rational choice of transmission paths for different traffic.And it reduces up to 3 times the average delay of real time flows from end to end, for which existing DMCQR routing model with the permissible delay rates were not met.

A limitation of the proposed idea is that in practice it is necessary to develop a tool according to which users can report to the controller about the required quality.Such a solution in our next work is proposed to be developed in the form of a personal user account.

In future work, we plan to develop QoE-routing for SDN/IoT networks, which, unlike known,to select the optimal data transmission path to use the adaptive QoE-oriented route metric.This metric is automatically calculated by the centralized SDN network controller based on a mathematical model of correlation QoS/QoE.Such improvement will allow users of IoT services to order the required quality in the form of QoE scores from 1 to 5, where higher value means better quality, and the controller analyzes QoE scores to find the best path.

Funding Statement:This research was supported by the Ukrainian project No.0120U102201“Development the methods and unified software-hardware means for the deployment of the energy efficient intent-based multi-purpose information and communication networks” and Comenius University in Bratislava, Faculty of Management.

Conflicts of Interest:The authors declare that they have no conflicts of interest to report regarding the present study.