Rediger

Del via

Device infrastructure and connectivity

  • Artikkel

This overview introduces the key concepts around how devices connect to the cloud in a typical Azure IoT solution. The article also introduces optional infrastructure elements such as gateways and bridges. Each section includes links to content that provides further detail and guidance.

IoT Central applications use the IoT Hub and the Device Provisioning Service (DPS) services internally. Therefore, the concepts in this article apply whether you're using IoT Central to explore an IoT scenario or building your solution by using IoT Hub and DPS.

The following diagram shows a high-level view of the components in a typical IoT solution. This article focuses on the connectivity between the devices and the IoT cloud services, including gateways and bridges, shown in the diagram.

Diagram that shows the high-level IoT solution architecture highlighting device connectivity areas.

Primitives

Azure IoT devices use the following primitives to exchange data with cloud services. Devices use:

  • Device-to-cloud messages to send time series telemetry 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 telemetry 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.

Device-facing cloud endpoints

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.

Device connection strings

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.

Authentication

Azure IoT devices use TLS to verify the authenticity of the IoT hub or DPS endpoint they're connecting to. The device SDKs 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:

All data exchanged between a device and an IoT hub is encrypted.

To learn more about security in your IoT solution, see Security architecture for IoT solutions.

Protocols

An IoT device can use one of several network protocols when it connects to an IoT Hub or DPS endpoint:

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:

Industrial IoT scenarios often use the open platform communications unified architecture (OPC UA) industry standard open interface. To enable connectivity to the Azure cloud, use Azure IoT Operations. To learn more, see What is Azure IoT Operations?.

Connection patterns

There are two broad categories of connection patterns that IoT devices use to connect to the cloud:

Persistent connections

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

Ephemeral connections are brief connections for devices to send telemetry to your IoT hub. After a device sends the telemetry, it drops the connection. The device reconnects when it has more telemetry 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 telemetry.

Field gateways

Field gateways (sometimes referred to as edge gateways) are typically deployed on-premises and close to your IoT devices. Field gateways handle communication with the cloud on behalf of your IoT devices. Field gateways can:

  • Do protocol translation. For example, enabling Bluetooth enabled devices to connect to the cloud.
  • Manage offline and disconnected scenarios. For example, buffering telemetry when the cloud endpoint is unreachable.
  • Filter, compress, or aggregate telemetry before sending it to the cloud.
  • Run logic at the edge to remove the latency associated with running logic on behalf of devices in the cloud. For example, detecting a spike in temperature and opening a valve in response.

You can use Azure IoT Edge to deploy a field gateway to your on-premises environment. IoT Edge provides a set of features that enable you to deploy and manage field 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 telemetry to IoT Hub. This option enables command and control of the downstream devices connected to the IoT Edge device.

Bridges

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 telemetry 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.

Next steps

Now that you've seen an overview of device connectivity in Azure IoT solutions, some suggested next steps include: