Merge pull request #299128 from spelluru/mqttbuild0430

Updating MQTT articles for Build

Author: rmca14

articles/event-grid/choose-right-tier.md

@@ -2,9 +2,7 @@
 title: Choose the right Event Grid tier for your solution
 description: Describes how to choose the right tier based on resource features and use cases.
 ms.topic: overview
-ms.custom:
-  - build-2024
-ms.date: 05/08/2024
+ms.date: 04/30/2025
 ---
 
 # Choose the right Event Grid tier for your solution
@@ -15,10 +13,10 @@ Azure Event Grid has two tiers with different capabilities. This article shares
 
 Azure Event Grid includes the following functionality through Event Grid namespaces:
 
-* An MQTT pub-sub broker that supports bidirectional communication using MQTT v3.1.1 and v5.0.
+* A Message Queueing Telemetry Transport (MQTT) pub-sub broker that supports bidirectional communication using MQTT v3.1.1 and v5.0.
 * CloudEvents publication using HTTP.
 * Pull delivery using HTTP.
-* Push delivery to Event Hubs using AMQP.
+* Push delivery to Event Hubs using Advanced Messaging Queueing Protocol (AMQP).
 
 Use this tier if any of the following statements is true:
 
@@ -54,20 +52,20 @@ The standard tier of Event Grid is focused on providing the following features:
 
 The basic tier is focused on providing push delivery support to trigger actions based on events. For a detailed breakdown of which quotas and limits are included in each Event Grid resource, see [Quotas and limits](quotas-limits.md).
 
-| Feature                                                                                                                            | Standard                                           | Basic                                  |
-|------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------|----------------------------------------|
-| Throughput                                                                                                                         | High, up to 40 MB/s (ingress) and 80 MB/s (egress) | Low, up to 5 MB/s (ingress and egress) |
-| MQTT v5 and v3.1.1                                                                                                                 | Yes                                                |                                        |
-| Pull delivery                                                                                                                      | Yes                                                |                                        |
-| Publish and subscribe to custom events                                                                                             | Yes                                                | Yes                                    |
+| Feature   | Standard  | Basic |
+|-----------|-----------|-------|
+| Throughput | High, up to 40 MB/s (ingress) and 80 MB/s (egress) | Low, up to 5 MB/s (ingress and egress) |
+| MQTT v5 and v3.1.1 | Yes | |
+| Pull delivery | Yes | |
+| Publish and subscribe to custom events | Yes | Yes |
 | Push delivery to Webhooks  |Yes  | Yes
-| Push delivery to Event Hubs                                                                                                        | Yes                                                | Yes                                    |
-| Push delivery to Azure services (Functions, Service Bus queues and topics, relay hybrid connections, and storage queues) |                                                    | Yes                                    |
+| Push delivery to Event Hubs | Yes | Yes |
+| Push delivery to Azure services (Functions, Service Bus queues and topics, relay hybrid connections, and storage queues) | | Yes  |
 | Maximum message retention  | 7 days on namespace topics  | 1 day
-| Subscribe to Azure system events                                                                                                   |                                                    | Yes                                    |
-| Subscribe to partner events                                                                                                        |                                                    | Yes                                    |
-| Domain scope subscriptions                                                                                                         |                                                    | Yes                                    |
-
+| Subscribe to Azure system events | | Yes |
+| Subscribe to partner events | | Yes |
+| Domain scope subscriptions | | Yes |
+| Pull delivery to Fabric Eventstream | Yes | No |
 
 ## Next steps
 

articles/event-grid/media/mqtt-overview/route-mqtt-events-to-fabric.png

@@ -2,7 +2,7 @@
 title: MQTT (PubSub) broker'
 description: Message Queuing Telemetry Transport (MQTT) PubSub broker feature in Azure Event Grid enables MQTT clients to communicate with each other and with Azure services.
 ms.topic: concept-article
-ms.date: 03/05/2025
+ms.date: 04/30/2025
 author: george-guirguis
 ms.author: geguirgu
 ms.subservice: mqtt
@@ -18,8 +18,7 @@ Azure Event Grid enables your MQTT clients to communicate with each other and wi
 - Broadcast alerts to a fleet of clients using the one-to-many messaging pattern. This pattern enables the application to publish only one message that the service replicates for every interested client.
 - Integrate data from your MQTT clients by routing MQTT messages to Azure services and Webhooks through the HTTP Push delivery functionality. This integration with Azure services enables you to build data pipelines that start with data ingestion from your IoT devices.
 
-
-The MQTT broker is ideal for the implementation of automotive and mobility scenarios, among others. See [the reference architecture](mqtt-automotive-connectivity-and-data-solution.md) to learn how to build secure and scalable solutions for connecting millions of vehicles to the cloud, using Azure’s messaging and data analytics services.
+The MQTT broker is ideal for the implementation of automotive, mobility and manufacturing scenarios, among others. See the reference architectures - [automotive](/industry/mobility/architecture/automotive-messaging-data-analytics-content) and [manufacturing](/industry/manufacturing/manufacturing-data-solutions/architecture/ra-manufacturing-data-solutions) to learn how to build secure and scalable solutions for connecting millions of MQTT clients to the cloud, using Azure’s messaging and data analytics services. 
 
 :::image type="content" source="media/overview/mqtt-messaging-high-res.png" alt-text="High-level diagram of Event Grid that shows bidirectional MQTT communication with publisher and subscriber clients." border="false":::
 
@@ -40,13 +39,12 @@ MQTT is a publish-subscribe messaging transport protocol that was designed for c
 	- **Clean start and session expiry** enable your clients to optimize the reliability and security of the session by preserving the client's subscription information and messages for a configurable time interval.
 	- **Negative acknowledgments** allow your clients to efficiently react to different error codes.
    	- **Server-sent disconnect packets** allow your clients to efficiently handle disconnects.
-- MQTT broker is adding more MQTT v5 features in the future to align more with the MQTT specifications. The following items detail the current differences between features supported by MQTT broker and the MQTT v5 specifications: Will message, Retain flag, Message ordering, and QoS 2 aren't supported.
 
 - MQTT v3.1.1 features:
   	- **Last Will and Testament** notifies your MQTT clients with the abrupt disconnections of other MQTT clients. You can use this feature to ensure predictable and reliable flow of communication among MQTT clients during unexpected disconnections.
 	- **Persistent sessions** ensure reliability by preserving the client's subscription information and messages when a client disconnects.
 	- **QoS 0 and 1** provide your clients with control over the efficiency and reliability of the communication.
--  MQTT broker is adding more MQTT v3.1.1 features in the future to align more with the MQTT specifications. The following items detail the current differences between features supported by MQTT broker and the MQTT v3.1.1 specification: Retain flag, Message ordering, and QoS 2 aren't supported.
+-  MQTT broker is adding more MQTT v5 and MQTT v3.1.1  features in the future to align more with the MQTT specifications. The following items detail the current differences between features supported by MQTT broker and the MQTT v5 specifications: Retain flag, and QoS 2 aren't supported.  
 
 [Learn more about the MQTT broker and current limitations.](mqtt-support.md) 
 
@@ -74,8 +72,10 @@ IoT applications are software designed to interact with and process data from Io
 Event Grid has a client registry that stores information about the clients permitted to connect to it. Before a client can connect, there must be an entry for that client in the client registry. As a client connects to MQTT broker, it needs to authenticate with MQTT broker based on credentials stored in the identity registry. MQTT broker supports the following client authentication mechanisms:
 
 - [X.509 certificate authentication](mqtt-client-authentication.md), which is the industry authentication standard in IoT devices.
-- [Microsoft Entra IDauthentication](mqtt-client-microsoft-entra-token-and-rbac.md), which is Azure's authentication standard for applications. [Learn more about MQTT client authentication.](mqtt-client-authentication.md)
-- [OAuth 2.0 (JSON Web Token) authentication](oauth-json-web-token-authentication.md), which provides a lightweight, secure, and flexible option for MQTT clients that aren't provisioned in Azure.
+- [Microsoft Entra ID authentication](mqtt-client-microsoft-entra-token-and-rbac.md), which is Azure's authentication standard for applications. [Learn more about MQTT client authentication.](mqtt-client-authentication.md)
+- Flexible authentications
+    - [OAuth 2.0 JSON Web Token (JWT) authentication](oauth-json-web-token-authentication.md), which provides a lightweight, secure, and flexible option for MQTT clients that aren't provisioned in Azure.
+    - Custom Webhook authentication allows external HTTP endpoints (webhooks) to authenticate MQTT connections dynamically. It uses the Entra ID JWT validation to ensure secure access.
 
 
 ### Access control
@@ -94,6 +94,12 @@ Event Grid allows you to route your MQTT messages to Azure services or webhooks
 
 :::image type="content" source="media/mqtt-overview/routing-high-res.png" alt-text="Diagram that shows MQTT message routing in Azure Event Grid." border="false":::
 
+### MQTT events to Microsoft Fabric event streams (Preview) 
+Route MQTT messages and Cloud Events from Event Grid Namespace to Fabric Event Streams for real-time analytics, storage, visualization of IoT data.
+
+:::image type="content" source="./media/mqtt-overview/route-mqtt-events-to-fabric.png" alt-text="Diagram that shows how MQTT events are routed to Fabric." lightbox="./media/mqtt-overview/route-mqtt-events-to-fabric.png":::
+
+
 ### Edge MQTT broker integration
 Event Grid integrates with [Azure IoT Operations](../iot-operations/manage-mqtt-broker/overview-broker.md) to bridge its MQTT broker capability on the edge with Azure Event Grid’s MQTT broker feature in the cloud. Azure IoT Operations provides a new distributed MQTT broker for edge computing, running on Arc enabled Kubernetes clusters. It can connect to Event Grid MQTT broker with Microsoft Entra ID authentication using system-assigned managed identity, which simplifies credential management. MQTT Broker provides high availability, scalability, and security for your IoT devices and applications. It's now available in [public preview](../iot-operations/manage-mqtt-broker/overview-broker.md) as part of Azure IoT Operations. [Learn more about connecting Azure IoT Operations MQTT Broker to Azure Event Grid's MQTT broker](../iot-operations/connect-to-cloud/howto-create-dataflow.md).
 

articles/event-grid/mqtt-overview.md

@@ -5,7 +5,7 @@ ms.topic: conceptual
 ms.custom:
   - ignite-2023
   - build-2024
-ms.date: 11/15/2023
+ms.date: 04/30/2025
 author: george-guirguis
 ms.author: geguirgu
 ms.subservice: mqtt
@@ -86,7 +86,7 @@ Azure Event Grid’s MQTT broker feature supports the following MQTT features:
 MQTT broker supports QoS 0 and 1, which define the guarantee of message delivery on PUBLISH and SUBSCRIBE packets between clients and MQTT broker. QoS 0 guarantees at-most-once delivery; messages with QoS 0 aren’t acknowledged by the subscriber nor get retransmitted by the publisher. QoS 1 guarantees at-least-once delivery; messages are acknowledged by the subscriber and get retransmitted by the publisher if they didn’t get acknowledged. QoS enables your clients to control the efficiency and reliability of the communication.
 
 ### Persistent sessions
-MQTT broker supports persistent sessions for MQTT v3.1.1 such that MQTT broker preserves information about a client’s session in case of disconnections to ensure reliability of the communication. This information includes the client’s subscriptions and missed/ unacknowledged QoS 1 messages. Clients can configure a persistent session through setting the cleanSession flag in the CONNECT packet to false.
+MQTT broker supports persistent sessions for MQTT v3.1.1 such that MQTT broker preserves information about a client’s session when it gets disconnected to ensure reliability of the communication. This information includes the client’s subscriptions and missed/ unacknowledged QoS 1 messages. Clients can configure a persistent session through setting the cleanSession flag in the CONNECT packet to false.
 
 #### Clean start and session expiry
 MQTT v5 introduced the clean start and session expiry features as an improvement over MQTT v3.1.1 in handling session persistence. Clean Start is a feature that allows a client to start a new session with MQTT broker, discarding any previous session data. Session Expiry allows a client to inform MQTT broker when an inactive session is considered expired and automatically removed. In the CONNECT packet, a client can set Clean Start flag to true and/or short session expiry interval for security reasons or to avoid any potential data conflicts that might have occurred during the previous session. A client can also set a clean start to false and/or long session expiry interval to ensure the reliability and efficiency of persistent sessions.
@@ -104,7 +104,7 @@ MQTT broker maintains a queue of messages for each active MQTT session that isn'
 
 ### Last Will and Testament (LWT) messages
 Last Will and Testament (LWT) notifies your MQTT clients with the abrupt disconnections of other MQTT clients. You can use LWT to ensure predictable and reliable flow of communication among MQTT clients during unexpected disconnections, which is valuable for scenarios where real-time communication, system reliability, and coordinated actions are critical. Clients that collaborate to perform complex tasks can react to LWT messages from each other by adjusting their behavior, redistributing tasks, or taking over certain responsibilities to maintain the system’s performance and stability.
-To use LWT, a client can specify the will message, will topic, and the rest of the will properties in the CONNECT packet during connection. When the client disconnects abruptly, the MQTT broker publishes the will message to all the clients that subscribed to the will topic. To reduce the noise from fluctuating disconnections, the client can set the will delay interval to a value greater than zero. In that case, if the client disconnects abruptly but restores the connection before the will delay interval expires, the will message isn't published.
+To use LWT, a client can specify the will message, will topic, and the rest of the will properties in the CONNECT packet during connection. When the client disconnects abruptly, the MQTT broker publishes the will message to all the clients that subscribed to the will topic. To reduce the noise from fluctuating disconnections, the client can set the delay interval to a value greater than zero. In that case, if the client disconnects abruptly but restores the connection before the delay interval expires, the will message isn't published.
 
 ### User properties 
 MQTT broker supports user properties on MQTT v5 PUBLISH packets that allow you to add custom key-value pairs in the message header to provide more context about the message. The use cases for user properties are versatile. You can use this feature to include the purpose or origin of the message so the receiver can handle the message without parsing the payload, saving computing resources. For example, a message with a user property indicating its purpose as a "warning" could trigger different handling logic than one with the purpose of "information."
@@ -128,6 +128,12 @@ In MQTT v5, flow control refers to the mechanism for managing the rate and size
 ### Negative acknowledgments and server-initiated disconnect packet
 For MQTT v5, MQTT broker is able to send negative acknowledgments (NACKs) and server-initiated disconnect packets that provide the client with more information about failures for  message delivery or connection. These features help the client diagnose the reason behind a failure and take appropriate mitigating actions. MQTT broker uses the reason codes that are defined in the [MQTT v5 Specification.](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)
 
+### Message Ordering  
+MQTT v5 ensures that messages sent within a single session are delivered in the same order they were published. MQTT broker fully supports it by maintaining message ordering per connection, so subscribers receive data in the exact sequence it was sent—ideal for scenarios like telemetry, command execution, and time-series data. 
+
+### Assigned Client Identifiers (Preview) 
+MQTT v5 introduces support for assigned client identifiers, allowing the broker to generate and return a unique client ID when one isn't provided by the client. MQTT broker supports this feature, ensuring seamless client onboarding and reducing the need for clients to manage their own identifiers. It's especially useful in scenarios where client provisioning is dynamic or when devices have no preconfigured identity. Assigned client IDs can be retrieved from the CONNACK response and reused for future sessions to maintain consistent identification. 
+
 ## Current limitations
 
 MQTT broker is adding more MQTT v5 and MQTT v3.1.1 features in the future to align more with the MQTT specifications. The following list details the current differences between features supported by the MQTT broker and the MQTT specifications:
@@ -137,12 +143,10 @@ MQTT broker is adding more MQTT v5 and MQTT v3.1.1 features in the future to ali
 MQTT v5 currently differs from the [MQTT v5 Specification](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html) in the following ways:
 - Shared Subscriptions aren't supported yet.
 - Retain flag isn't supported yet.
-- Maximum will delay interval is 300.
+- Maximum Will delay interval is 300.
 - Maximum QoS is 1.
 - Maximum Packet Size is 512 KiB
-- Message ordering isn't guaranteed.
 - Subscription Identifiers aren't supported.
-- Assigned Client Identifiers aren't supported yet.
 - Topic Alias Maximum is 10. The server doesn't assign any topic aliases for outgoing messages at this time. Clients can assign and use topic aliases within set limit.
 - CONNACK doesn't return Response Information property even if the CONNECT request contains Request Response Information property.
 - User Properties on CONNECT, SUBSCRIBE, DISCONNECT, PUBACK, AUTH packets aren't used by the service so they're not supported. If any of these requests include user properties, the request fails.
@@ -153,7 +157,6 @@ MQTT v5 currently differs from the [MQTT v5 Specification](https://docs.oasis-op
 
 MQTT v5 currently differs from the [MQTT v3.1.1 Specification](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html) in the following ways:
 - QoS2 and Retain Flag aren't supported yet. A publish request with a retain flag or with a QoS2 fails and closes the connection.
-- Message ordering isn't guaranteed.
 - Keep Alive Maximum is 1,160 seconds.
 
 ## Code samples: