University of Pisa
Master Degree in Computer Engineering
Computer Systems and Networks
Implementation, development and evaluation
of a Publish/Subscribe architecture in
IoT networks based on Software-defined Networking
paradigm
Supervisors
Prof. Enzo Mingozzi
Ing. Antonio Virdis
Ing. Giacomo Tanganelli
Candidate
Cristina Gallina
ABSTRACT... I
1 INTRODUCTION ... 1
2 BACKGROUND ... 5
2.1 WIRELESS SENSOR NETWORK ... 5
2.1.1 6LoWPAN ... 5
2.1.2 RPL ... 6
2.2 COAP ... 9
2.3 SDN:SOFTWARE DEFINED NETWORKING ... 10
2.3.1 System Architecture ... 11
2.3.2 OpenFlow protocol ... 11
3 SD-6LOWPAN: SOFTWARE DEFINED IN WIRELESS SENSOR NETWORK ... 13
3.1 OVERVIEW ... 13
3.2 ARCHITECTURE ... 14
3.3 SOUTHBOUND INTERFACE ... 16
3.3.1 Controller resources ... 16
3.3.2 Node Resources ... 17
4 PUBLISH/SUBSCRIBE: PROPOSED SOLUTION ... 19
4.1 OVERVIEW ... 19 4.2 BROKER CHOICE ... 22 5 PUBLISH/SUBSCRIBE IMPLEMENTATION ... 27 5.1 OVERVIEW ... 27 5.2 NORTHBOUND INTERFACE ... 28 5.3 NODES CONFIGURATION ... 29
6 TESTING AND PERFORMANCE EVALUATION ... 33
6.1 TESTING ... 33
6.2 PERFORMANCE EVALUATION ... 37
7 CONCLUSIONS ... 57
I
ABSTRACT
Wireless sensor Networks (WSN) and Internet of Things (IoT) are two interconnected concepts that, in last years, have gains more importance due to the development of new kind of networks.
Application of IoT in different field as industrial monitoring, healthcare, smart environment, etc. introduces new types of communication on sensor networks, not only from nodes to sink (multipoint-to-point) or vice-versa (point-to-multipoint), but also between nodes themselves.
This is possible using SDN, that, through the installation of forwarding rules in each node by an external entity that maintains a global vision of the network, achieves to establish direct path between nodes.
Many solutions have been proposed to apply SDN technique to WSN, but they all make use of proprietary protocols. Between them, SD-6LowPAN represents a solution that makes use only of standard protocols.
In this scenario, this thesis work aims to implement on this system a Publish/Subscribe architecture for many-to-many communication.
Attention has been focused on the position of the Broker nodes, the node in charge of gather messages arrived from producers and send them to consumers.
To do that two indexes have been proposed that, based on some characteristic of the network, place the broker node in different position.
Lastly, the system has been tested and evaluated, using as metric the total number of messages generated in the network during communication, comparing its performance between an RPL solution and between different position of the Broker.
As will be shown, broker position results to be not relevant respect to consumer communication in terms of the number of messages generated but became relevant for other kind of metrics.
In general, using SDN for many to many communication, brings benefit in terms of number of messages exchanged in the network, compared to a system with an RPL implementation.
1
1 INTRODUCTION
During last years, Internet of things (IoT) [1] concept gains more and more importance, due to the diffusion of new scenarios as smart home, smart cities or factory monitoring. IoT paradigm considers interconnection between any kind of object providing services for humans and machines.
For his peculiarity of interconnection of many numbers of devices, the concept of IoT is bound to Wireless Sensors Network (WSN) [2] ones, that allows to connect sensor nodes among the environment, gathering and analysing data.
A limit of WSN is that, often, they are domain-specific, and this doesn’t permit reusing them for other systems or application, and moreover it becomes difficult in case of the use of different applications simultaneously, without an appropriate instrument to help them.
A good choice in this case, is the use of Software Defined Networking (SDN) [3], that is a technique of network management that decouples control plane from data plane. In this way the underlying network infrastructure is abstracted from applications while network intelligence is logically centralized. So, it allows a sort of network virtualization and, in case of the presence of more users in the network, helps to use the same physical infrastructure providing several virtual overlay networks, each one dedicated to one user.
SDN, traditionally, was implemented in wired systems, due to some limits imposed by the wireless environment like the unreliability of links, and capability limits in terms of energy and computational constrains.
There are some implementations of SDN on Wireless Network, but they make use of proprietary protocols, and this limits interoperability between system and reusability. Between them, SD-6LowPAN [4] [5] represents a new solution that exploits standard protocols, in which Southbound interface is performed by using
2
CoAP protocol and the communication with the Controller that manages the control plane is performed exploiting RPL protocol and his DODAG formation.
Using SDN on WSN brings some benefits: first of all, nodes are energy and computational constrained so moving routing decisions and data processing to an external controller allow to reduce the power consumption.
SDN brings also other benefits, regarding communication machine-to-machine: installing direct path between two nodes through installation of rules, communication results to be more immediate and involves a fewer number of nodes compared to an RPL solution.
The combination of SDN and WSN and the new prerogatives provided by IoT, open new scenarios for other kinds of communication, not only from nodes to sink (multipoint-to-point) or vice versa (point-to-multipoint) but also machine-to-machine or many-to-many.
In this context, this thesis work aims to provide a solution to exploits benefits of using SDN on WSN by using SD6LowPAN as the underlying system by an implementation of a Publish/Subscribe architecture.
In this kind of architecture Producers generate information about a topic and send it to a Broker, that is responsible for sending this information to those consumers that have register to that specific topic.
Attention has been focused on the correct position of the Broker node inside the network, for its strategical role, trying to find a way to individuating univocally a position in which the number of generated packets in the network are minimized. For this purpose, two indexes have been proposed for Broker choice, Mean Index and Variance Index, that synthetize in different way the contribution of the communication between Producers and Broker and between Broker and Consumers. Lastly, the system has been tested in various scenarios to verify that the correctness of the system and to evaluate benefits of using SDN instead of classic RPL for
many-3
to-many communication, and to highlight the impact of positioning Broker in different part of the network.
It will be shown that using SDN for this kind of communication is convenient in terms of total messages generated in the network respect to using RPL. Regarding Broker positioning, if the evaluated metric is the number of generated messages in the network, and if Broker is chosen between the consumer nodes, will be demonstrated that the position of broker doesn’t matters, regarding communication from broker to consumers, but became important distance from producers: in this case the best index to collocate Broker is the Mean Index.
In case other metrics are involved, as latency, Variance Index individuates a better candidate to reduce mean hop distance from broker to consumers.
5
2 BACKGROUND
2.1 Wireless Sensor Network
A wireless sensor network [2] is a network in which each node is a low power sensor node that has the capability to observe and gather data in their surrounding environment, and to send them in a wireless medium to other sensors in the network after some kind of elaboration to avoid useless transmissions and to reduce traffic data. All sensors are coordinated by a sink, that serves as a link with the outside of the network and collects all the information arrived by all nodes.
The development of this kind of network brings new challenges, first the power management and computational constrains. For this reason, standard protocols as IPv6 or classic routing protocols are not suitable for them, and new solutions has been developed.
2.1.1 6LoWPAN
6LowPAN represents a solution for running IPv6 over low power and lossy personal area networks.
Figure 1 - 6LowPAN stack
In fact, Ipv6 presents some problems over low power networks:
Packet adaptation: IPv6 does not provide fragmentation and its minimum Maximum Transmission Unit is 1280 Bytes. The underlying MAC layer present on sensor nodes instead uses the standard IEEE 802.15.4, whose MTU is of 127 bytes.
So, there is the need of an intermediary in the stack between Network and MAC layer that allows fragmentation and reassembles them for upper layers.
6
Multi-hop support: at MAC layer only one-hop transmissions can be performed, so 6LowPAN has to implement multihop. There are two ways to perform multihop:
Mesh under (layer 2):
Figure 2 - Mesh under solution
The packet is forwarded by intermediate nodes according to information that can be found within layer 2, under IPv6 layer. This means that from the point of view of IPv6-transmitter and IPv6-receiver, the transmission in one-hop
Route over (layer 3):
Figure 3 - Route over solution
The forwarding operation is performed according information within the IP header.
This also means that if the IP packet is fragmented into multiple layer 2 frames, a router needs to wait for all the frames, reconstruct the IP packet and then take a decision on forwarding.
2.1.2 RPL
As already said, routing protocols must consider energy efficiency and computational constrains. Moreover, usually nodes don’t have enough space to contain entire
7
routing tables. So, in case a route over solution is used, 6LowPAN uses a different routing protocol, named RPL.
RPL represents an efficient solution based on a not usual version of the distance vector algorithm. The standard version of the distance vector is based upon the metric of the distance among nodes, in terms of hops. The RPL, instead, uses routing basing it upon different metrics, as direct consequence of the wireless nature of the channel.
The purpose of the algorithm is to form a Direct-Acyclic-Graph (DAG), that is a graph where all the nodes are connected by oriented arcs without the presence of any cycle.
An important property of acyclic graphs is that there will be for sure a sink, that is a node where all the arcs tends to and don't go out from it. This turns to fit very well with the aim of building a path from any node to the border router. By so, each node within the network will be able to reach whatever destination outside the network exactly through the border router.
The purpose of RPL protocol is thus to grant that will always exist a path from each node to the border router.
The RPL protocol is based upon the concept of the so called constrains based routing, where basically, among all the possible paths, only a subset of them will be chosen according some constraints and then the best one among the set is selected as preferred path.
The RPL protocol is said to be a multipoint-to-point protocol, that means building a DODAG such that from different points (multipoint) is possible to reach one point (-to-point). The DODAG is built upon a network abstraction: from the physical point of view we can only talk about broadcast communication ranges, since all the nodes in the same communication range of a specific one are able to receive packets sent from the latter. Upon this physical representation RPL performs a topological abstraction connecting all nodes that can talk. Upon this first abstraction the DODAG is built basically selecting and orienting some of those links in order to build an acyclic graph where is possible to reach one point (the border router) from multi-points (all the nodes in the network).
8
The node rank is the concept at the base RPL protocol. The node rank is basically a number each node will assign to itself. Border routers will start with rank 0. Then, by exchanging messages, each node will come up with its own rank.
At the end of rank selection, the following property must hold: on whatever path from each node to the border router, the sequence of ranks found on the path must be monotonically decreasing.
If the latter property is satisfied, then the graph built is acyclic and thus we won't have cycles.
When the network starts, all the nodes start to exchange messages in order to set its own rank. During this phase a node can several times adapt its rank in order to satisfy the above property, so that after a certain time, all the ranks will become stable. The latter means that the graph will become stable and at the same the paths associated. These RPL messages are called DIO (DODAG Information Object) and they carry all the information needed to run the RPL procedure.
DODAG_ID: used in case of different DODAGS in order to understand from which one DIOs are coming from.
Instance: ID order, to use different RPL instances within the same network.
Rank
Once a node has selected its rank, it starts to advertise all the neighbours periodically. To avoid transmitting when not necessary and so to save power, period after a new DIO transmission is performed is regulated by Trickle algorithm, based on two principles:
Broadcast suppression: sometimes when nodes receive broadcast information, they will not retransmit it if no changes are detected in the network. This reduces the useless retransmission.
Adaptive periodicity: in order to keep the network up to date, information is periodically transmitted, but this period will dynamically change over time.
9
RPL also provides a mechanism about the dissemination of information about reachability through DAO (Destination Advertisement Object) messages. Two possibilities:
Storing mode: each node stores information on how to reach all those nodes belonging to the subtree of which it is root. So, DAO message is forwarded from sending node through his tree, until it reaches a node that knows how to reach the destination
Non storing mode: only sink node stores routing table and source routing is employed
2.2 CoAP
Constrains Application Protocol (CoAP) is a communication protocol of application layer for lossy and low power network based on REST architecture that takes into consideration peculiarities of this kind of network like limited memory and computational capacity.
Figure 4 - CoAP stack
Some characteristics are:
RESTful architecture: communication is addressed to resources that each CoAP node exposes and that can be reached through PUT, GET, POST and DELETE requests.
Use of UDP at transport layer: in this way the protocol results more light and reliability if necessary is implemented at application layer.
10
Confirmable (CON): used for reliable transmission, when sent request a confirm of delivery from the receiver through an ACK message.
Non-Confirmable (NON): indicates that no ACK messages are requested and so that is a non-reliable communication
Acknowledgement (ACK) Reset (RST)
Client-server architecture based on request/response messages, exchanged in asynchronous mode
Support for multicast communication
Stateless HTTP mapping: allows intercommunication between application using HTTP and others using CoAP.
2.3 SDN: Software Defined Networking
Software Defined Networking (SDN) [3] is a network architecture where network control is decoupled from forwarding and is directly programmable. This migration of control formerly tightly bound in individual network devices, into accessible computing devices enables the underlying infrastructure to be abstracted for applications and network services, which can treat the network as a logical or virtual entity.
11
2.3.1 System Architecture
Figure 5 - SDN architecture
Inside Control Layer, network intelligence is centralized in software based SDN which maintain a global view of the network.
With open APIs between the SDN control and applications layers, applications can operate on an abstraction of the network, leveraging network services and capabilities without being tied to the details of their implementation: this is done through the so-called Northbound Interface-
Lastly the Southbound Interface, through which Controllers manages data place on Network Devices is traditionally implemented through OpenFlow.
2.3.2 OpenFlow protocol
OpenFlow is the first standard communications interface defined between the control and forwarding layers of an SDN architecture. OpenFlow allows direct access to and manipulation of the forwarding plane of network devices such as switches and routers.
12
The OpenFlow protocol is implemented on both sides of the interface between network infrastructure devices and the SDN control software. OpenFlow uses the concept of flows to identify network traffic based on matching rules that can be programmed by the SDN control software inside flow table of each SDN Switch. So, when a packet arrives to the node, it looks at his flow table: if a rule matches, it performs the action defined in that entry, otherwise it asks the Controller what to do and store a new rule in his table
13
3 SD-6LOWPAN: SOFTWARE DEFINED IN
WIRELESS SENSOR NETWORK
3.1 Overview
SDN was usually implemented in wired context due to the overhead brought by OpenFlow, so implementation on WSN uses ad-hoc solutions defining proprietary protocols. This approach, however, limits interoperability between different systems and with the existing deployment.
For this reason, SD-6LoWPAN was implemented [4] [5]: it exploits standard protocols to manage control and data plane.
These are the main characteristic of the implemented system: Mesh-Under for forwarding instead of Route-over solution
With route over, packet’s destination is analysed at network layer, so destination
is individuated through his IP address.
So, if a packet is fragmentated at MAC layer, at IP layer a node has to wait for all fragments before sending the entire packet, and this introduces an overhead. If, instead, mesh under is used, forwarding is managed at MAC layer, so each fragment is considerate separated from each other.
RPL for network setup and connectivity with the Controller (upward routes). Downward routes managed by the Controller (no need of DAO messages). Southbound interface exploits CoAP protocol: the control plane is performed by
the Controller, that communicates with the SDN Nodes to install on them forwarding rules and to receive from them network information. This communication is performed by using CoAP messages, addressed to specific resources.
14
3.2 Architecture
Figure 7 SD-6LoWPAN architecture
SD-6LoWPAN architecture is composed by three different components: SDN Controller
Manages control plane operations, receives information about network topology and about the quality of the links between nodes. Through this information it computes paths between nodes and install forwarding rules on them.
Gateway
The Gateway is a particular SDN Node that makes connection between sensor network and the outside, in particular with the Controller.
It is also the root of the DODAG formed by RPL. SDN Nodes IPv6 6LoWPAN MAC SDN Flow Table RPL Local Controller Figure 8 – SDN Node
15
These are standard 6LowPAN sensor network with SDN capabilities, reached through a new layer in the stack, the SDN layer that deals with data plane. With this layer, POSTO between MAC and 6LoWPAN layer, when a packet arrives to the node, it scans his Flow Table, managed by the Controller, that contains rules for forwarding. In case no match is found, a table-miss occurs, and a message is sent to the Controller. Each node has inside a Local Controller, that is one of the endpoints of the Southbound interface, that communicates with the Controller in case of a table-miss and populates the Flow Table of the node. So, the control plane is not completely separated by data plane, in fact Local controller manage topology maintenance by install upward rules in the Flow Table through RPL protocol, to know the next hop to reach Controller and rules to forward packet to neighbour.
Flow Table contains all rules that the nodes have to check when a packet arrives. Each row represents a rule and an action to be performed if the rule matches. In addiction there are two fields, priority and statistics, the former indicating the order in which rules must been examined, the latter containing information about how many times that rule matches, useful to determine when delete a rule.
16
The field rules can contains a list of conditions that must occur to validate the match: field, offset and size identify, inside the packet, the first operand on which operator is applied; value represents the second operand.
If all rules in the row are satisfied, an action is performed. Each action is characterized by a type that specify the kind of operation to do (i.e. Forward, Broadcast, Modify, …)
3.3 Southbound interface
The Southbound interface, that let the Local Controller of each node to manage entries of flow table by communicating with the Controller, is implemented by using CoAP Protocol. Through these exchanged messages the Controller installs
forwarding rules on nodes, based on the topology that it has received by nodes themself.
This is obtained by some resources exposed by SDN nodes and by the Controller.
3.3.1 Controller resources
Controller’s resources are:
Network Engine: represents the current network status, the nodes belonging to it, their status and their connections.
Periodically each node sends a Topology Update by performing a POST request to this resource, to update the global vision of the network of the Controller. Flow Engine: with this resource the Controller manages the installation of
forwarding rules. It is the resource that is queried by a POST request when a table miss occurs
17
3.3.2 Node Resources
SDN Nodes’ resources are:
Flow table: represents the Flow Table of each node, so is queried by the Controller whenever it changes, so by a PUT operation to insert a new row; a DELETE operation to remove rules or by a GET one to retrieve the entire table. Neighbour Table: represents the table of neighbouring of the nodes, so is
accessed by a GET request by the Controller to know, for that node, information about their neighbours and the link quality to reach them.
Key Features: specifies, in case of a table miss, which field of the packet that causes it has to be transmitted to the Controller.
19
4 PUBLISH/SUBSCRIBE: PROPOSED SOLUTION
4.1 OverviewSD6LowPAN represents a way to use SDN on Wireless Sensor Network and so to exploits its benefits on it.
This opens new scenarios, beginning from the possibility of virtualizing the underling network to implement communication M2M or even more, Many to Many.
In this context this thesis work offers an example of this kind of communication over a WSN based on SDN through the implementation of a Publish/Subscribe architecture.
Figure 10 – Producer/Consumer architecture
In this kind of architecture, three are the main roles: [6]
Producers: nodes that periodically send messages containing some kind of information about a topic
Consumers: nodes that register themselves to a particular topic and wait for some information about it
20
Broker: nodes that behaves as a link between producers and consumers. Producers sends messages to it, and then it dispatches message properly to consumers.
In this implementation only one topic is used, associating one multicast address to it, but multiple topics are possible performing multiple instance of the paradigm. The Publish/Subscribe paradigm is in fact performed through the NorthBound Interface of the SDN System.
Software-defined northbound application program interfaces (SDN northbound APIs) are usually SDN RESTful APIs used to communicate between the SDN Controller and the services and applications running over the network. These APIs can be used to facilitate efficient orchestration and automation of the network to align with the needs of different applications via SDN network programmability.
In this case, an external applicative, called the Manager, request for the beginning of the paradigm, providing a list of publishers and consumers. It has the possibility to choose the broker or it demands it to the Controller.
This communication is performed through CoAP protocol, that is a RESTful communication protocol, so Controller exposes a new resource, PublisherSubscriber through which it receives information from Manager and installs forwarding rules in SDN nodes.
21
So, Controller, as soon as it receives information about consumers and producers, interacts with nodes informing producers on who is the broker to send messages and associates a multicast address to consumers to which broker will send a broadcast message containing data received from producers.
Application plane Data plane Control plane NORTHBOUND INTERFACE SOUTHBOUND INTERFACE
Manager
SDN
Controller
22 4.2 Broker Choice
If Manager doesn’t choose a Broker node itself, the Controller has to choose it properly. This means that Broker shall be placed in a position such as to reduce the number of transmissions in the network. That is why, in first place, it was decided to choose broker between consumers and not between producers. Broker in fact will be the root of the multicast tree generated for consumers, so it better to be chosen between consumers.
In broker choice, two characteristics has been evaluated, one that take into account contribution of producers and one for consumers.
So, for each candidate broker, and so for each consumer, mean path length from each producer to broker and depth of the multicast tree that would occur having that node as root has been computed.
For producers’ length has been chosen to perform mean and to don’t take the max length to avoid situations like this:
Figure 12 - A network examples in which one producer is further respect to the others
23
In first case the maximum length is 4, while the mean length is 1,75. In second case the maximum length is 3 so, it would be better than first situation, but its mean is 3. Once obtained this two values, an index has been computed that synthetize both quantities together, in order to individuate univocally the best broker: the consumer with the lowest index value is chosen as broker, in case two consumers have the same lowest value, the first that will be evaluated will be chosen.
Two indexes have been individuated. Given: NC = number of consumers
NP = number of producers
PM = mean path length from producers to broker
CD = multicast tree depth
The first index, the Mean index is:
𝐼 =𝑁 × 𝑃 + 𝑁 × 𝐶 𝑁 + 𝑁
This index succeeds in individuating properly a good choice for the broker because takes into account both quantity in equal manner, but it is influenced from number of consumers and producers. In fact, if, for example, the number of producers turns out to be much greater than the number of consumers, broker will be that
24
consumer that is located closer to producers. But is important no notice that there I a difference between the communication between producers and broker and between broker and consumers.
Looking the Figure 14, even if broker in in both cases one hop distant from others, situations are different.
In case of producers, each of them performs a unicast transmission to broker, so in that case, 4 transmissions are performed.
In case of consumers instead, transmission is broadcast, so if all consumers result to be in the transmission range of broker, only one transmission in performed. So, it would be preferable, if it doesn’t result to be too far from producers and so getting up the unicast transmissions, a broker closer to the major number of consumers. To take this factor into account, an index based on the variance of multicast tree depth has been proposed.
In this way, if variance is high, this means that there will be consumers for which tree depth is much lower than others. These brokers are preferable because minimize the broadcast transmissions.
The Variance Index is:
𝐼 = 𝑃 + 𝑉𝑎𝑟 × 𝐶
with VarC multicast tree depth variance.
25
In this way, variance behaves like a weight: if is small, index takes into account, as Mean Index, both producers and consumers contribution in equal manner.
If instead variance turns out to be large, a greater importance is given to the consumer contribution.
The difference between two indexes however in negligible in case of small networks or if the number of consumers is not large enough, because the variance remains small, so they individuate the same broker.
27
5 PUBLISH/SUBSCRIBE IMPLEMENTATION
5.1 OverviewThe system descripted in previous chapter has been implemented on Java exploiting Californium framework, that is a Java CoAP implementation.
In particular a new resource, ps, has been added to Controller to manage Northbound interface and to manage distribution of rules in the sensor network.
The routines executed by nodes have been implemented through the C programming language and based on the Contiki framework. The latter is an Operated System designed for networked, memory-constrained systems with a focus on low-power wireless Internet of Things devices
The Sink Node, lastly, is implemented according to a native border router solution, so SDN part is running on an unconstrained device (in case of Cooja simulation on the host device), while the node itself behaves as a slip radio.
JSON
Manager
Controller
Pub/Cons PUT requestConsumers
Producers
cg ft ft PUT request POST request28
5.2 Northbound Interface
At beginning of the protocol, the Manager sends the list of producers, consumers and possibly the broker.
This information is taken from a JSON file as follow:
1. { 2. "consumers": [ "fd00:0:0:0:204:4:4:4", "fd00:0:0:0:205:5:5:5", "fd00:0:0:0:206:6:6:6", "fd00:0:0:0:207:7:7:7","fd00:0:0:0:208:8:8:8"], 3. 4. "producers": ["fd00:0:0:0:202:2:2:2","fd00:0:0:0:209:9:9:9"], 5. 6. "broker": 1, 7. 8. "BrokerIP": "fd00:0:0:0:203:3:3:3" 9. } where:
consumers: represents the list of consumer nodes. producers: represents the list of producer nodes.
broker: if is set to 1 means that the Manager provides the broker node, so the following field is read.
BrokerIP: represents the broker node IP
So, based on the information of the JSON file, Manager sends a PUT request to the Controller’s resource ps.
As soon as he receives the CoAP message, the Controller is responsible for setting up the system.
29
5.3 Nodes configuration
Once obtained broker node according to an index or another, the Controller begins to configure the sensor nodes to perform the Producers/Consumers paradigm:
Producers’ rules
For each producer, the Controller computes the unicast path to the broker, choosing the best path based on ETX metrics, that represents the number of expected transmissions of a packet necessary for it to be received without error at its destination.
The path has been calculated through the GraphStream library [7], that provides some function for handling graph.
Figure 16 - Example of producers' tree
Has been decided to create the producers’ tree as the overlap of each unicast path form one producers to the broker. This means that every time that a rule has to be sent to a node of the path, first it must be checked if that nodes has
30
already received a rule previously. In this way the producers’ tree is built recursively.
So, for example, looking at picture 16, first path from 1 to B in calculated and rules are sent to node 1-2-5-7. When path is computed for node 2, no rules are sent because all nodes have already received instruction on how reach broker. Rules are sent making a PUT request to the ft resources of producers, using CBOR [8] encoding to reduce the packet dimension.
1. Rule r = new Rule(Fields.MH_DST_ADDR, 0, 64, Operators.EQUAL,
hexStringToByteArray(broker));
2. Action a = new Action(TypeOfAction.FORWARD, Fields.NO_FIELD,
0, 64, hexStringToByteArray(nextHop.getId()));
Building consumers’ multicast tree
To construct the consumers’ multicast tree, a previously implemented algorithm has been exploited. The purpose of this algorithm is, given a set of nodes, to building a minimum Connected Dominating Set (CDS). A set of nodes C ⊆ V, where V represents the set of vertices of a graph G, is dominating for G if every nodes of the graph belongs to C or is a neighbour of a node in C. This set is connected if from every node of set C, every other node can be reached.
In particular, as the definition of a minimum CDS is NP-hard, an approximation of it is actually realized, so a Minimum Steiner Tree is formed: a Minimum Steiner Tree is a tree that covers all the nodes in a graph having minimum cost on the edge from one nodes to another. Even in this case, as for producers’ path, ETX is the used metric.
Once the multicast tree is created, a multicast address is generated and assigned to all nodes of the multicast tree performing a POST request to their cg resource Consumers’ rules
As soon as the multicast tree is built, the Controller sends to all nodes belonging to it the multicast rules: when a packet arrives, if the destination is the multicast address, broadcast the message.
31
In this way, however, there is the possibility to generating loops broadcasting packets to one node to another and cause a broadcast storm.
To avoid this situation, additional rules are sent to the multicast group:
Broadcast is performed only if message is received from its own parent Otherwise, packet is dropped
For example, if the multicast address is “0001000000000002”, installed rules are:
1. r = new Rule(Fields.MH_DST_ADDR, 0, 64, Operators.EQUAL,
hexStringToByteArray("0001000000000002"));
2. r = new Rule(Fields.LINK_SRC_ADDR, 0, 64, Operators.EQUAL,
hexStringToByteArray(node.getParent()));
3. a = new Action(TypeOfAction.BROADCAST, Fields.NO_FIELD, 0, 0,
null);
4. r = new Rule(Fields.MH_DST_ADDR, 0, 64, Operators.EQUAL,
hexStringToByteArray("0001000000000002"))
5. a = new Action(TypeOfAction.DROP, Fields.NO_FIELD, 0, 0,
null);
Is important to notice that, due to the broadcast nature of the transmission, also all the nodes adjacent to the multicast tree has to store a rule to drop multicast messages.
33
6 TESTING AND PERFORMANCE EVALUATION
In order to test the correct functioning of the proposed system and to demonstrate benefits of using SDN for M2M communication instead of RPL, some topologies have been proposed and tested on Cooja simulator.
6.1 Testing
To verify the correctness of implemented system, it has been tested on the following topology:
Figure 17 - Testing topology
Node 2 and node 9 are the Producers; nodes 4,5,6,7,8 are the Consumers and 3 is the Broker.
When the Manager requests for a producer/consumer service, the Controller computes the multicast tree for consumers and sends the multicast address to all nodes belonging to the tree:
34
Figure 19- Multicast address arrived in all nodes belonging to the multicast tree
Then Controller sends rules for forwarding to all nodes of the multicast tree and to the producers:
For all the consumer there are the two entries for managing multicast messages: For examples, looking at node 5, its parent in the multicast tree is node 6. So if it receives a message for “0001000000000002” and the source is node 6, it broadcasts the message, otherwise it drops it.
Figure 18 - Multicast tree generated by Controller
35
Figure 21- Rules installed in consumers' tables
Lastly, only consumers must receive messages sent from producers, and log confirms this. We can see in fact that after that node 2 sends a message containing the string “prova”, the Broker receives it and sent the message to the multicast group, so only consumer nodes, in this case node 4,5,6,7,8 receive and print the message
To see the path performed by a packet starting from the producer, for examples looking at a transmitted packet of producer 2, it can be seen looking at producers’ flow table:
When node 2 sends the message, looks at his rules and see that if he wants to send a message to node 3, he has to send it to node 12.
Following the path found in each flow table, the message arrives until broker node:
Figure 23 - Motes' log after producers' transmissions
36
About consumers, we can see, for example in node 7 flow table, how a packet is treated: if the sender is node’s parent, in this case 4, packet is broadcasted otherwise packet is discarded.
Figure 24 - Part of the forwarding table of node 12
Figure 25 - Part of the forwarding table of node 11
Figure 26 - Part of the forwarding table of node 4
37
6.2 Performance Evaluation
To evaluate the system, many topologies has been proposed: Topology 1: a simple topology, with few nodes
Topology 2: with the same number of producers and consumers of the previous topology but with more nodes, to evaluate the impact of enlarging the network, respect to having a small one
Topology 3: in which producers and consumers are present in the same quantity.
Topology 4: number of consumers is greater than number of producers. Topology 5: number of producers is greater than the number of consumers.
These last three topology have been evaluated to test how scaling consumers/producers node numbers impacts on performance
Topology 6: highlight a case in which using Variance index, a different broker is selected instead of using Mean Index.
For all of them, two metrics have been computed:
Number of generated packets in the network after a broker transmission represents the total number of messages generated in the network, computed as the sum of all messages sent from each node of the multicast tree after a broker transmission.
Number of necessary messages for producers to reach the broker is the sum of messages exchanged through the path from producer to broker.
Figure 28 – Message is sent from node’s parent and is addressed to 000100000002, so the message is broadcasted
38
These values have been evaluated using RPL; using SDN having broker near Border Router and using SDN choosing Broker through index. There is no difference between choosing Broker using Mean index or Variance index, except for Topology 6, in that case both cases are reported.
Results have been calculated performing 5 transmission and performing a mean value with a precision of 95%.
Topology 1 – Small topology (14 Nodes, 2 Producers, 5 Consumers)
Producers Nodes 2,9
Consumers Nodes 3,4,5,6,7,8
Broker near BR 3
Broker chosen with index 7
39
Figure 29 - Topology 1
Figure 30- Mean number of messages generated in the network after a broker transmission
The chosen broker using the index is node 7. The number of messages sent in case of RPL are 14, that are exactly the number of nodes of the network.
Consumer node Producer node
Forwarder node Broker node
40
Figure 31 - Mean number of messages necessary to arrive from producers to broker
Evaluation of only one node is reported because they result to be identical for both of them.
Regarding number of messages necessary for reaching broker from each producer, it can be notice that there isn’t a great improvement using SDN instead of RPL. This is because, due to the limited dimension of the network, path from producers to the two brokers results to be similar in terms of hops for both RPL and SDN. In fact:
Path in case of SDN (broker 3): 2-12-10-7-3
Path in case of SDN with chosen broker (broker 7): 2-12-10-7 Path in case of RPL: 2-12-10-1-3
41
Topology 2 – Wider network (19 Nodes, 2 Producers, 5 Consumers)
Producers Nodes 2,9
Consumers Nodes 3,4,5,6,7,8
Broker near BR 3
Broker chosen with index 7
Forwarder Nodes 10,11,12,13,14,15,16,17,18,19,20 Figure 32- Topology 2 Consumer node Producer node Forwarder node Broker node
42
Figure 33 - Mean number of messages generated in the network after a broker transmission
Chosen broker is node 7. Adding nodes to the network, performance in SDN case become worse, but they still remain under RPL transmission. This is because path from broker to consumer and from producer has been expanded from the presence of the other added node, so a larger number of messages are necessary to reach destination.
Figure 34 - Mean number of messages necessary to arrive from producers to broker 0 1 2 3 4 5 6 7 8 Node 2 Node 9 Tr an sm itt ed p ac ke ts
Packet generated per producer transmission
43
About producer’s transmission, regarding node 9, RPL has the same performance than SDN using 3 as broker. This is because broker is in the path from producer to the border router.
Topology 3 – Same number of Consumer and Producer (20 Nodes, 5 producers, 4 Consumers)
Producers Nodes 2,21,22,26
Consumers Nodes 3,5,6,7,8
Broker 3
Broker chosen with index 7
Forwarder Nodes 10,11,12,13,14,15,16,17,18,19,20 Figure 35 - Topology 3 Consumer node Producer node Forwarder node Broker node
44
Figure 36 - Mean number of messages generated in the network after a broker transmission
Even in this case SDN results to be better respect to RPL regarding the number generated after a broker transmission. RPL in fact performs 20 transmission (the number of nodes in the network), instead SDN, thanks to the fact that the multicast tree is not very deep performs only 6 transmission if node 3 is the broker, 5
45
Figure 37 - Mean number of messages necessary to arrive from producers to broker
Even in this case performance of RPL are identical to SDN ones if Broker is 3.
Topology 4 -More Consumers than Producers (23 Nodes, 9 Consumers, 2 Producers)
Producers Nodes 2,9
Consumers Nodes 3,4,5,6,7,8,21,22,23,24
Broker near BR 3
Broker chosen with index 8
Forwarder Nodes 10,11,12,13,14,15,16,17,18,19,20 0 1 2 3 4 5 6 7 8
Node 2 Node 21 Node 22 Node 26
Tr as m itt ed p ac ke ts
Packets generated per Producer transmission
46
Figure 38- Topology 4
Figure 39 - Mean number of messages generated in the network after a broker transmission Consumer node
Producer node
Forwarder node Broker node
47
Figure 40- Mean number of messages necessary to arrive from producers to broker
Topology 5 – More Producers than Consumers (23 Nodes, 8 Producers, 4 Consumers)
Producers Nodes 2,9,21,22,23,24,25,26
Consumers Nodes 3,5,7,8
Broker 3
Broker chosen with index 8
Forwarder Nodes 10,11,12,13,14,15,16,17,18,19,20 0 1 2 3 4 5 6 7 8 Node 2 Node 9 Tr an sm itt ed p ac ke ts
Packet generated per producer transmission
48
Figure 41 - Topology 5
Figure 42 - Mean number of messages generated in the network after a broker transmission Consumer node
Producer node
Forwarder node Broker node
49
Figure 43 - Mean number of messages necessary to arrive from producers to broker
About producers’ messages, as it is possible to note in all these three situations, due to the position of nodes in network there is nearly no difference between using RPL or SDN using 3 as Broker. There is an enhancement using instead 8 in latter two cases because it is in a completely other part of the network respect to 3 and his position helps reducing producer’s path and it isn’t in the same path from producers to the root of the DODAG. Regarding messages generated by a broker transmission, SDN continue to be the better choice, and benefits improve in a situation with a great number of producers. This is because, when there are a great number of consumers to be served, number of messages generated are greater that in case of few consumers and more producers, so, from this side, number of messages sent by the broker goes down. On the other side, when many producers send a message to the broker, he tries to perform several broadcast transmissions and this can cause collisions. This brings to retransmissions and so the number of messages in RPL increases.
0 1 2 3 4 5 6 7 8 9 10
Node 2 Node 9 Node 21 Node 22 Node 23 Node 24 Node 25 Node 26
Tr an sm itt ed p ac ke ts
Generated packets per producer transmission
50
Topology 6 – Broker index Mean ≠ Broker index Std Dev (Nodes 21, Producers 5, Consumers 4)
Producers Nodes 2,21,22,26,27
Consumers Nodes 3,5,7,8
Broker near BR 3
Broker chosen with Mean index 8
Broker chosen with Variance index 5
Forwarder Nodes 10,11,12,13,14,15,16,17,18,19,20 Figure 44 - Topology 6 Consumer node Producer node Forwarder node Broker node
51
Figure 45 - Mean number of messages necessary to arrive from producers to broker
Figure 46 - Mean number of messages generated in the network after a broker transmission 0 1 2 3 4 5 6 7 8
Node 2 Node 21 Node 22 Node 26 Node 27
Tr an sm itt ed P ac ke ts
Packets generated per producer transmission
SDN - Broker near BR SDN - Broker Index Mean SDN - Broker Index Variance RPL
0 5 10 15 20 25 30 Tr an sm itt ed P ac ke ts
Packets generated per Broker transmission
SDN - Broker near BR SDN - Broker Index Mean SDN - Broker index Variance RPL
52
Finally, in this topology there is a difference if choose broker using Mean index or Variance index. In former case the chosen broker in 8 because it minimizes paths from producers to broker. In the latter, even if consumers are lesser then producer, they have a heavier weight in the compute of the index, in fact variance of multicast tree depth in nearly 2, in this case the chosen broker became 5.
Looking at Figure 45, can be notices that there is no difference in the number of messages generated after a broker transmission if the broker is Node 5 or node 8. This is because, as first assumption, we have chosen to select broker between consumers so, there isn’t a real difference in terms of number of generated messages if a broker is one consumers ore another, because all of them have to receive the message.
In general in fact, looking also to other topologies, can be notices that the improvement from one broker choice to another is of only 1 transmission.
This can me explained with this simple example:
The best solution is that the chosen broker is the central node, in this way with one transmission, all the other nodes receives the message.
53
If instead, another node in the circle is chosen as broker, not all the other nodes results to be in the transmission range, but with 1 transmission it sends the message to the central node and then from it all the other result reachable, for a total of 2 transmission.
This is however possible thanks SDN feature, that has installed in nodes M2M path. In the same situation, using RPL, messages results to be much more, because the broker doesn’t know how to reach consumers.
If the constrains of selecting broker between consumers is no longer valid, situation changes: for example looking at Figure 46, if the yellow nodes are consumer, orange nodes are the producers and the blue nodes are simple forward, and broker can be chosen between the latter, the mean index will probably select node 2, due to the higher number of the producer and because minimize the distance from them.
Figure 48 - In this case broker node, is the central one
54
The Variance Index instead, will select node 1 because is the node with the shallower multicast tree, and with only one transmission reaches all consumers.
In any case, is a trade-off between two opposite situations: in one case transmissions for reach all consumers are minimized but transmission for producers are maximized. In the other case the situation is reversed, so the total number of messages had to be taken into account.
So if the metrics to be evaluated is the total messages exchanged in the network, and there is the constrains to choose broker between consumers, indexes make no
difference and in general one consumer is good as the other, what makes the difference is the distance from producers. So, in general the better choice is to select the consumer closer to all producers that minimize the path from all to them to himself.
If instead a different metric is selected, may be worth to evaluate if the two indexes brings a benefit one respect to the other.
Looking again at Figure 43, another interesting metric can be the mean number of hops between consumers and broker. This can be relevant, for example, in a system in which latency is relevant, for example a real-time system, and is important to minimize the maximum delay of reception of the message.
In case 5 is the broker the minimum number of hops to reach a consumer is 1, while the maximum is 6. The mean results to be 3,5.
In case node 8 is the broker, the minimum number of hops is 4, the maximum is 9, so the mean distance is 6,5.
1
Figure 50 - Example of a situation in which broker isn't chosen between consumers
55 So, if latency can be considered proportional, or anyway influenced by hop distance, the solution with selects 5 as the brokers nearly double performance.
57
7 CONCLUSIONS
In this thesis work an implementation of many-to-many communication based on the paradigm of Publish/Subscribe has been implemented over an SDN-based Wireless Sensor Network.
In order to place the broker in a position that takes into account contribution of the communication from broker to consumers and from producers to broker, a choice based on indexes, that synthetize such characteristics of the network, have been proposed and implemented.
To evaluate the correctness of the solution, various scenarios have been tested, trying to individuate realistic situations.
The first result obtained is that in a system based on SDN, respecting to an RPL solution, the number of generated message in the network after a broker transmission is lower.
Regarding the part of the messages exchanged between broker and consumers, however the broker position doesn’t matter. In fact, having chosen to select broker between consumer nodes and being the metric evaluated the number of messages generated, there is at most one message of difference between choosing one consumer node or another to be the broker. This is because, in any case all consumers must receive the message sent from broker, so doesn’t matters who the broker is. Things change if some factors differ, for example if the candidate broker is chosen not only between consumers but also between other nodes in the network.
So, to individuate the proper broker, the part of communication between producers and broker must be investigated, so the best choice results to be the one the minimize transmissions from producers to broker.
The Mean index achieves to properly individuating the broker based on these assumptions.
58
If instead, the metric evaluated changes, the Mean index is not always capable of individuate the best broker: if for example the latency, in terms of hops, for the reception of messages is important, for example in a time-constrained application, the mean hop distance from broker to consumers matters.
In this case the Variance index do his best in this task.
Regarding the part of communication between producers and broker, every test highlight how the position of the producer respect to the broker and the DODAG root is important.
In fact, if the broker results to be in the path from producers to the DODAG root or the broker is positioned closer to the root itself, the performance between RPL or SDN are very similar.
In general, has been demonstrated that SDN results to be an efficient option to establish a communication many-to-many and a good way to individuate a position inside the network where to place the broker in order to further improves performance in terms of number of exchanged messages has been proposed. Starting from this initial point, the system can be extended and be enriched with new features through the NorthBound interface, for further development of the paradigm and new metrics can be evaluated in order to highlight other aspects of the systems not investigated in this thesis.
59
8 BIBLIOGRAPHY
[1] S. U. K. R. Z. a. S. K. Rafiullah Khan, Future Internet: The Internet of Things Architecture, Possible Applications and Key Challenges, 2012.
[2] W. S. Y. S. E. C. I.F. Akyildiz, Wireless sensor networks: a survey.
[3] O. N. Foundation, Software-Defined Networking:The New Norm for Networks - White Paper.
[4] A. V. E. M. Giacomo Tanganelli, Enabling Multi-hop Forwarding in 6LowPANs through Software-Defined Networking.
[5] A. V. E. M. Giacomo Tanganelli, Implementation of Software-Defined 6LowPANs in Contiki OS.
[6] A. K. J. J. M. Koster, Publish-Subscribe Broker for the Constrained Application Protocol (CoAP).
[7] «GraphStream documentation,» [Online]. Available: http://graphstream-project.org/. [8] P. H. C. Bormann, Concise Binary Object Representation (CBOR).
