Quality of Service (QoS) Mapping

Quality of Service (QoS) is a critical mechanism in messaging protocols that determines the reliability of message delivery. Different protocols implement QoS in various ways, making protocol translation challenging but essential for interoperable IoT systems.

Understanding QoS Across Protocols

Before diving into cross-protocol QoS mapping, it's important to understand how different protocols conceptualize and implement QoS:

Protocol	QoS Levels	Description
MQTT 3.1.1	0, 1, 2	QoS 0: At most once (fire and forget) QoS 1: At least once (acknowledged delivery) QoS 2: Exactly once (assured delivery)
MQTT 5.0	0, 1, 2	QoS 0: At most once (fire and forget) QoS 1: At least once (acknowledged delivery) QoS 2: Exactly once (assured delivery) Added message properties to extend QoS functionality
MQTT-SN 1.2	-1, 0, 1, 2	QoS -1: Fire and forget with no connection QoS 0: At most once QoS 1: At least once QoS 2: Exactly once
MQTT-SN 2.0	-1, 0, 1, 2	Similar to MQTT-SN 1.2 with improvements Better integration with MQTT 5.0 features
AMQP 1.0	Settlements & Dispositions	Unsettled: Requires acknowledgment Settled: No acknowledgment required Dispositions: accepted, rejected, released, modified
CoAP 1.2	Confirmable & Non-confirmable	CON: Confirmable messages (reliable) NON: Non-confirmable messages (unreliable)
STOMP 1.2	Simple delivery	No inherent QoS levels Uses receipts for basic acknowledgments Relies on underlying transport for reliability

QoS Level Mapping Table

When translating between protocols, QoS levels must be mapped to ensure reliable message delivery while respecting each protocol's capabilities:

Source Protocol QoS	MQTT	MQTT-SN	AMQP	CoAP	STOMP
MQTT QoS 0	QoS 0	QoS 0	Settled	NON	Simple send
MQTT QoS 1	QoS 1	QoS 1	Unsettled + Accepted	CON	Send + Receipt
MQTT QoS 2	QoS 2	QoS 2	Unsettled + Accepted with transaction	CON + Retry mechanism Enterprise	Send + Receipt + Custom deduplication Enterprise
MQTT-SN QoS -1	QoS 0 (best effort)	QoS -1	Presettled	NON	Simple send
AMQP Settled	QoS 0	QoS 0	Settled	NON	Simple send
AMQP Unsettled + Accepted	QoS 1	QoS 1	Unsettled + Accepted	CON	Send + Receipt
CoAP NON	QoS 0	QoS 0	Settled	NON	Simple send
CoAP CON	QoS 1	QoS 1	Unsettled + Accepted	CON	Send + Receipt
STOMP (no receipt)	QoS 0	QoS 0	Settled	NON	Simple send
STOMP (with receipt)	QoS 1	QoS 1	Unsettled + Accepted	CON	Send + Receipt

Certain protocol combinations (such as STOMP to MQTT QoS 2) require additional infrastructure to support higher reliability levels not natively supported by the source protocol.

QoS Mapping Examples

Example 1: MQTT to CoAP Translation

// MQTT Publisher sending QoS 1 message mqttClient.publish("sensors/temperature", "22.5", { qos: 1 });

// Translated to CoAP Confirmable request → Converted to CoAP CON message with token for tracking

// CoAP Request CON [0xb1] POST /sensors/temperature Token: 0x7d3e Payload: 22.5

// CoAP Response confirming receipt ← Sent back to MQTT client as PUBACK

Example 2: CoAP to MQTT-SN Translation

// CoAP Non-confirmable request (similar to fire-and-forget) NON [0x71] PUT /actuators/led Payload: "ON"

// Translated to MQTT-SN QoS 0 message → Converted to MQTT-SN PUBLISH with QoS 0

// MQTT-SN Publish (no acknowledgment required) PUBLISH TopicId: 0x0001 (mapped from /actuators/led) QoS: 0 Payload: "ON"

Example 3: AMQP to MQTT Translation with QoS 2

// AMQP Sender using Transactions for reliability txn = session.beginTransaction(); sender.send(message, txn); // Wait for confirmation txn.commit();

// Translated to MQTT QoS 2 message → Converted to MQTT PUBLISH with QoS 2

// MQTT Publish QoS 2 flow PUBLISH (QoS 2, packet id: 1234) → PUBREC (packet id: 1234) → PUBREL (packet id: 1234) → PUBCOMP (packet id: 1234)

Best Practices for QoS Selection

When designing IoT systems that involve protocol translation:

Match QoS levels to application requirements, not higher

Consider bandwidth and resource constraints, especially for constrained devices

Use QoS 0 for frequent, non-critical sensor readings

Use QoS 1 for important messages where occasional duplicates are acceptable

Reserve QoS 2 for critical commands or financial/billing information

Remember QoS increases message overhead (packet size and processing)

Consider splitting your strategy by message type rather than using one QoS for everything

Advanced QoS Features Premium ML

Adaptive QoS

Our platform's Premium ML edition offers Adaptive QoS, which intelligently adjusts QoS levels based on:

1. Network conditions: Automatically increases reliability in poor network conditions
2. Message importance: Uses content-aware classification to assign appropriate QoS
3. Historical patterns: Learns from delivery success patterns
4. Device capabilities: Adapts to energy and bandwidth constraints
5. Application feedback: Adjusts based on application-level success metrics

This ensures optimal resource usage while maintaining required reliability.

QoS Translation Guarantees

The maximum achievable end-to-end QoS is limited by the lowest capability in the chain:

Scenario	Max Effective QoS	Enterprise Features
MQTT → MQTT	QoS 2 (Exactly once)	Native support
MQTT → CoAP	QoS 1 (At least once)	Deduplication for QoS 2 simulation
MQTT → STOMP	QoS 1 (At least once)	Message tracking & retransmission
CoAP → MQTT-SN	QoS 1 (At least once)	Enhanced reliability layer
Heterogeneous chain	Varies by path	End-to-end QoS monitoring Premium ML

Our Protocol Mapping system ensures the most appropriate translation of QoS semantics across different protocols, maximizing reliability within the constraints of each protocol.