This page lists Cloud IoT Core requirements and related information.

Regions and versions

Cloud regions

Only these cloud regions are available: us-central1, europe-west1, and asia-east1.

Cloud SDK

Cloud IoT Core requires version 173.0.0 or higher of the Cloud SDK.

Transport Layer Security (TLS)

Cloud IoT Core requires TLS version 1.2 or higher. For more guidance on TLS, see the section "Minimum standards for TLS clients" in Disabling SSLv3 and RC4 on the Google Security Blog.

MQTT bridge

MQTT version 3.1.1 is required.

The following features are not supported:

  • MQTT QoS 2
  • Arbitrary MQTT topics and subscriptions. For topic requirements, see the section on connecting devices using MQTT
  • Last Will and Testament (LWT)
  • Retained messages
  • Persistent sessions

Permitted characters and size requirements

Registries and device identifiers, and their associated fields, are limited to certain characters. These fields are also limited in size (either length or byte size).

The following table lists the permitted characters and sizes for each resource:

Resource Limitations
Registry IDs
  • Permitted characters: [a-zA-Z][-a-zA-Z0-9._+~%]+
  • Minimum length: 3 characters
  • Maximum length: 255 characters
  • Cannot start with "goog"
    Device IDs
    • Must be unique within the parent device registry
    • Permitted characters: [a-zA-Z][-a-zA-Z0-9._+~%]+
    • Minimum length: 3 characters
    • Maximum length: 255 characters
    • Cannot start with "goog"
      Device metadata keys
      • Permitted characters: [a-zA-Z][-a-zA-Z0-9._+~%]+
      • First character must be a letter ([a-zA-Z])
      • Minimum length: 1 character
      • Maximum length: 128 characters
      • Maximum combined total size of all device metadata key-value pairs: 256 KB
      Device metadata values
      • Minimum size: 0 KB
      • Maximum size: 32 KB
      • Maximum combined total size of all device metadata key-value pairs: 256 KB
      • Permitted characters: [a-zA-Z][-a-zA-Z0-9._+~%]+
      • First character must be a letter ([a-zA-Z])
      • Maximum size: 256 bytes

      "Subfolders" refers to the eventNotificationConfigs.subfolderMatches field in the device registry, which is used when matching MQTT or HTTP subfolders to a Cloud Pub/Sub topic. For more information, see Creating a device registry with multiple Pub/Sub topics.

      Managing excessive load with exponential backoff

      This section explains how to use truncated exponential backoff to ensure that your devices do not generate excessive load.

      When devices retry calls without waiting, they can produce a heavy load on the Cloud IoT Core servers. Cloud IoT Core automatically limits projects that generate excessive load. Even a small fraction of overactive devices can trigger limits that affect all devices in the same Cloud Platform project.

      To avoid triggering these limits, you are strongly encouraged to implement truncated exponential backoff with introduced jitter. If you have questions or would like to discuss the specifics of your algorithm, complete this form.

      Truncated exponential backoff is a standard error-handling strategy for network applications. In this approach, a client periodically retries a failed request with increasing delays between requests. Clients should use truncated exponential backoff for all requests to Cloud IoT Core that return HTTP 5xx and 429 response codes, as well as for disconnections from the MQTT server.

      Example algorithm

      An exponential backoff algorithm retries requests exponentially, increasing the waiting time between retries up to a maximum backoff time. For example:

      1. Make a request to Cloud IoT Core.

      2. If the request fails, wait 1 + random_number_milliseconds seconds and retry the request.

      3. If the request fails, wait 2 + random_number_milliseconds seconds and retry the request.

      4. If the request fails, wait 4 + random_number_milliseconds seconds and retry the request.

      5. And so on, up to a maximum_backoff time.

      6. Continue waiting and retrying up to some maximum number of retries, but do not increase the wait period between retries.


      • The wait time is min(((2^n)+random_number_milliseconds), maximum_backoff), with n incremented by 1 for each iteration (request).

      • random_number_milliseconds is a random number of milliseconds less than or equal to 1000. This helps to avoid cases in which many clients are synchronized by some situation and all retry at once, sending requests in synchronized waves. The value of random_number_milliseconds is recalculated after each retry request.

      • maximum_backoff is typically 32 or 64 seconds. The appropriate value depends on the use case.

      The client can continue retrying after it has reached the maximum_backoff time. Retries after this point do not need to continue increasing backoff time. For example, suppose a client uses a maximum_backoff time of 64 seconds. After reaching this value, the client can retry every 64 seconds. At some point, clients should be prevented from retrying indefinitely.

      The wait time between retries and the number of retries depend on your use case and network conditions.

      For an example, see the retrying library for Python.

      Sample implementations incorporating exponential backoff are provided in the following languages:

      Send feedback about...

      Google Cloud Internet of Things Core