One more file DocuMentored

Author: sethmanheim

articles/iot-edge/iot-edge-as-gateway.md

@@ -3,7 +3,7 @@ title: Use Azure IoT Edge as a gateway for downstream devices
 description: Use Azure IoT Edge to create a transparent, opaque, or proxy gateway device that sends data from multiple connected devices to the cloud or processes locally.
 author: sethmanheim
 ms.author: sethm
-ms.date: 07/09/2025
+ms.date: 02/25/2026
 ms.topic: concept-article
 ms.service: azure-iot-edge
 services: iot-edge
@@ -13,31 +13,31 @@ ms.custom:
   - sfi-image-nochange
 ---
 
-# How an IoT Edge device can be used as a gateway
+# How to use an IoT Edge device as a gateway
 
 [!INCLUDE [iot-edge-version-all-supported](includes/iot-edge-version-all-supported.md)]
 
 IoT Edge devices can operate as gateways, providing a connection between other devices on the network and IoT Hub.
 
 The IoT Edge hub module acts like IoT Hub, so it can handle connections from other devices that have an identity with the same IoT hub. This type of gateway pattern is called *transparent* because messages can pass from downstream devices (devices that connect through the gateway) to IoT Hub as though there weren't a gateway between them.
 
-For devices that don't or can't connect to IoT Hub on their own, IoT Edge gateways can provide that connection. This type of gateway pattern is called *translation* because the IoT Edge device has to perform processing on incoming downstream device messages before they can be forwarded to IoT Hub. These scenarios require extra modules on the IoT Edge gateway to handle the processing steps.
+For devices that don't or can't connect to IoT Hub on their own, IoT Edge gateways can provide that connection. This type of gateway pattern is called *translation* because the IoT Edge device has to perform processing on incoming downstream device messages before it can forward them to IoT Hub. These scenarios require extra modules on the IoT Edge gateway to handle the processing steps.
 
 The transparent and translation gateway patterns aren't mutually exclusive. A single IoT Edge device can function as both a transparent gateway and a translation gateway.
 
 All gateway patterns provide the following benefits:
 
 * **Analytics at the edge** - Use Foundry Tools locally to process data coming from downstream devices without sending full-fidelity telemetry to the cloud. Find and react to insights locally and only send a subset of data to IoT Hub.
-* **Connected device isolation** - The gateway device can shield all connected devices from exposure to the internet. It can sit in between an operational technology (OT) network that doesn't have connectivity and an information technology (IT) network that provides access to the web. Similarly, devices that don't have the capability to connect to IoT Hub on their own can connect to a gateway device instead.
+* **Connected device isolation** - The gateway device shields all connected devices from exposure to the internet. It sits between an operational technology (OT) network that doesn't have connectivity and an information technology (IT) network that provides access to the web. Similarly, devices that don't have the capability to connect to IoT Hub on their own can connect to a gateway device instead.
 * **Connection multiplexing** - All devices connecting to IoT Hub through an IoT Edge gateway can use the same underlying connection. This multiplexing capability requires that the IoT Edge gateway uses AMQP as its cloud-bound protocol.
 * **Traffic smoothing** - The IoT Edge device automatically implements exponential backoff if IoT Hub throttles traffic, while persisting the messages locally. This benefit makes your solution resilient to spikes in traffic.
 * **Offline support** - The gateway device stores messages and twin updates that can't be delivered to IoT Hub.
 
 ## Transparent gateways
 
-In the transparent gateway pattern, devices that theoretically could connect to IoT Hub can connect to a gateway device instead. These devices (called *downstream devices* or *child devices*) have their own IoT Hub identities and connect using either MQTT or AMQP protocols. The gateway simply passes communications between the devices and IoT Hub. Both the devices and the users interacting with them through IoT Hub are unaware that a gateway is mediating their communications. This lack of awareness means the gateway is considered *transparent*.
+In the transparent gateway pattern, devices that theoretically can connect to IoT Hub can connect to a gateway device instead. These devices, called *downstream devices* or *child devices*, have their own IoT Hub identities and connect by using either MQTT or AMQP protocols. The gateway simply passes communications between the devices and IoT Hub. Both the devices and the users interacting with them through IoT Hub are unaware that a gateway is mediating their communications. This lack of awareness means the gateway is considered *transparent*.
 
-For more information about how the IoT Edge hub manages communication between downstream devices and the cloud, see [Azure IoT Edge runtime and architecture overview](iot-edge-runtime.md).
+For more information about how the IoT Edge hub manages communication between downstream devices and the cloud, see the [Azure IoT Edge runtime and architecture overview](iot-edge-runtime.md).
 
 Beginning with version 1.2 of IoT Edge, transparent gateways can handle connections from downstream IoT Edge devices.
 
@@ -69,10 +69,10 @@ Change arrow styles to include a double hyphen to make it work in the markdown m
 
 You declare transparent gateway relationships in IoT Hub by setting the IoT Edge gateway as the *parent* of a downstream device *child* that connects to it.
 
->[!NOTE]
->A downstream device emits data directly to the Internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
+> [!NOTE]
+> A downstream device sends data directly to the Internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
 
-The parent/child relationship is established at three points in the gateway configuration:
+You establish the parent/child relationship at three points in the gateway configuration:
 
 #### Cloud identities
 
@@ -85,11 +85,11 @@ All devices in a transparent gateway scenario need cloud identities so they can
 
 Child devices can only have one parent. By default, a parent can have up to 100 children. You can change this limit by setting the **MaxConnectedClients** environment variable in the parent device's edgeHub module.
 
-IoT Edge devices can be both parents and children in transparent gateway relationships. A hierarchy of multiple IoT Edge devices reporting to each other can be created. The top node of a gateway hierarchy can have up to five generations of children. For example, an IoT Edge device can have five layers of IoT Edge devices linked as children below it. But the IoT Edge device in the fifth generation can't have any children, IoT Edge or otherwise.
+IoT Edge devices can be both parents and children in transparent gateway relationships. You can create a hierarchy of multiple IoT Edge devices reporting to each other. The top node of a gateway hierarchy can have up to five generations of children. For example, an IoT Edge device can have five layers of IoT Edge devices linked as children below it. But the IoT Edge device in the fifth generation can't have any children, IoT Edge or otherwise.
 
 #### Gateway discovery
 
-A child device needs to be able to find its parent device on the local network. Configure gateway devices with a **hostname**, either a fully qualified domain name (FQDN) or an IP address, that its child devices use to locate it.
+A child device needs to be able to find its parent device on the local network. You configure gateway devices with a **hostname**, either a fully qualified domain name (FQDN) or an IP address, that its child devices use to locate it.
 
 On downstream IoT devices, use the **gatewayHostname** parameter in the connection string to point to the parent device.
 
@@ -123,9 +123,9 @@ Use the following table to see how different IoT Hub capabilities are supported
 
 ## Translation gateways
 
-If downstream devices can't connect to IoT Hub, then the IoT Edge gateway needs to act as a translator. Often, this pattern is required for devices that don't support MQTT, AMQP, or HTTP. Since these devices can't connect to IoT Hub, they also can't connect to the IoT Edge hub module without some preprocessing.
+If downstream devices can't connect to IoT Hub, the IoT Edge gateway needs to act as a translator. Often, this pattern is required for devices that don't support MQTT, AMQP, or HTTP. Since these devices can't connect to IoT Hub, they also can't connect to the IoT Edge hub module without some preprocessing.
 
-Custom or non-Microsoft modules that are often specific to the downstream device's hardware or protocol need to be deployed to the IoT Edge gateway. These translation modules take the incoming messages and turn them into a format understood by IoT Hub.
+You need to deploy custom or non-Microsoft modules that are often specific to the downstream device's hardware or protocol to the IoT Edge gateway. These translation modules take the incoming messages and turn them into a format understood by IoT Hub.
 
 There are two patterns for translation gateways: *protocol translation* and *identity translation*.
 
@@ -135,7 +135,7 @@ There are two patterns for translation gateways: *protocol translation* and *ide
 
 In the protocol translation gateway pattern, only the IoT Edge gateway has an identity with IoT Hub. The translation module receives messages from downstream devices, translates them into a supported protocol, and then the IoT Edge device sends the messages on behalf of the downstream devices. All information looks like it's coming from one device, the gateway. Downstream devices must embed more identifying information in their messages if cloud applications want to analyze the data on a per-device basis. Additionally, IoT Hub primitives like twins and direct methods are only supported for the gateway device, not downstream devices. Gateways in this pattern are considered *opaque* in contrast to transparent gateways, because they obscure the identities of downstream devices.
 
-Protocol translation supports devices that are resource constrained. Many existing devices are producing data that can power business insights; however they weren't designed with cloud connectivity in mind. Opaque gateways allow this data to be unlocked and used in an IoT solution.
+Protocol translation supports devices that are resource constrained. Many existing devices are producing data that can power business insights; however, they weren't designed with cloud connectivity in mind. Opaque gateways allow this data to be unlocked and used in an IoT solution.
 
 ### Identity translation
 
@@ -154,7 +154,7 @@ The following table explains how IoT Hub features are extended to downstream dev
 | Direct methods and cloud-to-device messages | The cloud can only address the gateway device | The cloud can address each connected device individually |
 | [IoT Hub quotas and throttling](../iot-hub/iot-hub-devguide-quotas-throttling.md) | Apply to the gateway device | Apply to each device |
 
-When a gateway uses the protocol translation pattern, all devices connecting through that gateway share the same cloud-to-device queue, which can contain at most 50 messages. Only use this pattern when few devices are connecting through each field gateway, and their cloud-to-device traffic is low.
+When a gateway uses the protocol translation pattern, all devices connecting through that gateway share the same cloud-to-device queue, which can contain at most 50 messages. Only use this pattern when few devices connect through each field gateway, and their cloud-to-device traffic is low.
 
 The IoT Edge runtime doesn't include protocol or identity translation capabilities. These patterns require custom or non-Microsoft modules that are often specific to the hardware and protocol used. [Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps/category/internet-of-things?page=1&subcategories=iot-edge-modules) contains several protocol translation modules to choose from. For a sample that uses the identity translation pattern, see [Azure IoT Edge LoRaWAN Starter Kit](https://github.com/Azure/iotedge-lorawan-starterkit).