| title | description | ms.service | services | author | ms.author | ms.topic | ms.date |
|---|---|---|---|---|---|---|---|
IoT asset and device connectivity and infrastructure | An overview of asset and device connectivity and infrastructure in an Azure IoT solution, including gateways and protocols such as MQTT and OPC UA. | azure-iot | iot | asergaz | sergaz | overview | 03/12/2025 |
This overview introduces the key concepts around how assets and devices connect to a typical Azure IoT solution. The article also introduces infrastructure elements such as gateways and bridges. Each section includes links to content that provides further detail and guidance.
The following diagram shows a high-level view of the components in a typical edge-based IoT solution. This article focuses on the connectivity between the assets and the edge runtime environment shown in the diagram:
:::image type="content" source="media/iot-overview-device-connectivity/iot-edge-connectivity-architecture.svg" alt-text="Diagram that shows the high-level IoT edge-based solution architecture highlighting device connectivity areas." border="false" lightbox="media/iot-overview-device-connectivity/iot-edge-connectivity-architecture.svg":::
The following diagram shows a high-level view of the components in a typical cloud-based IoT solution. This article focuses on the connectivity between the devices and the IoT cloud services, including gateways and bridges shown in the diagram:
:::image type="content" source="media/iot-overview-device-connectivity/iot-cloud-connectivity-architecture.svg" alt-text="Diagram that shows the high-level IoT cloud-based solution architecture highlighting device connectivity areas." border="false" lightbox="media/iot-overview-device-connectivity/iot-cloud-connectivity-architecture.svg":::
IoT Central applications use the IoT Hub and the Device Provisioning Service (DPS) services internally. Therefore, the concepts in a cloud-based IoT solution apply whether you're using IoT Central or IoT Hub.
To exchange data with edge-based services, assets use industry standards such as:
OPC UA tags and events. OPC UA tags represent data points. OPC UA events represent state changes. The connector for OPC UA is an Azure IoT Operations service that connects to OPC UA servers to retrieve their data and publishes it to topics in the MQTT broker. OPC Foundation
MQTT messaging. MQTT allows a single broker to serve tens of thousands of clients simultaneously, with lightweight publish-subscribe messaging, topic creation, and management. Many IoT devices support MQTT natively out of the box. The MQTT broker underpins the messaging layer in Azure IoT Operations and supports both MQTT v3.1.1 and MQTT v5. MQTT.
ONVIF media specifications (preview). The connector for ONVIF in Azure IoT Operations discovers ONVIF conformant cameras and registers them in the Azure Device Registry. The connector enables capabilities like retrieving and updating the configuration of the camera to adjust the output image configuration, or controlling the camera pan, tilt, and zoom (PTZ). ONVIF
Media protocols such as RTSP, RTCP, SRT, HLS, and JPEG over HTTP (preview). The media connector makes images and video from media sources such as IP cameras available to other Azure IoT Operations components. It can also capture snapshots from a video stream or from an image URL and publish them to an MQTT topic, or proxy a live video stream from a camera to an endpoint that an operator can access.
Once asset data is received, Azure IoT Operations uses data flows to process and route data to cloud endpoints or other edge components.
Azure IoT devices use the following primitives to exchange data with cloud services:
- Device-to-cloud messages to send time series data to the cloud. For example, temperature data collected from a sensor attached to the device.
- Device twins to share and synchronize state data with the cloud. For example, a device can use the device twin to report the current state of a valve it controls to the cloud and to receive a desired target temperature from the cloud.
- Digital twins to represent a device in the digital world. For example, a digital twin can represent a device's physical location, its capabilities, and its relationships with other devices.
- File uploads for media files such as captured images and video. Intermittently connected devices can send data in batches. Devices can compress uploads to save bandwidth.
- Direct methods to receive commands from the cloud. A direct method can have parameters and return a response. For example, the cloud can call a direct method to request the device to reboot.
- Cloud-to-device messages receive one-way notifications from the cloud. For example, a notification that an update is ready to download.
To learn more, see Device-to-cloud communications guidance and Cloud-to-device communications guidance.
Azure IoT Operations uses connectors to discover, manage, and ingress data from assets in an edge-based solution.
- The connector for OPC UA is a data ingress and protocol translation service that enables Azure IoT Operations to ingress data from your assets. The broker receives sensor data and events from your assets and publishes the data to topics in the MQTT broker. The broker is based on the widely used OPC UA standard.
- The media connector (preview) is a service that makes media from media sources such as edge-attached cameras available to other Azure IoT Operations components.
- The connector for ONVIF (preview) is a service that discovers and registers ONVIF assets such as cameras. The connector enables you to manage and control ONVIF assets such as cameras connected to your cluster.
To configure a connector in an Azure IoT Operations scenario, you define an asset endpoint that describes the southbound edge connectivity information for one or more assets. An asset endpoint profile includes connection information like the local IP address and authentication information.
To learn more, see What is asset management in Azure IoT Operations.
An Azure IoT hub exposes a collection of per-device endpoints that let devices exchange data with the cloud. These endpoints include:
- Send device-to-cloud messages. A device uses this endpoint to send device-to-cloud messages.
- Retrieve and update device twin properties. A device uses this endpoint to access its device twin properties.
- Receive direct method requests. A device uses this endpoint to listen for direct method requests.
Every IoT hub has a unique hostname that you use to connect devices to the hub. The hostname is in the format iothubname.azure-devices.net. If you use one of the device SDKs, you don't need to know the full names of the individual endpoints because the SDKs provide higher level abstractions. However, the device does need to know the hostname of the IoT hub to which it's connecting.
A device can establish a secure connection to an IoT hub:
- Directly, in which case you must provide the device with a connection string that includes the hostname.
- Indirectly by using DPS, in which case the device connects to a well-known DPS endpoint to retrieve the connection string for the IoT hub it's assigned to.
The advantage of using DPS is that you don't need to configure all of your devices with connection-strings that are specific to your IoT hub. Instead, you configure your devices to connect to a well-known, common DPS endpoint where they discover their connection details. To learn more, see Device Provisioning Service.
To learn more about implementing automatic reconnections to endpoints, see Manage device reconnections to create resilient applications.
Assets and asset endpoints in Azure IoT Operations are represented as custom resources in the Kubernetes cluster and as resources in Azure. Asset endpoint profiles include user authentication information for accessing those endpoints. This authentication can be anonymous or username/password authentication where the values are stored as secrets in Azure Key Vault. Access to the Azure Key Vault is configured with a user-assigned managed identity.
The connector for OPC UA is an OPC UA client application that uses a single OPC UA application instance certificate for all the sessions it establishes to collect data from OPC UA servers. By default, the connector uses cert-manager to manage its application instance certificate.
To learn more about security in your edge-based IoT solution, see Security best practices for edge-based IoT solutions.
A device connection string provides a device with the information it needs to connect securely to an IoT hub. The connection string includes the following information:
- The hostname of the IoT hub.
- The device ID registered with the IoT hub.
- The security information the device needs to establish a secure connection to the IoT hub.
Azure IoT devices use TLS to verify the authenticity of the IoT hub or DPS endpoint they're connecting to. The device SDKs rely on the device's trusted certificate store to include the DigiCert Global Root G2 TLS certificate they currently need to establish a secure connection to the IoT hub. To learn more, see Transport Layer Security (TLS) support in IoT Hub and TLS support in Azure IoT Hub Device Provisioning Service (DPS).
Azure IoT devices can use either shared access signature (SAS) tokens or X.509 certificates to authenticate themselves to an IoT hub. X.509 certificates are recommended in a production environment. To learn more about device authentication, see:
- Authenticate devices to IoT Hub by using X.509 CA certificates
- Authenticate devices to IoT Hub by using SAS tokens
- DPS symmetric key attestation
- DPS X.509 certificate attestation
- DPS trusted platform module attestation
- Device authentication concepts in IoT Central
All data exchanged between a device and an IoT hub is encrypted.
To learn more about security in your cloud-based IoT solution, see Security best practices for cloud-based IoT solutions and Security architecture for Azure IoT Hub.
To exchange data with Azure services, assets use industry standards such as:
- MQTT v3.1.1 and MQTT v5.0
- OPC UA
- ONVIF (preview)
- Media streaming protocols such as RTSP, RTCP, SRT, HLS, and JPEG over HTTP (preview).
An IoT device can use one of several network protocols when it connects to an IoT Hub or DPS endpoint:
- MQTT
- MQTT over WebSockets
- Advanced Message Queuing Protocol (AMQP)
- AMQP over WebSockets
- HTTPS
Note
IoT Hub has limited feature support for MQTT. If your solution needs MQTT v3.1.1 or v5 support, we recommend MQTT support in Azure Event Grid. For more information, see Compare MQTT support in IoT Hub and Event Grid.
To learn more about how to choose a protocol for your devices to connect to the cloud, see:
- Protocol support in Azure IoT Hub
- Communicate with DPS using the MQTT protocol
- Communicate with DPS using the HTTPS protocol (symmetric keys)
- Communicate with DPS using the HTTPS protocol (X.509)
Azure IoT Operations enables a one-to-many connection pattern at the edge. A single deployment can ingest data from multiple industrial assets at the edge, then handle communication with the cloud.
The OPC UA standard is built around assets connecting to servers. The connector for OPC UA is a client application that runs as a middleware service in Azure IoT Operations. The connector for OPC UA connects to OPC UA servers, lets you browse the server address space, and monitor data changes and events in connected assets. Operations teams and developers use the connector for OPC UA to streamline the task of connecting OPC UA assets to their industrial solution at the edge.
The media connector can process video streams (RTSP) directly from cameras. It can also access media servers where multiple cameras store their videos or images. Once the media connector connect to a single external media server, it can save, process, or route the snapshots or video streams to an edge or cloud endpoint.
There are two broad categories of connection patterns that IoT devices use to connect to the cloud:
Persistent connections are required when your solution needs command and control capabilities. In command and control scenarios, your IoT solution sends commands to devices to control their behavior in near real time. Persistent connections maintain a network connection to the cloud and reconnect whenever there's a disruption. Use either the MQTT or the AMQP protocol for persistent device connections to an IoT hub. The IoT device SDKs enable both the MQTT and AMQP protocols for creating persistent connections to an IoT hub.
Ephemeral connections are brief connections for devices to send sensor data to your IoT hub. After a device sends the sensor data, it drops the connection. The device reconnects when it has more sensor data to send. Ephemeral connections aren't suitable for command and control scenarios. A device client can use the HTTP API if all it needs to do is send sensor data.
Edge gateways (sometimes referred to as field gateways) are typically deployed on-premises and close to your assets and IoT devices. Edge gateways run on your edge runtime environment and handle communication with the cloud on behalf of your assets and IoT devices. Edge gateways can:
- Do protocol translation. For example, enabling Bluetooth enabled devices to connect to the cloud.
- Manage offline and disconnected scenarios. For example, buffering sensor data when the cloud endpoint is unreachable.
- Filter, compress, or aggregate asset and device data before sending it to the cloud.
- Run AI at the edge to remove the latency associated with running AI models on behalf of assets and devices in the cloud. For example, using computer vision AI to detect anomalies in a production line and automatically stopping the line to prevent defects.
Azure IoT Operations is an edge runtime environment that hosts the services to connect, monitor, and control your assets. One of the functionalities of an edge runtime environment is to act as an edge gateway, using the connectors and the MQTT broker, to communicate with assets and equipment, either directly or through a server, so that they don't need their own cloud connections.
Data flows provide data transformation and data contextualization capabilities before routing messages to various locations including cloud endpoints.
Azure IoT Operations runs on Azure Arc-enabled Kubernetes clusters, enabling a fully automated machine learning operations in hybrid mode, including training and AI model deployment steps that transition seamlessly between cloud and edge. To learn more, see Introduction to Kubernetes compute target in Azure Machine Learning.
You can use Azure IoT Edge to deploy an edge gateway to your on-premises environment. IoT Edge provides a set of features that enable you to deploy and manage edge gateways at scale. IoT Edge also provides a set of modules that you can use to implement common gateway scenarios. To learn more, see What is Azure IoT Edge?
An IoT Edge device can maintain a persistent connection to an IoT hub. The gateway forwards device sensor data to IoT Hub. This option enables command and control of the downstream devices connected to the IoT Edge device.
Azure IoT Edge allows you to deploy complex event processing, machine learning, image recognition, and other high value AI models. Azure services like Azure Stream Analytics and Azure Machine Learning can be run on-premises via the containerized Linux workloads. To learn more, see Perform image classification at the edge with Custom Vision Service.
A device bridge enables devices that are connected to a non-Microsoft cloud to connect to your IoT solution. Examples of non-Microsoft clouds include Sigfox, Particle Device Cloud, and The Things Network.
The open source IoT Central Device Bridge acts as a translator that forwards device data to an IoT Central application. To learn more, see Azure IoT Central Device Bridge. There are non-Microsoft bridge solutions, such as Tartabit IoT Bridge, for connecting devices to an IoT hub.
