Selecting the Optimal IIoT Connectivity: Frameworks vs. Transports

Designing a distributed infrastructure for the Industrial Internet of Things (IIoT) can feel like navigating a maze of protocols and standards. As a developer or system architect, you likely already have a list of options—TCP, UDP, MQTT, CoAP, OPC‑UA, DDS, and more—each promising to solve a different slice of the connectivity puzzle. The real challenge is determining which solution truly aligns with your application’s needs.

Fortunately, an independent, vendor‑neutral study has already mapped the landscape. The Industrial Internet Consortium (IIC) published the Industrial Internet Connectivity Framework (IICF), a comprehensive guide that evaluates the strengths and trade‑offs of each transport and framework. The findings are now publicly available, giving you a data‑driven foundation for your decision‑making process.

Below we walk through the key questions you should ask yourself, compare transport and framework capabilities, and highlight the most relevant IICF‑identified technologies. By the end, you’ll have a clearer picture of which option best fits your unique IIoT application.

About the Industrial Internet Consortium (IIC)

Founded in 2014 by industry leaders such as Cisco, Intel, AT&T, IBM, and GE, the IIC has grown to include over 250 member companies. Its mission is to advance the commercial potential of the IIoT by developing standards, testbeds, and best‑practice documents. The IICF is one of its flagship outputs, offering a vendor‑neutral framework for evaluating connectivity solutions in real‑world scenarios.

Transport vs. Framework: Understanding the Stack

In the IICF, connectivity solutions are split into two layers:

• Transport – Low‑level mechanisms that move raw bytes between endpoints (e.g., TCP, UDP, MQTT).
• Framework – Higher‑level abstractions that enforce data models, discovery, and semantic interoperability (e.g., OPC‑UA, DDS, OneM2M).

Figure 1 illustrates the overall stack, highlighting where transports and frameworks fit.

While a transport simply delivers bytes, a framework wraps those bytes into structured messages, enabling applications to benefit from features like data filtering, content discovery, and security policies.

Transport Options

Below is a snapshot of the transport capabilities covered in the IICF (Table 1). The table is available as an image in the original document; you can view it here:

MQTT – The Proven Telemetry Transport

MQTT is the only transport in the IICF that does not impose a data model. Its lightweight, broker‑based architecture makes it ideal for scenarios where devices simply need to publish telemetry data to a backend system.

Broker‑based design eases loose coupling but may not satisfy stringent real‑time or deterministic requirements. Use the following quick test: answer "yes" to at least three of the questions below to confirm MQTT is a good fit.

• Is your application primarily data collection?
• Is device‑to‑device communication minimal?
• Is interoperability a secondary concern?
• Do you have many small, low‑power devices?
• Is software complexity low for your team?

Frameworks

Frameworks add a layer of semantic meaning to the data, enabling richer interaction patterns. We focus on the three most widely adopted frameworks identified by the IICF: OPC‑UA, OneM2M, and DDS.

OPC‑UA – Industrial Automation’s Standard

OPC‑UA is a broker‑based framework that offers secure, real‑time data exchange between industrial devices and enterprise systems. It is especially suited to discrete manufacturing and environments where device semantics must be preserved.

Answer "yes" to at least three of the following to gauge OPC‑UA’s fit:

• Are you working in discrete manufacturing?
• Are you aligned with the German Industrie 4.0 program?
• Will your device be integrated by control engineers rather than software developers?
• Will the product serve diverse applications across multiple systems?
• Are you building equipment for a workcell?

OneM2M – A Cross‑Industry Service Layer

OneM2M provides a horizontal platform that sits between applications and transport, exposing common IoT services via RESTful APIs. It excels in mobile, home‑automation, and large‑scale deployments where cellular connectivity and service provider integration are key.

Use the checklist below to see if OneM2M aligns with your needs:

• Do you understand the meaning of ICT (Information & Communications Technology)?
• Is cellular the primary network technology?
• Do your applications involve significant mobility?
• Can your system tolerate intermittent connections and variable latency?
• Will you leverage telco‑provided services?

Data Distribution Service (DDS) – Real‑Time Publish/Subscribe

DDS is a peer‑to‑peer publish/subscribe framework that creates a shared data bus. It is designed for low‑latency, high‑reliability scenarios such as autonomous vehicles, defense, and healthcare monitoring.

Ask yourself these five questions to determine DDS suitability:

• Do brief outages have severe consequences?
• Have you used terms like "millisecond" or "microsecond" in recent discussions?
• Does your team have more than ten developers?
• Does your data need to reach many destinations?
• Are you building a next‑generation IIoT system?

Wrapping It Up

The right connectivity solution depends on your specific requirements—data volume, latency, reliability, and the level of semantic interoperability you need. Use the IICF as a starting point, run through the checklists, and consider how each transport or framework addresses your key constraints.

Should you find gaps or have additional use cases, feel free to reach out. The community’s collective knowledge can help refine your choice and avoid reinventing the wheel.

Additional Resources

• RTI Blog – Industrial Internet Connectivity Document Evaluates Core Standards: DDS, OPC‑UA, WebServices
• Free On‑Demand Webinar: How the IIC’s Connectivity Framework Guides IIoT Connectivity Selection