Publish/subscribe-enabled software defined networking for efficient and scalable IoT communications

Requirements

• IoT deployment involves heterogeneous smart objects whose connectivity, locations, speeds, and operational states can change dynamically.Devices may sleep, wake, connect, disconnect, or move while operating with limited computation, storage, and power.Source: §I · p. 1

Networking gap

• Existing IoT networking faces IPv4 exhaustion, heterogeneity, device-discovery, context-awareness, and resource-utilization challenges.The paper argues that current protocols and provisioning approaches lack abstractions and flexibility for changing IoT application needs.Source: §I · p. 1

Related approaches

• Web-of-Things approaches reduce heterogeneity through open web technologies but do not provide distributed, peer-to-peer publish/subscribe semantics.Security and scalability challenges also remain unresolved.Source: §I · p. 1
• Existing middleware contributions address upper-layer access and services without sufficiently addressing the underlying network, while DDS is not itself a network-level solution.DDS capabilities are rarely propagated to the network layer, limiting use across wide-area environments.Source: §I · pp. 1–2

Contribution

• The paper combines SDN and DDS to create a protocol- and technology-independent abstraction addressing both network and distributed-systems concerns.The proposed combination is intended to support a more flexible IoT network architecture.Source: §I · p. 2

SDN and NFV

• SDN separates network control from switches and uses a centralized controller with northbound application interfaces and southbound device protocols.OpenFlow uses software-defined flow tables to process and forward packets.Source: A. Software Defined Networking (SDN)… · p. 2
• NFV complements SDN by virtualizing network functions as software modules running on standardized IT infrastructure.These modules can be assembled or chained to create services.Source: A. Software Defined Networking (SDN)… · p. 2

DDS

• DDS is standardized middleware for interoperability among connected machines, enterprise systems, and mobile devices, spanning low-footprint devices to cloud platforms.It supports efficient bandwidth usage and agile orchestration through a flexible, modular structure.Source: B. OMG Data Distribution Service (DDS) · p. 2
• DDS models communication through domains, topics, publishers, data writers, subscribers, and data readers.A domain provides a virtual global data-space, while publishers and subscribers manage writers and readers.Source: Figure 1 · p. 2

DDS evolution

• DDS standardization has expanded from platform- and language-independent publish/subscribe mechanisms toward discovery through RTPS and planned SDN northbound integration.The standard also discusses dynamic topic types, remote method invocation, web integration, and security extensions.Source: Figure 1 · p. 2, B. OMG Data Distribution Service (DDS) · p. 3

Architecture

• IoT systems are organized into device, network, and application domains.The device domain contains smart devices and access networks, the network domain provides heterogeneous connectivity, and the application domain contains applications and cloud infrastructure.Source: A. IoT Architecture · p. 3

Device domain

• Devices connect to the network directly through access networks such as Bluetooth and ZigBee or indirectly through gateways acting as network proxies.Gateways extend connectivity between device-side technologies and the broader network.Source: A. IoT Architecture · p. 3

Gateway requirements

• IoT gateways must manage heterogeneous traffic while supporting resource efficiency, QoS, security, and multimedia data exchange.The architecture seeks a convergent gateway solution rather than requiring each IoT subnetwork to maintain its own gateway.Source: A. IoT Architecture · p. 3

Network domain

• The network domain combines diverse access and core-network technologies, including xSDL, satellite, 3GPP, TISPAN, and LTE-A.This domain provides connectivity to devices, gateways, and application infrastructure.Source: A. IoT Architecture · p. 3

Current Standardization Efforts

• 6LoWPAN adapts IPv6 to low-capacity devices by operating between the IPv6 and MAC layers.It targets compatibility between IPv6 networking and constrained device environments.Source: 1) Current Standardization Efforts · p. 3
• ROLL focuses on routing for lower-energy smart-object networks, while CoAP provides web transfer for constrained devices and networks.Both efforts target communication constraints common in IoT deployments.Source: 1) Current Standardization Efforts · p. 3
• M2M promotes end-to-end architecture covering sensor integration, naming, addressing, location, QoS, and security.Its scope includes several cross-cutting functions needed for IoT deployments.Source: 1) Current Standardization Efforts · p. 3
• These standardization efforts remain isolated rather than forming a unified IoT networking approach.The paper presents their separation as an unresolved issue for deployment.Source: 1) Current Standardization Efforts · p. 3

• IoT devices frequently operate in diverse mobile scenarios, making efficient mobility management a primary concern.Source: 2) Mobility Management · p. 3
• Controllers need a network-wide view of IoT-object mobility to manage spatial-temporal requests, adaptive handover, and dynamic flow scheduling.Source: 2) Mobility Management · p. 4
• Publish/subscribe middleware delivers events asynchronously from source nodes to interested destinations, supporting varied IoT communication patterns.Source: 3) Recurring Distributed Systems Issues · p. 4
• Many-to-many IoT communication also creates congestion-control challenges in machine-to-machine scenarios with short packets and short-lived interactions.Source: 3) Recurring Distributed Systems Issues · p. 4

• TCP imposes connection-setup, congestion-control, buffering, and retransmission overheads that are unsuitable for many IoT scenarios.Source: 4) Communication Protocols · p. 4
• IoT devices require configurable confidentiality, integrity, and privacy protections because wireless channels are vulnerable and devices have limited resources.Source: 5) Security and Privacy · p. 4
• The architecture connects sensors and actuators through local processing, Internet access, gateways, and diverse technologies including Wi-Fi, Ethernet, VPN, USB, Serial, and ZigBee.Source: §IV · p. 4

• The DDS layer mediates between the IoT system and SDN controller, supporting proactive and reactive flow programming.Source: A. The Controller Architecture · p. 4
• DDS pub/sub provides anonymous, asynchronous, many-to-many communication rather than synchronous point-to-point RESTful interaction.Source: A. The Controller Architecture · p. 4
• The mediation layer implements Packet Handler, Packet Forwarder, and Flow Programming services around controller events and DDS topics.Source: A. The Controller Architecture · p. 4
• DDS messaging transports messages between network-control applications and SDN services while supporting scalability, reliability, flexibility, security, and real-time delivery.Source: A. The Controller Architecture · p. 4

• SDN and DDS are open, standardized technologies intended to reduce lock-in and support modular network experimentation.Source: 1) Standardization and Open Innovation · p. 5
• DDS enables broker-less many-to-many communication, self-addressable and self-routable data, bounded resource use, and message replay after reconnection.Source: 2) Addressing and Mobility · p. 5
• Virtualized IoT gateways maintain active session continuity and enable sensors to attach dynamically to multiple networks.Source: 2) Addressing and Mobility · p. 6
• When devices move between networks, the centralized SDN controller modifies OpenFlow switch flow tables to account for mobility.Source: 2) Addressing and Mobility · p. 6
• DDS supports request-response queues, event-based topics, traffic differentiation, prioritization, selective down-sampling, and DSCP marking for end-to-end QoS.Source: 3) Efficient Middleware Integration · p. 6

• DDS discovery lets gateways maintain local object lists containing device locations, descriptions, IP addresses, CoAP URIs, and multicast addresses.Source: 4) Service Discovery and… · p. 6
• Gateway-based collection can become a bottleneck when multiple nodes transmit simultaneously, motivating filtering and fusion to reduce unnecessary traffic.Source: 5) Scalability handling · p. 6
• DDS batching combines multiple small samples into one packet, while Content Filtered Topics deliver only subscriber-requested subsets of a topic.Source: 5) Scalability handling · pp. 6–7
• OpenFlow complements DDS mechanisms by collecting traffic statistics at configurable granularity and enabling responses to detected network flooding.Source: 5) Scalability handling · p. 7

• DDS multi-channel supports high-volume sensor streams by dividing data flows across multiple channels.Source: 6) Context aware network management · p. 7
• Multichannel Data Writers associate multicast addresses with filter expressions so subscribers receive only matching topic data.Source: 6) Context aware network management · p. 7
• OpenFlow can move keyword-based filtering closer to the source and let a controller application determine filtering decisions dynamically.Source: 6) Context aware network management · p. 8

• DDS Security Model provides interoperable policies for securing domains, topics, and individual data-object instances.Source: 7) Solving Security issues · p. 8
• DDS partition QoS provides an additional mechanism for creating isolated system segments.Source: 7) Solving Security issues · p. 8
• The proposed data-centric DDS–SDN architecture is presented as enabling agile and flexible IoT network orchestration.Source: §V · p. 8
• The study aims to clarify DDS middleware and SDN integration as IoT architectures evolve toward broader technology convergence.Source: §V · p. 8