An SDN-Based Publish/Subscribe-Enabled Communication Platform for IoT Services

Yali Wang, Yang Zhang*, Junliang ChenState Key Laboratory of Networking and Switching technology, Beijing University of Posts and Telecommunications,Beijing, 00876, China College of Computer and Information Engineering, Henan Normal University, Xinxiang, Henan, 453007, China

I. INTRODUCTION

IoT devices and services proliferate rapidly.The number of deployed IoT devices is approximately on the order of 50 billion, and there will be 1000 times more by the year 2020 [1]. IoT services involve many domains such as manufacturing, E-health, transport,insurance, public safety, and mass-market, etc.

[2]. As a result, both the underlying networks and communication technologies are facing big challenges in the aspects of accessing IoT applications and transmitting exploding IoT trafc.

Many IoT applications such as large power grids, which operate at the same frequency,highlight the supply and demand balance in real time[3]. Sensor data with microsecond-accurate timestamps and real-time transmission demands starves for a coherent picture of the whole system and closed-loop control as well as broad protection. Recent power disturbances cascading into large blackout call for visualization, situational awareness technologies,and visibility improvements. The other continuing need, driven by demand for high reliability and efficient operation, is to improve the communication infrastructure.

The increasing IoT services require event-driven service coordination to process complex multi-source real-time data streaming. Publish/subscribe paradigm, which provides loosely coupled services in time, space and control, facilitates asynchronous and on-demand sensor information transmission.Thus, it is suitable to access IoT services/applications. Topic-based publish/subscribe paradigm distinguishes events from their topics which are embedded in event headers. Event dissemination still depends on network infrastructure.

However, under the ossifying architecture of the conventional Internet architecture, publish/subscribe systems suffer from scalability and flexibility, concerning with the growing interests in IoT. Thus, they are disabled to provide personalized service and QoS guarantees facing multifarious IoT services/applications.

As a novel programmable network architecture, SDN [4] decouples the control plane from the forwarding plane. The former, which embeds all the intelligence, is responsible for making optimal decisions on how SDN-configurable switches deal with packets, under the fact that it maintains a network-wide view.The latter just takes actions deferring to the instructions from the control plane. In this way,SDN perfectly solves the scalability problem without deteriorating network performance.Moreover, the features of slicing and network function virtualization (NFV) owned by SDN make it feasible to provide individualized services for applications with different requirements.

In this paper, we propose a unied communication platform for IoT services combining SDN architecture with a topic-oriented publish/subscribe middleware, named SDNPS(SDN-based publish/subscribe system). This platform facilitates service consumers of diversied IoT-related services to access network as well as relieves stress for service providers and developers to manage and optimize IoT applications.

In addition to describe the software architecture of the topic-based publish/subscribe system we proposed as well as its main components, we discuss how our system caters for the baseline communication requirements of a data delivery system supporting IoT applications abstracted by literature[3]. We also point out our prototype can address some open research challenges summarized by literature[1].Finally, we exemplify it with a DHCISS scenario.

II. RELATED WORK

There were some surges to develop IoT-enabled platform to facilitate key related players,including software developers, network administrators, services providers, and services users. The following lists several prototypes or researchndings.

Bakken D. E. et al. [3] abstracted the baseline communications requirements of a data delivery system supporting IoT applications.They also suggested some implementation guidelines to achieve them.

Hakiri A et al. [1] proposed a publish/subscribe-enabled IoT network architecture, which integrates SDN and DDS(Data Distribution Service) middleware aiming at establishing efficient and scalable IoT communications. They also summarized several open issues related to standardization efforts,mobility of objects, networking etc. However,there was no prototype for this architecture.

Qin Zhijing et al. [7] designed a software-dened approach for IoT environment to achieve differentiated QoS levels for different IoT tasks in very heterogeneous wireless networking scenarios.

Jae Man Been et al. [8] proposed an IoT trafc management method through a virtualized IP multimedia subsystem environment,addressing some issues of congestion and server overload incurred by explosive increase on IoT signals and data trafc.

Kim and Jaeho [9] presented an open services framework for IoT for the sake of establishing a global ecosystem.

Akram Hakiri et al. [10] presented a data-centric publish/subscribe paradigm middle-ware, which employed a two-level architecture that aligned with the decoupled architecture of SDN.

A content-oriented publish/subscribe middleware based on SDN was presented by Tariq M A, etc. in literature [11]. This system supported interoperability and independent reconfiguration of multiple controlled SDN networks.

Zhang et al. [12] studied the impact of SDN on the design of future message-oriented middleware, especially on the publish/subscribe systems. They argued that publish/subscribe systems can adopt a logically centralized controller model for maintenance, monitoring,and control of the overlay network.

Al-Fuqaha A. et al. [13] proposed a generic IoT protocol, which extended the MQTT(Message Queuing Telemetry Transport) protocol.This protocol wasexible enough to address IoT vertical market requirements and support rich QoS features by exploiting a mix of IP multicasting, intelligent broker queueing management, and trafc analytics techniques.

Akiyama T. et al. [14] proposed a scalable pub/sub system using OpenFlow controller. It utilized both application layer multicast and openow-based multicast.

Liu Bo, Chen Ming, Hu Chao et al. [15]proposed a resource utilization optimizing mechanism for Datacenter Networks with OpenFlow.

III. THE SDN-BASED PUBLISH/SUBSCRIBE COMMUNICATION PLATFORM FOR IOT SERVICES

IoT is a broad term referring to the next-generation internet [2]. Although there is no precise definition, IoT is still considered as an upand-coming market, with a major impetus to the development of information process and communication technologies as well as the innovation of infrastructure networks. IoT ecosystem, which involves many stakeholders including device developers, services developers, software developers, integrators, network operators, and services users etc., enables IoT objects or machines to interact with each other so that they can exchange information and perform actions without human intervention.

The exponential expansion of IoT devices and services/applications with different requirements will have a great impact on how people interact with the surroundings and how IoT services/applications access networks, as well as how networks provide services. To solve these questions, we present an SDN-based publish/subscribe communication platform, enabling IoT services/applications to access SDN networks seamlessly and work efciently.

3.1 IoT objects,IoT services/appllications

The development of IoT devices is surged by the advances of micro-electro-mechanical systems (MEMS). These devices mainly consist of sensors and actuators (RFID, Bluetooth Devices, Wireless Sensor Networks (WSN),Embedded Systems, and Near Field Communication (NFC)). They automatically record,process, and send information over network.

IoT services cover a huge range of domains,including E-health, heating control, smart grid,transportation, safety, industry, agriculture,retail services, etc. So far, there are hundreds of applications identied with the relevance to IoT.

3.2 What IoT applications requires againgst network?

Currently, a large number of IoT objects,which cover a variety of purposes, are geographically distributed. The IoT deployment environment is fundamentally heterogeneous[13], partly depending on the integration of already-deployed IoT sub-networks. The infrastructure networks should expose an access mechanism for IoT services/applications to join in internet easily.

In the era of IoT, the traffic generated by IoT services may exceed the one generated by human beings. The infrastructure networks should have the ability to process and forward trafc far much more than before.

Most IoT applications have their own QoS requirements, such as latency and data rate as traditional metrics, as well as geographic scope and criticality as the broader metrics.Differentiated QoS is another important issue that the network should address.

Privacy and Security, which are prominently important for some IoT service/applications,highlight the strong demand for access control or data protection that the network should provide.

Moreover, scalability, robustness and mobility are also essential, as IoT will change the order of magnitude of service control, network control and information processing.

3.3 The publish/subscribe-based communication platform for IoT services

Surged by the heterogeneous and dynamic characteristics of IoT services and on-demand data transmission service provided by SDN,we propose an SDN-based publish/subscribe communication platform depicted as Figure 1. This frame serves multiple IoT applications through a unified communication platform.Any IoT service, which is authorized to access the platform, can publish or subscribe/unsubscribe events. These events can be metadata from sensors or control instructions from IoT applications. The platform then disseminates them to related receivers.

Fig. 1. A publish/subscribe service frame under SDN.

Different from topic-oriented DDS under conventional Internet, SDN-based DDS can orchestrates event routing and forwards events in ane-grained manner according to events’different constrains. The reason is that it can make full use of the programmability and the global knowledge obtained by interacting with SDN controller through northbound interfaces provided by SDN controller. According to the characteristics of SDN, we design an SDN-based publish/subscribe-enabled system,especially routing subsystem and topology management subsystem.

3.4 Interface

In general, SDN architecture adopts a three-layered reference model suggested by Open Networking Foundation (ONF). Figure 2 depicts this model and the interaction interface.

The interaction between SDNPS and SDN controller recurs to Northbound API. At present, there is no standardization for northbound interface. ONF has developed a Northbound Working Group to research whether or not create standards for Northbound APIs. As for Southbound Interfaces interacting between SDN-C and SDN-FE, there is a dominant protocol named OpenFlow. In addition, for the sake of efficiency, security and privacy considerations, network on a large scale should be partitioned into multiple clusters. We call the interfaces implementing cooperative work between controllers of different clusters the East-West interfaces.

IV. PROTOTYPE IMPLEMENTATION

The publish/subscribe-enabled communication platform offers unified services mediating events from source nodes to one or more related destination nodes in an anonymous,asynchronous, and many-to-many mode. It consists of three layers: the Infrastructure layer, the network layer, and the application layer.The device layer includes a large number of sensors/actuators which generate metadata and then deliver it to the local processing brokers they directly connected to. The network layer consists of many SDN-configurable switches providing network service as network infrastructure. The application layer consists of local processing brokers which implement the topic-oriented publish/subscribe service.The local processing brokers receive metadata from sensors/actuators, package them in a predefined format by embedding topics and metadata, and put them on SDN infrastructure for transmitting. The network layer accounts for forwarding events efficiently and providing differentiated services to meet events’ constraints such as end-to-end latency, loss rate,etc.

In this section, we describe the implementation of the publish/subscribe-enabled communication platform we proposed. Figure 3 depicts its main modules and process logic. Our work mainly focuses on the application layer and the control layer (the network layer).We add an IoT service interface as the northbound interface to SDN controllers, allowing the publish/subscribe system to interact with the control layer for the sake of building network-agnostic supports for IoT applications.

Fig. 2. SDN reference frame and interface.

4.1 Administration subsystem

4.1.1 Topic management

The publish/subscribe platform is topic-oriented. Every event is required to carry a topic. To prevent topics from exploding, all the topics must register to the administration node before they are put into use. We organize topics as a topic tree. A topic’s subscriber list is a subset of its ancestor topics’ subscribe list in this topic tree. If a subscriber subscribes a topic,it also automatically subscribes those topics on its subtrees. This subscription cover relationship contributes to calculating routing in a lower complexity on time and space.

We encode every topic into a unique binary string as described in literature [17]. Events embeds such strings as topic identification.Matching event with forwarding rules ofow tables becomes simple and efficient with the aid of this encoding.

Every local processing broker should download this topictree as well as its encoding. When a broker receives metadata from a directly connected IoT object, it packages this metadata and its topic code into an event according to a predened format.

The administration node is responsible for adding, modifying and deleting a topic in topictree. When there is any modication on topictree, it will notify all brokers to update their topictrees.

4.1.2 Strategy management

Strategy management defines some access control requirements. On the one hand, some clusters may prohibit events with specic topics from passing through them for security or privacy reasons on behalf of network administrator. On the other hand, some events may avoid passing through certain clusters on behalf of the IoT applications. The use of strategy makes it possible to distinguish clusters with different authorities, which is conducive to prevent the system from some hostile conditions, such as information leakage, network trafc anomalies, etc.

We adopt a strategy base to storage these constraints. The organization and storage form of the strategy is also in accord with the topics for convenience of routing calculation module to apply strategy. The administration node accounts for managing the strategies, including addition, deletion and modification. All the representative node of clusters must download and storage strategyle.

When calculating routing paths for topics,the routing module will meanwhile consider relative strategy constraints. If a strategy is cluster-level, the routing path should bypass these clusters constrained by it. If a strategy is broker-level, routing paths will not be affected; those brokers constrained by it will filter this type of events autonomously.

Like topic management, all the brokers should have consistent information on strategy with the administration node. The addition,update, and deletion to the strategy data will also trigger the corresponding routing computation.

4.2 Topology management subsystem

Fig. 3. The software architecture of publish/subscribe-enabled communication platform.

To meet the needs of large-scale deployment,we manage network hierarchically by dividing the whole network into areas. A set of SDN-configurable switches, which are con-trolled by a same controller set, constitute an area. Here we only consider the case of only a single controller per area.

For topology in a cluster (intra-area topology), OpenFlow protocol family contains protocols such as OFDP and LLDP to discovery devices and topology. Controller accounts for collecting device and link information,and then sums up topology knowledge about its cluster. Controller should also expose this knowledge to applications through northbound interface.

The acquisition and maintenance of inter-area topology rely on the cooperation of administration node and all the controllers.Every controller reports its intra-area topology to the administration node. The administration node aggregates and abstracts all the intra-area topology information, then form global topology information. Following, it diffuses global topology information back to controllers. Every controller keeps contact with its adjacent areas through periodic heartbeat messages.When a controller should but not receive heartbeat information, it sends a message to the administration node to report this state.Then, the administration node regenerates inter-area topology and diffuses topology update messages to all the controllers.

Through above mechanisms, each controller has its intra-area topology information and the global inter-area topology information.

Correspondingly, local processing brokers(publish/subscribe nodes) are organized into two levels. Those brokers located in the same area naturally constitute a cluster. Each cluster can have exactly one representative broker and some agent brokers. The representative is responsible for computing routing and delivering routing information to controller through northbound API. Then controllers configureow tables on switches of its cluster through southbound API. To simplify our prototype,we plant functions for representative on controllers. Each cluster can have exactly one representative. Even if an area has no IoT application to access publish/subscribe platform,a representative node is still necessary. The reason is that events may pass through every area, and every switch may require flow entries to forward events.

All the brokers account for publishing,subscribing, and unsubscribing events. They execute the corresponding actions according to applications.

4.3 Event routing

Under hierarchical organization and management for brokers and network, we divide the event routing inevitably into two levels: intra-cluster routing and inter- cluster routing.

Intra-cluster routing can realize autonomy.Every cluster is permitted to define its own routing strategy within cluster. E.g., we should make full use of IP multicast technology in those clusters which support IP multicast aiming at achieving better performance than application layer multicast. The representative nodes independently select intra-cluster multicast strategy according to their own intra-cluster topologies.

As for inter-cluster routing, constructing overlay network or multicast tree is often required for every topic. In our system, the global topology is abstracted into a graph denoted byG, the subscription list for every topic is abstracted into a node set denoted bySt. Then the overlay problem is abstracted into the problem of constructing a minimum connected subgraph that spansSt, also known as stenier tree problem. We can construct different stenier trees in terms of different optimization objectives. In literature [17], we have implemented a load-balanced algorithm standing in a global position rather than a single program.In addition, subscription coverage relationship between father topic and descendant topics also contributes to reducing the time and space complexity of overlay construction algorithm by the means of incrementally computation and storage.

4.4 Event Procedure Subsystem

This publish/subscribe-enabled communication platform is event-driven. There are four types of events: subscribe event, unsubscribe event, publish event, and advertisement event.IoT application client is designed for generating these events. There may be multiple clients connected to one broker.

4.4.1 Subscribe/unsubscribe event

Every broker has complete subscription information. A broker maintains three different subscription tables: client subscription table,broker subscription table, and cluster subscription table. When a broker receives a subscribe/unsubscribe event from its clients, it first updates its client subscription table, and then delivers this event to all the brokers and the representative node in the same cluster with its own broker ID. When other brokers receive this event, they update their broker subscription table. Besides this, a representative broker also updates its cluster subscription table. If this id is the first one of its cluster who subscribe a topic or the last one who unsubscribes a topic, the representative node should notify all the representative nodes to update their cluster subscription table including itself with cluster id.

4.4.2 Advertisement

Before a broker first publish an event with a topic, it should publish an advertisement to indicate it maybe publish events with this topic. Advertisement should also be broadcast to every broker. It also triggers reconstructing the overlay network of this topic (routing recalculation).

4.4.3 Publish Event

When a broker receives a publish event from its client, itrst checks its client subscription table, then it pushes this event to those clients who have subscribed this type of events. Following, this broker delivers this event to those destination brokers through intra-cluster table.

4.5 QoS supports

Many IoT applications need real-time monitoring and control for their reliable operation to handle anomalies of this platform. Some IoT applications need rigorous end-to-end delay and cost requirements, while others do not.To achieve these, three requirements are necessary: (1) Adopting multicast routing to improve efficiently network utilize. In SDNPS,we construct multicast tree incrementally at low cost for per-topic, according to the cover relationship among topics. When new subscribers join in this multicast group over time,we just expand this multicast tree sequentially.(2) Every path from source node to a destination node must meet event’s delay constraint.For this goal, we combine routing algorithms with queue management on switches. (3) Providing differentiated services to meet different QoS requirements of different applications or events. IoT applications express their QoS requirements through events’ topics. SDNPS achieves differentiated services through latency-constraint routing and queue management.

V. IOT APPLICATION SCENARIOS

The publish/subscribe-based unied platform described above can serve multiple IoT applications. DHCISS [16] is one of them.

5.1 The scenario description of DHCISS

DHCISS is deployed in Beijing. It adopts a publish/subscribe-enabled communication platform under traditional Internet. DHCISS often needs automatically process massive real-time streaming data generated by sensors,and make prompt and intelligent decisions in response to any abnormal situation reflected by events. Here we list an example. When there is a leakage of heating water supply pipe, a series of detection items such as pipeline pressure, backwater volume, backwater temperature etc. will have some deviantuctuations. Sensors catch this exception and send it to relevant monitoring points. These monitoring points fuse multi-source raw sensor data and derive problem diagnosis based on implicit professional knowledge. Then,the heating control system publishes warning information and starts the maintenance and rescue system with notification message. If the maintenance work has to influence some household heating, DHCISS will send short messages to those inuenced customers. Once the problem upgrades, some emergency information should be reported to the government heating administration department. All these messages are handed out by events with topics by this publish/subscribe-based unified platform.

Up to now, DHCISS has a very good effect.However, when we push too much trafc maliciously on Internet, DHCISS does not work well due to the defects of Internet itself. The conventional Internet also undergoes huge pressure and difculties on handling the access of heterogeneous, dynamic changing IoT applications, not to mention providing required QoS supports. To solve these problems, we re-construct the topic-based publish/subscribe DDS under SDN.

5.2 How the communication platform serves DHCISS?

DHCISS is composed of multiple subsystems, including sensor information collection subsystem, real-time monitoring subsystem,control subsystem, event analysis subsystem,maintenance & rescue subsystem, report subsystem, and billing subsystem. These subsystems are deployed on different brokers, depicted asgure 4. A broker can subscribe/unsubscribe, or publish which events depending on the systems planted on it. All these brokers constitute the topic-based publish/subscribe DDS.

The event process logic is similar to the communication platform based on traditional Internet. The difference is that we can manipulate the routing calculation and forwarding actions according to current network station with optimal or sub-optimal solutions, as we have global knowledge about network and the ability to control the forwarding plane. We can also provide enhanced QoS in order to implement differentiated service according to intrinsic properties of events, as SDN can be sliced and virtualized.

Fig. 4. DHCISS deployment instance.

5.3 Evaluations

In order to validate the effectiveness of the topic-based publish/subscribe system under SDN. In this section, we exhibit some experiment results. The topology used in experiments is similar to Figure 4. The difference between the two systems under different network infrastructure is the routers/switches connecting different clusters. The traditional Internet adopts routers. In SDN, a computer,which installs OpenvSwitch and three netcore NE104 PCI network cards, acts as an Open-Flow switch. We get different topologies by enabling or disenabling some links.

5.3.1 Throughput

Two hosts (publishers) located in cluster 1 sent 5w publish messages respectively, heading to two hosts (subscribers) located in cluster 3 and going through cluster 2. We recorded the time difference σ from the two subscribers received therst message to they received the last message. At the same time, we recorded the total number of messages (denoted asN)they received. Then we computed the average received messages per second byN/σas throughput. Then, we repeated this experiment enabling the publish messages that each publisher sent varied at {10w, 15w, 20w, and 25w}, and computed the throughput in the same way. Figure 5 shows the result. There is no obvious decline on throughput.

Fig. 5. Throughput.

Fig. 6. Average delay.

5.3.2 Average delay

This set of experiments exhibit the loss rate characteristics under SDN. We test the delay for 1 hop, 2 hops, and 3 hops respectively.One publisher located at cluster 1 publishes events heading to one or several subscribers located at cluster 3. For every test, the publisher publishes 100,000 events continuously. We recorded the time difference from the time that therst packet is sent to the time that the subscribers received the last packet. Every test is repeated 1000 times. We compute the average value for end-to-end delay. Figure 6 depicts the results.

We would like to stress that virtual machine does validate the business logic of SDNPS,but gives very conservative performance bounds. In fact, the other metric, the loss rate,decreases with the increase of hops in our test.It looks incredible but rational. The virtual end nodes, which causes event loss, limit their reception capacity.

VI. CONCLUSION

IoT, which opens new dimensions for people to interact with the world and puts forward new requirements to internet, is promising to have a big impact on networks and information communication technology. SDN as a new emerging future network architecture makes it easier and more efcient to deploy and manage applications with different requirements.A large number of IoT applications, which are mainly event-driven, highlight the importance of a unied communication platform.

In this paper, we presented an SDN-based publish/subscribe communication platform for IoT services. We summed up how the proposed platform facilitates the access of diverse IoT services and how it improves mega data delivery and sharing. We also described its prototype implementation, and outlined how IoT applications benefits from this unified platform through an example.

We have already implemented a prototype and some simulations to evaluate the correctness and feasibility. The following work will focus on the QoS improvement. Different routing algorithms should be exploited to meet different objectives. The combination of routing mechanism and per-port queue management will help to implement end-to-end delay guarantees.

As IoT covers a wide range of people’s lives and a large scale of applications, service architectures for IoT applications are undergoing an evolution. New SDN-based solutions will play an import role on serving IoT applications. We hope our work is a meaningful attempt on serving IoT applications and exploring their performance guarantee methods by integrating data distribution service and SDN.

ACKNOWLEDGEMENT

This research is supported by National Hightech R&D Program of China (863 Program)under Grant (No. 2013AA102301) and Natural Science Foundation of China under Grant(No. U1536112).